PHP2Shell and LiteLLM compromise demand immediate security action

Two security emergencies disclosed on October 21 require different responses. PHP2Shell is a set of flaws in the PHP runtime; the LiteLLM incident is a compromise of distributed software artifacts. Both can put credentials at risk, but patching a runtime and responding to a malicious release are different jobs.

This expanded guide separates the affected components, explains the evidence, and gives teams a practical way to organize the response. Technical details were checked against vendor advisories and original research on October 22, 2026. LiteLLM’s investigation remains ongoing.

#First, identify which response you need

This table is an editorial response aid. It does not establish that any particular deployment was exploited.

#PHP2Shell: why application updates alone are insufficient

The vulnerabilities are in PHP itself. CVE-2026-109618 concerns corruption associated with out-of-memory handling. CVE-2026-109619 concerns stale global state persisting across requests. The advisories describe conditions that can lead to remote code execution.

In everyday terms, a request can fail while leaving behind internal state that a later request should never trust. The relevant boundary is inside the runtime, below the normal application code. Updating a WordPress plugin cannot replace a vulnerable PHP engine.

Wiz’s original research demonstrates unauthenticated code execution against representative WordPress, Drupal, and Joomla deployments. These examples illustrate the impact; the bugs are not limited to those products. Wiz also demonstrates disclosure of PHP process memory, potentially exposing passwords, tokens, and API keys without first executing code.

AI Socratic explanatory diagram. Exploitability varies with the runtime and deployment; the diagram summarizes the affected boundary rather than an exploit recipe.

#Which PHP versions contain the fixes?

PHP’s October 21 advisory lists these fixed upstream releases:

Distribution vendors may ship backported fixes under different package versions. PHP 8.1 and older receive no upstream updates; obtain an explicit vendor-supported fix or migrate. PHP identifies web-serving deployments including FPM, mod_php, CGI, FrankenPHP, and LiteSpeed as at risk. Configuration workarounds cover only particular paths: PHP says updating is the only complete remediation. Check the advisory and your vendor’s package notice.

Verification should identify the runtime actually serving traffic. The shell’s PHP binary may differ from an FPM pool, container, or managed-host runtime. Record the package or image deployed, the vendor evidence for both fixes, and confirmation that every serving instance has moved to the updated runtime.

#Watch: demonstrations from the original researchers

Wiz links these demonstrations in its research write-up. They show controlled test environments and help explain why the issue reaches beyond an individual CMS. They do not establish that your own site is exploitable or that it has been compromised.

The researchers’ PHP2Shell site also collects demonstrations and upgrade guidance.

#Patching and investigating are separate tasks

Amazon Threat Intelligence observed an attempt in MadPot telemetry on October 17, four days before disclosure. AWS cautions that the earlier attempt’s success against real systems is unclear. Its report also describes broad exploitation after disclosure.

That makes October 17 a useful minimum starting point for retrospective review, rather than assuming exposure began when the patch appeared. Preserve relevant web, PHP, process, and network evidence. Unexpected worker failures, new files, unusual child processes, or outbound connections warrant investigation in context; none is a standalone verdict.

Cloudflare’s response describes WAF protections and attempts to evade them. A protective edge rule is useful defense in depth, while the underlying runtime still needs its fix. Confirm that traffic cannot bypass the protected edge through an exposed origin.

#LiteLLM: the released artifact was the attack

LiteLLM’s incident report identifies 1.107.0 as compromised. PyPI wheels were available on October 21 around 11:39–13:23 UTC. Docker Hub tags v1.107.0, latest, main-latest, and main-stable were affected around 11:46–14:20 UTC; affected GHCR tags were unavailable by 13:51 UTC. The private enterprise registry was unaffected, according to the vendor.

Removal from a public registry does not remove copies from build caches, image mirrors, developer machines, or already running containers. Check what was actually installed or executed, rather than only what a tag points to today.

StepSecurity’s artifact analysis found extra startup files, including cook.pth, cook.py, and sitecustomize.py. They enable execution when Python starts, without an explicit LiteLLM import. The payload targets environment variables, cloud credentials, SSH keys, AI tool tokens, and LiteLLM proxy database keys. A separate component retrieves and executes remote code. The legitimate source tag lacks these malicious additions: the distributed artifacts came from a lookalike repository.

AI Socratic explanatory diagram, based on LiteLLM’s incident report and StepSecurity’s artifact analysis. A clean source tag alone does not verify a downloaded wheel or container.

#Contain before attempting an in-place upgrade

Do not start Python or pip inside a suspected affected environment before containment. LiteLLM warns that interpreter startup can trigger the malware again. Its report recommends rebuilding from trusted inputs, temporarily pinning 1.106.2, and rotating reachable credentials. Missing malware markers do not establish that an environment is clean. Follow the vendor’s recovery instructions for the current procedure.

For responders, organize the work into four evidence-backed steps:

1. Establish exposure. Use existing deployment records, lockfiles, image digests, registry audit history, and build logs from a clean system. Include CI runners and developer environments in the inventory.
2. Contain and preserve. Isolate suspected workloads and retain the artifacts and logs needed to reconstruct what ran and which identities were reachable. Coordinate this with your incident response owner.
3. Recover from trusted inputs. Replace affected environments with verified builds. Check caches and mirrors so the same poisoned artifact cannot re-enter through a rebuild.
4. Address credential access. Inventory identities and secrets the workload could reach. Revoke and replace affected credentials from a clean environment, then review their activity for unauthorized use.

This is an editorial work breakdown, not a substitute for the vendor’s incident-specific procedure. A version change addresses the software currently deployed; a credential investigation addresses what may already have escaped.

#Why artifact provenance matters

This incident illustrates a practical distinction between reviewing source and trusting a release. A project can have a clean source tag while a package registry distributes different bytes. Pinning an immutable digest helps identify those bytes, but does not itself establish they were built safely.

For future releases, teams should be able to answer: which source revision produced this artifact, which workflow built it, who could alter that workflow, and what evidence connects the approved source to the deployed output? Keep release privileges narrow and independent of routine development credentials. These are engineering lessons drawn from the incident, rather than claims that any single control would have prevented it.

#A useful handoff for web and AI teams

The response is easier to verify when each owner supplies concrete evidence:

Our assessment: both incidents deserve urgent attention, with distinct closure criteria. For PHP, verify runtime remediation and investigate earlier exposure. For LiteLLM, verify trusted recovery and complete the credential response. Avoid using a completed upgrade ticket as evidence that an earlier compromise has been resolved.

Expanded October 22, 2026. The LiteLLM incident discussed here is the October 1.107.0 compromise, separate from its March 2026 incident. Refer to the linked advisories for updates after this review.