PHP2Shell: Two Bugs That Turned Requests Into Shells [Under the Hood]

analyst@unixshadow: ~/php2shell/analysis.log
analyst@unixshadow:~$ explain php2shell # two bugs, no patch for most of the internet, shells for anyone who asks nicely

PHP2Shell
Two Bugs That Turned Requests Into Shells

In October 2026, two unauthenticated remote-code-execution flaws were disclosed in the PHP interpreter itself. No login, no plugin, no upload form: a crafted request to any PHP application could hand the attacker a shell. The nickname is the researchers’ exploit name. The CVE IDs are what matter.

# the bugs — two flaws, one interpreter, zero authentication
CVE-2026-109618

class: memory corruption in out-of-memory handling, at request startup
trigger: a request that pushes PHP’s startup path into its OOM branch
result: corrupted interpreter state, shaped by the attacker into code execution
The dangerous detail is when it fires: request initialization, before any of your application code runs. Your framework, your auth checks, your WAF rules inside the app — none of them get a say, because the bug is underneath all of them.
CVE-2026-109619

class: use-after-free
trigger: a request that frees a piece of interpreter memory and then keeps using it
result: code execution — plus leakage of other requests’ memory contents
The second bug is arguably uglier: it does not just run code, it can read across requests. On a shared host or a busy application server, that means one attacker’s request can brush against another user’s data in memory.
Note on scope: this post describes the flaw classes and the fix. It deliberately contains no exploit code, payloads, or reproduction steps. The public proof-of-concept already exists; nobody needs another copy.
# who is affected — the version table is the whole story
vulnerable: PHP 5.4 through 8.1, plus unpatched 8.2 / 8.3 / 8.4 / 8.5 — essentially every PHP in widespread use
fixed: 8.2.35, 8.3.36, 8.4.27, 8.5.12 (released 21 Oct 2026) — and nothing else
stranded: no official binary release for 8.1 and older — PHP published source-only backports for 7.4, 8.0, and 8.1, and some distributions ship patched packages, but 7.3 and older get nothing from the project
That last line is the story. PHP’s supported branches got fixes within days. Older branches got source-only backports at best — useful if you build from source or your distro ships a patched package, but no official release. For most hosts still running 7.4 or 8.1, the practical fix is still to leave those versions.
analyst@unixshadow:~$ php -v # the one command that tells you which side of the table you are on
if it prints 8.2.35+, 8.3.36+, 8.4.27+ or 8.5.12+: patched. Stay current.
anything else, especially 7.x or 8.1: vulnerable, with no official binary fix. Plan the upgrade, not the workaround — unless your distro ships a patched package.
# in the wild — this one did not stay theoretical
honeypots: Amazon’s MadPot sensors recorded an exploitation attempt on Oct 17, before the fix shipped
at scale: Cloudflare reported millions of exploitation attempts against its customers
public: a working proof-of-concept circulated, and independent researchers confirmed exploitation
KEV: not CISA KEV-listed as of Oct 23, 2026
The gap between disclosure and mass exploitation was measured in days, not months. That is the normal tempo now for unauthenticated RCE in a ubiquitous runtime: assume scanning started before you finished reading the advisory.
# what to do — in order of honesty
1. Upgrade PHP to a patched release on a supported branch. This is the fix. Everything else on this list is a delaying tactic.
2. If you cannot upgrade yet, filter at the edge: a WAF or reverse proxy blocking the known malicious request shapes buys time. It is not a patch, and it will not hold forever.
3. If you are on an end-of-life branch, the upgrade is also a migration: newer PHP breaks old code. Budget for compatibility testing — especially plugins and themes written for the PHP 5/7 era.
4. Check what you actually run. Shared hosts, control panels, and old VPS images all hide PHP versions. php -v on the box, or your host’s panel, is the only answer that counts.
# the bigger lesson — runtimes are infrastructure, and infrastructure rots
PHP2Shell is not really a story about two bugs. It is a story about the long tail: millions of servers running interpreters whose vendors stopped patching them years ago, kept alive because the application on top still works. The application working is not evidence the stack is safe. Every EOL runtime is a countdown to the next disclosure that has no fix — and this time the countdown ran out in public, at scale, in days.
If your stack includes an end-of-life interpreter, language, or framework, the question is not whether it will have an unpatched critical flaw. It is whether you will have migrated before that flaw is found.
Sources (public, at time of writing): PHP.net security announcements (fixed versions, 21 Oct 2026); watchTowr Labs analysis; Cloudflare exploitation reporting; Amazon MadPot honeypot observations. All terminal examples above are genericized illustrations, not output from any real system.
Series: Under the HoodStatus: Published 25 Oct 2026

Scroll to Top