PHP2Shell LiteLLM and Railway show why patching alone is not enough

Research checked October 23, 2026. This briefing covers the disclosures and emergency response activity surrounding October 21 and 22, with earlier incidents clearly dated and an October 23 PHP follow-up.

The security stories circulating on October 22 were serious. They also required different responses. A vulnerable runtime needs patching. A malicious software release may require a clean rebuild. An exposed API key needs revocation at the company that issued it. An abused cloud application identity requires investigation beyond a password reset.

Treating all of these as one giant hack obscures what an organization actually needs to do.

Our review covers 23 incidents and advisory groups across hosting, AI infrastructure, business applications, certificate trust and widely deployed software. These are selected, sourced items, not a count of successful attacks on one day. Some events happened weeks earlier. There is no established common actor linking the entire list.

For business leaders, the immediate question is which affected component or credential exists in their environment, what it can reach, and what evidence will demonstrate that the response is complete.

The wider list and the dates that matter

The dates below identify incident windows, disclosures or material updates. A published vulnerability is not, by itself, proof that a customer was compromised. Vendor notices linked in the first column contain the detailed scope and latest recovery instructions.

This list includes older backlog and adjacent disclosures because teams were responding to them during the same period. It does not establish 23 simultaneous breaches. Several entries are precautionary security releases, while others involve confirmed malicious activity.

PHP2Shell requires runtime work and an exposure review

PHP's October 21 releases address CVE-2026-109618 and CVE-2026-109619. The fixed releases were 8.2.35, 8.3.36, 8.4.27 and 8.5.12. Distribution-maintained packages may carry backports, so validate the vendor advisory as well as the displayed version. Updating a CMS or its plugins does not necessarily update its PHP interpreter. Confirm the running workers after the change. PHP release notices

Maintainer research demonstrated unauthenticated HTTP code execution in affected configurations. Risk varies with the PHP execution mode and reachable application paths. PHP's large deployment footprint does not mean that the same percentage of websites was breached.

AWS observed attempted exploitation in its honeypots beginning October 17 and more activity around public disclosure. AWS also cautioned that the early attempts did not establish whether attacks would succeed against real production systems. That distinction supports urgent patching and investigation without inventing a global victim count. AWS threat analysis

October 23 update: PHP described an additional unlikely RCE path, CVE-2026-115560, involving runtime session-serializer changes and upload progress. Its recommended setting, `session.upload_progress.enabled=0`, was already included in the October 21 mitigation guidance. Teams that applied that setting need no further action for this follow-up; others should review the current notice pending the next bugfix release. PHP informational advisory

LiteLLM demonstrates how a trusted release can carry malware

LiteLLM's October 21 incident affected the public 1.107.0 release. The vendor identifies malicious PyPI wheels available from 11:39:51 to 13:23 UTC, with affected Docker tags continuing until 14:20 UTC. Its private enterprise registry was outside this incident's scope. These times help identify affected builds; a cached malicious artifact can remain dangerous after removal from the registry. LiteLLM incident report

SafeDep's analysis found a Python startup hook and remote-code loader installed outside the ordinary package directory. Merely uninstalling LiteLLM may leave the added files behind. Starting Python, including through pip, can retrigger the payload. Initial containment and evidence collection should therefore use a clean administrative environment, following the maintainer's recovery instructions. SafeDep analysis

The published GitHub source tag was clean. The vendor says compromised developer credentials enabled a workflow to build from a lookalike repository and sign the poisoned artifacts. Release signatures did not establish that the artifacts matched the intended source. Initial access remained under investigation.

For affected organizations, the work extends to everything the environment could access: cloud roles, provider keys, source-control tokens and proxy-database credentials. Datadog recommends rotating affected credentials from a clean machine and reviewing their subsequent use. The prior March LiteLLM incident is separate; a link between the two had not been established. Datadog Security Labs

Railway and other hosted services expose the limits of a dashboard reset

Railway disclosed possible unauthorized access to encrypted environment variables and decrypted contents for some variables. It recommended precautionary rotation for all users while investigating scope. That recommendation is broader than a finding that every customer was compromised. Railway disclosure

The October 22 recovery guidance explains another distinction. Railway reset bucket credentials and GitHub credentials it held, but registry tokens removed from Railway could still work at GitHub until revoked there. Services also needed redeployment to pick up new bucket credentials. Restoring deployments and completing credential recovery are separate tasks. Railway recovery guidance

Zeabur's October 19 report concerns an October 14 and 15 intrusion. Its account describes long-lived administrative credentials, exposure of environment-variable records, and access to infrastructure. Its 3,218,965 environment-variable records are not 3.2 million users. Recovery instructions differ by service and hosting model. Zeabur incident report

OpenCode described a breach of an older hosted Console system affecting 1.4% of Console users. The local open-source app and CLI path were outside the disclosed incident, according to the company. A local user who separately stored the same provider key in Console could still need to replace that key. Company statement, TechCrunch reporting

For each provider notice, build a credential map: who issued the secret, where it was copied, what it authorizes, whether old access has been revoked, and which running services still hold it. Changing a value in one dashboard is not evidence that all copies or sessions are invalid.

