Halloween brought a vulnerability with a costume. PHP2Shell is the name circulating for a pair of critical CVE records in core PHP, CVE-2026-109618 and CVE-2026-109619, both yielding unauthenticated remote code execution. The name is doing a lot of work. A good name gets a bug on the CISO's phone before the advisory is even readable—and in this case, the branding literally arrived before the facts, when an embargoed proof-of-concept video and early container diffs leaked on October 20 ahead of the coordinated release.

Now that the dust has settled from the October 21 emergency release, let's separate the verified facts from the social-media rumor mill. Both vulnerabilities live in the C code of the Zend Engine itself and affect every version of PHP from 5.4 through 8.5.11. Discovered independently in August by researchers at Calif (with OpenAI) and Wiz Research using AI-assisted code auditing, both flaws carry an official CVSS v4.0 score of 9.2:

• CVE-2026-109618 (Out-of-Memory Corruption): When a crafted request exhausts memory_limit mid-parse, PHP aborts via longjmp() before internal structures are fully initialized, tricking the cleanup routine into freeing uninitialized memory. Against Apache mod_php, a single unauthenticated request can trigger RCE before a single line of application code runs.

• CVE-2026-109619 (Stale Global State): After a fatal error, request-owned pointers can survive pointing to freed memory. The next request handled by the same persistent worker (such as PHP-FPM) reuses that poisoned state—most notably via the default-enabled session.upload_progress.enabled setting.

In the first 48 hours of a named bug, the story always has three layers: what the official advisory says, what the researchers' write-ups say, and what a thousand panicked reposts say. CISA's Known Exploited Vulnerabilities (KEV) catalog () remains the sober signal here. While honeypot networks from Amazon, Cloudflare, and Arctic Wolf have already caught opportunistic scanning and botnet probes, CISA noted in its October 21 alert that it had not yet confirmed successful breaches in the wild, and neither CVE has been added to KEV yet.

What we can analyze with total confidence is what happens next, because the post-exploitation playbook never changes. Whether an attacker uses PHP2Shell to run commands directly in memory (MITRE ATT&CK T1190) or drops a persistent web shell (T1505.003, ), the payload runs as the web server's identity. And in far too many shops, that identity is a quietly powerful service account with a database password sitting in a config file next to it.

That is why an IAM publication is writing about a PHP bug. The exploit is the entry. The identity is the prize. Once an attacker is executing as www-data or the FPM worker pool user, the questions that decide whether this is a bad afternoon or a bad quarter are all identity questions:

• What credentials can that process read? Database users, API keys, OAuth client secrets, and cloud instance roles reachable through the metadata endpoint.

• What can those credentials do? A database user that only needs SELECT on three tables but holds DBA because "it was easier in 2019" turns a compromised worker into a full data breach.

• What does the web host's own identity have? An over-scoped IAM role attached to the compute instance is the fastest route from one box to the whole cloud account. AWS documents instance metadata hardening (IMDSv2) for exactly this reason ().

• Would you even see it? Compromised workers are noisy if you log process behavior and silent if you only watch HTTP logs. Outbound connections from a web server to unfamiliar hosts, new files in web-writable directories, and PHP workers spawning /bin/sh, curl, or wget are cheap, high-signal detections.

PHP gives you configuration levers that narrow the exposure while you test the patch (). For PHP2Shell specifically, setting session.upload_progress.enabled = 0 and (on PHP 8.5) fatal_error_backtraces = 0 closes the most common CVE-2026-109619 paths. Locking down disable_functions (exec, shell_exec, system, passthru) and open_basedir is still good hygiene against opportunistic PHP payloads—though because PHP2Shell corrupts memory in the underlying C engine, a sophisticated exploit can bypass php.ini restrictions in memory. OS-level containment (SELinux, AppArmor, and strict cgroup v2 memory limits) is where the real boundary lives.

On the identity side, the standing advice is unglamorous and correct. Give the web tier the smallest set of permissions it needs, rotate the secrets it holds, move those secrets out of flat .env files into a secrets manager with short-lived tokens, and treat the web server's service account as a principal to be audited like any human admin. Service accounts do not complain in exit interviews, so nobody reviews them. That is the whole problem.

Here is the encouraging part, and I mean it. Every bug with a spooky name is a free tabletop exercise. You do not need to wait for the next CVE to answer: "If a stranger ran code on our PHP tier tonight, what would they get, and would we know?" If your honest answer makes you wince, congratulations: you just found the actual vulnerability, and it did not need a CVE number.

Update to PHP 8.5.12, 8.4.27, 8.3.36, or 8.2.35 (and if you are still running End-of-Life PHP 8.1 or 7.x, recognize that upstream patches aren't coming). Watch CISA KEV. In the meantime, shrink what the web tier can reach. The costume will be gone by Monday. The over-privileged service account will still be there, unless you deal with it.