Session CRT-20261026 — 26 October 2026 · Afternoon Edition

Tonight’s queue is: 1) LiteLLM 1.107.0 artifacts that executed—preserve evidence, isolate affected workloads, rotate every credential available to the process, and rebuild from a trusted artifact such as 1.106.2 or earlier. 2) Internet-facing PHP2Shell exposure—successful exploitation has progressed beyond scanning, so isolate any host showing execution and canary-test an official patched PHP release before broad deployment. 3) CVE-2026-114625—restrict access and investigate on-premises VCOs only where the service is reachable and a valid Enterprise Read Only session exists; suspicious session activity elevates it to immediate containment. 4) Brotli, unless inventory confirms a vulnerable decoder directly processes untrusted external input. Any confirmed execution overrides that ordering and enters the incident-containment queue.

For Brotli CVE-2026-111497, the available advisories identify an out-of-bounds write in the decoder. Inventory deployed artifacts, not just repositories: compare Node.js runtimes against fixed releases 22.23.4, 24.22.1, and 26.12.1; identify Bun below 1.4.4; enumerate .NET shared runtimes, NuGet packages, self-contained applications, and NativeAOT builds—the Microsoft package table includes .NET 9 packages below 9.0.22 as affected; inspect Python environments and lockfiles for Brotli and brotlicffi, with reported fixed releases 1.2.1 and 1.2.1.0 respectively; inventory Envoy binaries and images against 1.37.8, 1.38.6, 1.39.3, or 1.40.0; and map Istio proxies and gateways against 1.29.9, 1.30.6, or 1.31.2, while preferring supported release lines. Generate SBOMs from running images and hosts, inspect native packages and binaries for embedded Brotli symbols, and rebuild statically linked applications—updating a host library will not replace an embedded copy.

I would still reject an estate-wide Brotli emergency. Emergency patching belongs on confirmed-vulnerable decoders handling attacker-controlled compressed content through public HTTP services, uploads, API gateways, Envoy ingress, or Istio gateways. Encoder-only paths, unreachable internal services, dormant dependencies, and unconfirmed static copies should receive expedited inventory and staged maintenance instead. The evidence establishes affected versions and fixes, but the sources reviewed here do not establish active exploitation; mass replacement without reachability analysis risks avoidable production disruption.

Halil, the ordering stands only when LiteLLM execution is established. Starting Python in an environment containing a poisoned 1.107.0 wheel can execute the payload even without importing LiteLLM, creating a credential-theft and recurring remote-code-execution channel. That is a compromise, not exposure, so isolate it, preserve evidence, and rotate reachable credentials first. By contrast, merely downloading a wheel or pulling an affected container does not establish execution; quarantine it and confirm whether Python or the container ever started.

PHP2Shell now warrants an emergency posture: reporting documents pre-patch exploitation, compromise of a European government entity, and scanning across 216 unpatched hosts. Therefore, the CISO should swap priorities tonight when LiteLLM is pull-only while PHP is internet-facing, unpatched or partly mitigated, and running an affected configuration. Take that PHP service offline or patch it first, using fixed releases 8.5.12, 8.4.27, 8.3.36, or 8.2.35 or the distribution’s fixed package. Preserve memory and logs before restarting workers if there are worker crashes, malformed multipart requests, unexpected files, shell processes, or other exploitation indicators.

The decision rule is straightforward: confirmed execution beats exposure; among exposures, active exploitation plus direct internet reachability beats an artifact that never ran. If both have execution evidence, run parallel containment; if staffing forces a single first move, prioritize the system with accessible production credentials and the larger downstream blast radius.

James’s ranking is right. SQL errors alone do not cross the incident threshold. Isolate immediately when an authenticated low-privilege session is followed by any of these: operator-only API or console activity; local-superuser impersonation; operator creation/reactivation or role elevation; credential or MFA changes; unscheduled bulk configuration exports; unauthorized profile, route, VPN, firewall, certificate, or edge-configuration pushes; mass edge reboot/deactivation; or unexpected VCO-host outbound traffic, webshells, daemons, database writes, or filesystem changes. Repeated SQL syntax/database exceptions become decisive only when correlated to that session and a subsequent privilege or state transition. Arista also lists two malicious source IPs—74.82.197.86 and 38.54.50.151—but an IP match is a hunting lead, not proof by itself.

If patching cannot finish tonight, break both required links: place the VCO web interface behind an upstream firewall or VPN and permit only named administrative source addresses; then disable stale and nonessential portal accounts, terminate existing sessions, and rotate credentials associated with suspicious sessions. Add outbound allow-listing from the VCO host. That is the minimum credible containment because the documented chain needs both web-interface reachability and a valid authenticated session. Preserve web-access, backend-application, system, database logs, and filesystem timestamps before making changes.

What would prove this narrower urgency wrong? Evidence that exploitation works without authentication, that attackers can mint or steal a portal session through the same endpoint, or that ordinary unauthenticated probes are producing operator sessions or downstream edge changes. Any of those closes the chain from the public Internet and moves VeloCloud into the “isolate now” tier—not merely emergency patching and hunting.

Confirmed: Keystone stated that unauthorized website access was detected on October 20 and, after reviewing Shopify API activity, confirmed on October 23 that a third party obtained customers’ names, contact and shipping details, and order information including products and prices. The exposed records identify both a physical location and likely cryptocurrency ownership. They do not, by themselves, establish compromise of wallets, seed phrases, private keys, or funds. The single reported law-enforcement impersonation attempt is one warning signal—not proof of a broader campaign or demonstrated theft.

Obligation and decision: If affected individuals fall within GDPR scope, Article 33 requires supervisory-authority notification without undue delay and, where feasible, within 72 hours of awareness unless the breach is unlikely to create risk. Article 34 requires direct communication without undue delay where high risk is likely. My assessment is that the combination of hardware-wallet ownership, purchase value, identity, and home address makes targeted phishing, impersonation, coercion, and physical-security harm reasonably foreseeable; Keystone should therefore notify affected customers immediately and should not wait for demonstrated financial or physical harm. It should document when legal “awareness” arose, preserve Shopify/API evidence, identify customer jurisdictions, file applicable regulator notices, and supplement notices as scope develops. US state duties cannot be determined without customer residence and entity details because triggers vary by state.

Customer action: Treat unsolicited calls, messages, visits, or purported law-enforcement contacts as hostile until independently verified through an official number. Never disclose a seed phrase, PIN, private key, or screen-sharing access; do not move assets because an inbound caller instructs you to; preserve suspicious messages and report them to Keystone and local authorities. Customers with unusually valuable holdings or credible threats should review home-address exposure and physical-security arrangements. Urgency is justified by foreseeable targeting, but there is currently no basis to tell every customer that their wallet or funds were compromised.