Cloud application identities and certificate trust need separate checks

Microsoft attributes the ConnectWise campaign to Storm-0940 and describes ARTEX-assisted activity using compromised application identities. An organization can require MFA for employees and still have a highly privileged cloud application that operates without an interactive employee login.

Microsoft reported attempts against more than 2,250 tenants, with follow-on activity in multiple environments. That figure is not a count of confirmed data-theft victims. Review service-principal sign-ins and subsequent credential, privilege and data-access events rather than treating an application installation or one sign-in as a complete incident conclusion. Microsoft research

The eMudhra issue concerns weak intermediate certificate keys. Mozilla blocked affected certificates and updated its trust protections; this does not demonstrate theft of the root private key. Browser updates alone may not refresh every application, container or embedded trust store. Mozilla response

Google scheduled removal of emSign ECC Root CA - G3 from the Chrome Root Store for October 27 PDT. Organizations using affected certificate chains should check replacement requirements and application trust updates. Do not bypass certificate validation to restore a failing connection. Google response

A patch must match the actual product and deployment

Node.js's October 21 security release included Brotli, DNS and TLS issues and certificate-store updates. Fixed supported releases were 22.23.4, 24.22.1 and 26.12.1. A repository lockfile does not prove a deployed container uses one of those runtimes. Node.js advisory

GitLab's October 21 critical release addressed CVE-2026-110264, rated 10.0. Its notice distinguishes self-managed installations needing upgrades from GitLab.com, which was already patched. A GitLab security headline is not evidence that all hosted GitLab repositories were breached. GitLab release

Some fixes also require application changes. The MCP bearer-token advisory adds an audience-validation setting that is off by default. The maintainer explains the configuration and verifier changes required to enforce it. Separately, shared HTTP server/transport instances could mix clients' messages. Package updates and integration review both matter. MCP authentication advisory, MCP isolation advisory

The same discipline prevents misleading recovery claims elsewhere. Rank Math's affected PRO release does not mean the free plugin was poisoned. Siemens' advisory does not establish a breach of its update channel. A PAN-OS management-interface flaw with authenticated, high-privilege prerequisites should not be described as an unauthenticated attack against every firewall. The linked vendor notices define those differences.

What the AI evidence does and does not establish

AI appears on both sides of this period's security work. The PHP Foundation describes AI-assisted research and validation alongside human investigation and patching. Microsoft documents ARTEX-assisted offensive operations. Neither finding proves that AI caused every incident in the wider list. PHP Foundation account, Microsoft research

Aeon expects AI-assisted incident pressure to increase as operators apply capable tools to more targets. This is our risk assessment, not a measured forecast of a specific incident count. The response should include faster defensive investigation and verification, with authorization, least privilege and human review retained.

No evidence reviewed for this briefing establishes one attacker behind all the events, universal compromise of the affected ecosystems, or a reason to shut down the internet. Unconfirmed loss figures and claims of autonomous agents breaking into everything do not improve a response plan.

A practical response plan for the next working day

First, appoint an owner and preserve relevant evidence. Keep deployment manifests, package versions and digests, vendor notices, identity logs and credential-change timestamps. Where compromise is plausible, coordinate containment with evidence preservation. SiteGuard explicitly warns that patching can erase diagnostic traces; recovery order can matter. SiteGuard notice

Second, match the advisories to real assets. Include managed runtimes, build runners, developer environments, older containers, backup integrations and dormant applications. Record both the version and the configuration. An asset with no match should be documented as such rather than patched blindly.

Third, deal with secrets at their issuers. For exposed credentials, revoke old access promptly, then issue replacements from a clean administrative environment and update consumers. Where continuity requires a short overlap, make it explicit and time-limited. Check whether sessions, refresh tokens or added application credentials require separate invalidation. Do not place replacement secrets on an untrusted host.

Fourth, verify running systems and look for use of compromised access. Confirm deployed runtime versions, artifact identities and restart completion. Review cloud audit events, identity changes, source-control activity, provider billing and relevant application access. A working homepage and an unchanged invoice do not prove that a key was never used elsewhere.

Finally, record closure criteria and remaining uncertainty. Useful evidence includes an invalidated old credential, a running patched process, a cleanly rebuilt host, reviewed logs for a stated time window, and an accountable owner for any gap. Consult the appropriate legal, privacy and insurance advisers where evidence indicates exposure requiring their review.

How Aeon can support clients

Aeon CyberGuard can help turn a broad advisory list into an environment-specific assessment: identify relevant systems and trust relationships, review authorized attack paths, prioritize corrections, and verify fixes. We can also help clients assemble vendor evidence and a clear record of remediation decisions.

For AI deployments, that includes gateways, agent permissions, MCP servers, RAG data paths, provider credentials and deployment pipelines. Work is scoped and authorized, with human validation. An assessment is not a certification, a guarantee of safety, or a substitute for specialist incident response when an active compromise requires it.

If these notices touch your organization and you need help deciding what to examine first, contact Aeon or review CyberGuard. Email info@airiskmanagement.ca.

The useful outcome is a tested answer to what was exposed, what authority it carried, what has been corrected, and what remains unknown.