Series — PHP php2shell Critical Bug (1 of 3). Read in order: 1) What the bug is (this post) → 2) Server & security impact → 3) How to prevent & patch.
Introduction
In October 2026, the PHP project released emergency security updates for a pair of critical flaws nicknamed php2shell. Agencies like CISA urged immediate patching because, under the right conditions, an attacker does not need a login to try to run code on a vulnerable PHP server.
This Part 1 explains the issue in plain language: what broke, which CVE IDs to track, who is affected, and what fixed versions look like. Parts 2 and 3 cover impact and prevention. This series will not teach exploit steps—only enough understanding to take the risk seriously and patch safely.
What is the php2shell bug?
php2shell is the informal name used for two related critical vulnerabilities in PHP core:
- CVE-2026-109618 — remote code execution risk tied to out-of-memory (OOM) handling / memory corruption
- CVE-2026-109619 — remote code execution risk tied to stale request state / use-after-free style memory problems
Both sit deep in PHP’s engine—areas nearly every web request touches: memory management and error handling. That is why the impact is so broad. This is not a bug in one Laravel package or one CMS plugin. It is in PHP itself.
Public severity ratings for these issues are in the critical range (reported around CVSS 9.2). Government and vendor advisories treated them as “patch now” events.
What went wrong (plain English)
CVE-2026-109618 — OOM corruption path
PHP has a memory limit. When a request runs out of memory at an awkward moment, PHP aborts that request path. Researchers and the PHP security team found that an allocation failure could interrupt work while internal request data was only partly initialized. Later cleanup could treat that incomplete/invalid state as if it were valid—corrupting memory in a dangerous way.
In short: a crafted request that forces the wrong kind of memory failure can leave PHP’s internals in a bad state that attackers may abuse for code execution.
On Apache with mod_php, advisories note this can be triggered by an unauthenticated HTTP request before application code runs. That is especially serious: your Laravel middleware, WordPress plugins, or custom auth never get a chance to help.
CVE-2026-109619 — stale global / request state
The second issue is related in spirit. A fatal error at the wrong point could leave internal pointers or state referring to memory that belonged to an earlier request. A later request handled by the same PHP worker could then touch that freed/stale state.
In short: one bad request can poison worker memory; the next request may inherit danger. Advisories confirmed crashes and demonstrated remote code execution against real-world setups in research conditions.
Who is affected?
If your server runs PHP to serve web requests, treat yourself as in scope until you verify a patched version.
Advisories list common SAPIs / setups, including:
- Apache mod_php (called out as highest risk)
- PHP-FPM
- php-cgi
- FrankenPHP
- LiteSpeed
That covers a huge share of real hosting: shared hosts, VPS, Docker images, Laravel Forge/Ploi-style servers, XAMPP-style stacks moved to production, and many CMS appliances that quietly bundle PHP.
Version picture (high level)
- Fixed releases announced: PHP 8.5.12, 8.4.27, 8.3.36, 8.2.35
- Older than those patch levels in the 8.2–8.5 lines: treat as vulnerable until upgraded
- PHP 8.1 and earlier: end-of-life from the PHP project’s perspective for this fix—upgrade to a supported branch or rely only on a vendor/LTS backport if your distro provides one
Always confirm with php -v (CLI) and your web SAPI’s reported version (they can differ).
Why this bug is different from a “normal” app CVE
- Unauthenticated risk — attacker does not need a valid user account
- Engine-level — patching one plugin is not enough; you must update PHP
- Before app logic (especially mod_php) — framework hardening may never run
- Wide install base — PHP still powers a large portion of the web
- PoC interest after disclosure — once details and proof-of-concepts circulate, unpatched internet-facing servers become easy targets for scanners
That combination is why CISA and other national CERTs pushed emergency guidance within days of disclosure.
Timeline (useful context, not gossip)
- Related OOM concerns were studied earlier; full RCE impact became clearer through 2026 research and audits
- 21 Oct 2026: PHP released patched versions; public advisories followed
- Nicknamed php2shell in community and government materials
- A separate later issue (CVE-2026-115560) was also discussed around the same period with a different, narrower configuration path—do not confuse it with the main php2shell pair, but do keep reading official advisories as they update
What this Part 1 is (and is not)
This post is: a clear map of the bug, CVEs, affected surface, and why it matters.
This post is not: a how-to-exploit guide. We will not publish payloads, reproduction steps, or attack recipes. Responsible coverage means helping owners patch—not helping attackers.
Quick checklist from Part 1
- Track CVE-2026-109618 and CVE-2026-109619 (php2shell)
- Assume web-facing PHP is at risk until patched
- mod_php is especially urgent; FPM and others still matter
- Target fixed builds: 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35 (or newer in that branch)
- EOL PHP (8.1 and older) needs upgrade or vendor-supported backport
Conclusion
php2shell is a critical PHP-core problem: bad memory and request-state handling can open a path to remote code execution without a login. Because the flaws live under nearly every request, the correct response is not “wait and see”—it is identify PHP everywhere you run it, then move to a fixed release.
Next: Part 2 — how this bug affects servers and security.
Series navigation: You are on Part 1 · Next: Part 2 · Then: Part 3
