Two Critical Flaws in the PHP Engine: CVE-2026-109618 and CVE-2026-109619 (PHP2Shell)
PHP shipped emergency fixes today for two critical flaws in its core engine that let an unauthenticated attacker run code on a web server. If you run PHP anywhere, the move is the same: upgrade to PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35 now.
The flaws are tracked as CVE-2026-109618 and CVE-2026-109619 and collectively named PHP2Shell by researchers.
How Oligo Scopes and Detects PHP2Shell
PHP2Shell corrupts memory inside the PHP engine itself, and the fix is upgrading PHP. Oligo covers what the patch can't: where you're exposed today, and whether anyone is exploiting it right now to detect and block in real time.
Runtime Protection: catch exploitation while you patch. Oligo's research team reproduced the PHP2Shell exploit, and our runtime protection detects it using events its sensor already collects. When a PHP web server worker spawns a process during multipart request parsing, before any application code runs, Oligo flags it as critical. In our reproduction, an Apache worker launched a shell, and Oligo caught it with the full process lineage.
That's the signal application logs miss, and it matters most on the end-of-life and forgotten systems that won't be patched imminently.
Zero-day response: PHP2Shell leaked on October 20, and the fix didn't ship until today. Because the flaw is in the PHP engine itself, the guidance is simple: anyone running PHP should upgrade. The hard part is knowing where PHP runs. Oligo's runtime view shows which workloads are actually running PHP in production
The broader point. Patching answers one question. The rest depend on a real-time view of what's running, what it's doing, and what changed while you were exposed. That's the gap runtime security closes.
You Don't Need a CVE to Catch an Exploit
Most security programs start with the CVE: wait for the advisory, match versions, patch. Attackers don't wait for any of that. An exploit has to do something on the server to matter, and that activity looks the same whether the CVE was published this morning or hasn't been discovered yet.
The patch is the fix. But PHP2Shell will sit on end-of-life and forgotten servers for months, and those systems need protection that doesn't depend on a patch at all.
Today's stopgaps only cover part of the problem. Web application firewall vendors moved quickly to ship rules that filter known PHP2Shell requests at the edge. PHP's interim settings close the confirmed attack paths. Both are worth deploying. Both also have limits: PHP says its settings don't block other variants of these bugs, and a request rule only matches the request shapes it was written for.
Oligo detects the exploit by what it does once it lands. A PHP web server worker has no reason to spawn a process while it's still parsing a multipart upload. When it does, Oligo flags it as critical, whatever the PHP version, patch status or request shape. That makes it a backstop for exactly the systems a patch won't reach this week.
CVE Breakdown
PHP reuses worker processes across requests. Between requests, it tears down internal state and starts fresh. Both CVEs break that cleanup.
The trigger is a fatal error, particularly an out-of-memory error, during session upload-progress handling, which runs before any application code. The fatal error path frees the request's memory but does not clear several engine-global pointers that still reference it.The worker survives and accepts the next connection with those stale pointers intact.
On a subsequent request, the attacker's data reclaims the freed memory. When PHP follows a stale pointer, it reads attacker-controlled bytes as its own internal structures, leading to memory disclosure, code execution, or both.
Who Is Exposed
Every PHP installation that serves web requests is affected, on every version back to PHP 5.4. That includes PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. Setups running mod_php carry the greatest risk.
The hard part is finding it all. PHP runs well beyond the obvious websites: vendor appliances, hosting control panels like cPanel and Plesk, Windows software that bundles it, and internal tools nobody has touched in years.
What to Do Now
Patching is the only complete fix. Everything else buys time.
- Find every PHP install. You can't patch what you can't see. Map which PHP versions are actually running in production, including PHP bundled in appliances, control panels and forgotten internal tools.
- Upgrade, internet-facing systems first. Move to PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35 from php.net or your distribution's updated packages. If you install from rpms.remirepo.net, switch to distribution packages or build from source. That repository won't have updates today.
- Plan for end-of-life versions. PHP 8.1 and earlier get no official release. Use PHP's source backports for 7.4, 8.0 and 8.1, an LTS vendor, or upgrade. PHP 8.2 reaches end of life on December 31, 2026.
- Watch for post-exploitation activity. These flaws execute below the application layer, so application logs show little. Runtime monitoring catches what logs miss: a PHP worker spawning a shell, pulling down a tool, or connecting somewhere new.
- Rotate secrets on exposed servers. If an internet-facing server ran a vulnerable version, assume credentials held in PHP worker memory could be exposed.
The Takeaway
Patch PHP today, starting with what faces the internet. Then find the PHP you didn't know you had, and check what those servers did while they were exposed.
Stop modern attacks and keep your business moving
