You Cannot Patch What You Forgot: PHP2Shell, LiteLLM, and Governance

Your site can look patched on paper and stay open in real life. That gap opens when nobody can list what actually runs it. Two failures on October 21, 2026 made that gap public. One hid inside a language runtime. One hid inside a trusted software release.

What is PHP2Shell, in plain words?

PHP runs a huge share of public websites. WordPress sites are one common example. Vendor portals and old internal tools count too. The flaws sit in PHP itself, not your code. RCE means remote code execution. It means a stranger runs code on your server.

CVE-2026-109618 breaks when PHP runs out of memory mid request. It leaves request data half built, then cleans it up. Cleanup treats that bad data as if it were real.

CVE-2026-109619 keeps state from one request too long. Its memory is freed, but later requests may use it. That path can leak memory and run code too.

Both flaws run before your app code starts. A login page cannot stop either one.

How do you fix PHP2Shell?

Update to PHP 8.5.12, 8.4.27, 8.3.36, or 8.2.35. Restart every PHP worker after the update. Rebuild every container image that ships PHP.

On PHP 8.1 or older, move to a supported line. A vendor backport is a bridge, not a home. No setting or firewall rule fully fixes this.

The Cybersecurity and Infrastructure Security Agency, or CISA, says patch now. Read the CISA alert for the full patch order. CISA says take unpatched public systems offline if needed.

Then hunt for signs that someone got there first. Look for very large form posts in your logs. Look for memory errors at request start. Look for PHP workers starting shells or downloads.

What happened to LiteLLM?

LiteLLM is a proxy that routes app requests to AI providers. One proxy can hold keys for many providers. That makes it a vault and a target at once.

Version 1.107.0 shipped with a credential stealer. It also shipped with a loader for remote code. Three files landed in the root of site-packages. Their names were cook.pth, cook.py, and sitecustomize.py. Python runs those files each time it starts. Your app never has to import LiteLLM for harm.

The source code did not tell the whole story. The shipped wheels held files the source lacked. A clean code review could miss this attack.

LiteLLM says stolen GitHub tokens drove the release. One account started the release run. Another account approved that same release. That is a control failure, not bad luck.

This incident has no CVE number of its own. The release itself was hijacked, not just the code. The bad Docker tags went past 1.107.0 alone. Latest, main-latest, and main-stable pointed there too. Floating tags mean you may not know you took it.

What do you do if you ran LiteLLM 1.107.0?

Treat any host that ran it as compromised. This is an incident, not a normal upgrade. Rebuild the host or image from a clean base. Pin LiteLLM to 1.106.2, and pin Docker by digest.

Rotate every secret that host could reach. That means cloud keys and provider keys. It also means build secrets and login keys.

Check for the /tmp/.pc_once marker files. Check for /tmp/remote_code_loader.lock as well.

Older LiteLLM flaws add one more reason to move. SQL is the language apps use to query databases. CVE-2026-42208 is a SQL injection in the key check path. The National Vulnerability Database, or NVD, holds that record. CISA lists that flaw as known exploited.

Why is this a governance problem?

Governance is not a binder on a shelf. It is a true map of how work really runs. You cannot govern a system you only half know.

You need four maps, and each must stay current. The runtime map lists languages and server versions. The dependency map lists packages, images, and digests. The secret map lists keys and what each key opens. The data map lists what data flows through daily. It also names who owns each hard call.

If any map is a guess, governance is a guess.

Which compliance rules does this touch?

NIST is the National Institute of Standards and Technology. Its control catalog is NIST SP 800-53 Revision 5.

Inventory is control CM-8 in that catalog. In NIST 800-171, it is practice 3.4.1. Flaw repair is control SI-2 and practice 3.14.1. Scanning is control RA-5 and practice 3.11.2. Change control is CM-3 and practice 3.4.3. Supply chain checks live in the SR control family. Incident work is control IR-4 and practice 3.6.1.

Your System Security Plan, or SSP, tells the system story. Your Plan of Action and Milestones, or POA&M, lists open gaps. An old PHP server belongs on the POA&M list. It needs an owner, a date, and a real plan.

Defense work adds one hard clock on top. DFARS is the Defense Federal Acquisition Regulation Supplement. Its clause 252.204-7012 can require a report in 72 hours. It also requires keeping images and logs for 90 days. You cannot meet that clock without the four maps.

What proof should you keep after patch day?

Patch day ends with proof, not hope. Keep the old version and the new version. Keep the restart time and the scan after it. Keep the image digest you now run in production. Keep the list of secrets you rotated, with dates. That set of records is the real audit trail.

PolicyCortex does not patch PHP or clean LiteLLM hosts. That limit is worth saying out loud. The habit behind it is what transfers. PolicyCortex collects evidence from live Azure configuration and ties each control to the setting that met it. That is the same habit these incidents demand. Proof from the system itself, not from memory.

Sources

• CVE record, CVE-2026-109618, CVE Program. https://www.cve.org/CVERecord?id=CVE-2026-109618
• CVE record, CVE-2026-109619, CVE Program. https://www.cve.org/CVERecord?id=CVE-2026-109619
• Critical Vulnerabilities in PHP Require Immediate Patching, CISA, October 21, 2026. https://www.cisa.gov/news-events/alerts/2026/10/21/critical-vulnerabilities-php-require-immediate-patching
• CVE-2026-42208 record, National Vulnerability Database, NIST. https://nvd.nist.gov/vuln/detail/CVE-2026-42208
• LiteLLM Compromised, Steals Credentials, Wiz, October 21, 2026. https://www.wiz.io/blog/litellm-compromised-steals-credentials
• LiteLLM PyPI Package and Docker Images Compromised, Socket. https://socket.dev/blog/litellm-compromise
• NIST SP 800-53 Revision 5, Security and Privacy Controls. https://doi.org/10.6028/NIST.SP.800-53r5
• DFARS 252.204-7012 requirements summary, Koop. https://www.koop.ai/blog/dfars-252-204-7012-requirements