
PHP2Shell CVE-2026-109618: Fix and Interview Questions
PHP2Shell (CVE-2026-109618 and CVE-2026-109619): affected versions, the fix, and five interview questions on memory safety and stale state.
- What happened: PHP shipped emergency fixes for CVE-2026-109618 and CVE-2026-109619, both CVSS v4.0 9.2.
- Who is affected: PHP web servers below 8.5.12, 8.4.27, 8.3.36 or 8.2.35.
- What to do now: upgrade, restart all workers, and restrict unpatched hosts.
- Interview angle: memory safety, error paths and stale state.
PHP2Shell is the name for two critical PHP remote-code-execution flaws, CVE-2026-109618 and CVE-2026-109619. Both are memory-corruption bugs reachable by web requests. PHP fixed them on 21 October 2026. Update to a fixed release and restart workers, because PHP says no mitigation is complete.
A use-after-free is a memory-safety bug where a program keeps using memory after it was released. The memory may now hold other data, so the program reads or writes something it does not own. In a web server, that can turn a crafted request into code execution.
PHP2Shell is back in the news. The IEEE Spectrum analysis published on 2 November sparked a large Hacker News thread. The advisory is older, but the lessons are fresh. This guide covers the fix and the PHP2Shell interview questions it prepares you for.
What changed and who is affected?
The PHP project published a security release on 21 October 2026. It covers two flaws, each rated CVSS v4.0 9.2. Per watchTowr, both affect all branches below the fixed versions.
| Branch | Fixed in |
|---|---|
| PHP 8.5.x | 8.5.12 |
| PHP 8.4.x | 8.4.27 |
| PHP 8.3.x | 8.3.36 |
| PHP 8.2.x | 8.2.35 |
| PHP 8.1, 8.0, 7.4 | No official release; vendor package or source backport |
| PHP 7.3 and older | No fix; upgrade |
According to BleepingComputer, risk covers PHP-FPM, Apache mod_php, php-cgi, FrankenPHP and LiteSpeed. It is highest for mod_php. The finders were Calif, OpenAI and Wiz, per the Calif write-up.
Exploitation is real. watchTowr says it observed attacks from 21 October and that CISA listed CVE-2026-109618 in KEV on 26 October. Its page shows conflicting KEV wording for the second CVE, so check CISA directly. Calif also reports pre-auth RCE was confirmed against several popular PHP applications, including WordPress and Drupal.
How does PHP2Shell work?
We keep this at advisory level. Per Calif, the first bug starts when PHP runs out of memory during request setup. A fatal error interrupts the work before cleanup completes. Later code then consumes half-built internal state.
- A request makes PHP exhaust memory while it registers request data.
- A fatal error stops setup partway.
- Internal structures stay inconsistent or dangling.
- Cleanup trusts them, so memory is corrupted.
The second flaw is about stale global state. State outlives the request memory it points to. The next request on the same worker can act on leftover data. Both are classic memory-safety failures in rarely exercised error paths.
A safe way to check your build is to list the version and the interim settings PHP named:
php -v
php -i | grep -E "memory_limit|session.upload_progress.enabled"
If the version is below your branch’s fixed release, you are exposed. Settings output alone does not prove safety.
What should developers do right now?
- Detect: inventory every PHP host and container image, including CMS servers and forgotten staging boxes.
- Patch: move to 8.5.12, 8.4.27, 8.3.36 or 8.2.35. On older branches use a vendor backport or upgrade.
- Restart: restart all PHP workers, as watchTowr advises.
- Verify: re-run
php -vinside the running container or service, not only on the build host. - Contain: restrict internet access to anything you cannot patch today.
- Layer, don’t rely: Cloudflare’s default WAF rules help, but sites that changed the upload-progress field name are not covered.
PHP is blunt on interim settings. Its advisory says “there are no complete mitigations, updating is the only safe choice.” Calif adds that removing the memory limit raises memory-exhaustion risk. For wider hardening, see our guide to Drupal security best practices.
Interview questions this update prepares you for
What is a use-after-free, and why is it dangerous?
A use-after-free happens when code keeps a pointer to memory after it was released. The allocator may hand that memory to something else, so reads can leak data and writes can corrupt it. Attackers shape what occupies the freed block to redirect execution. Languages with ownership rules or garbage collection prevent most of these bugs by design.
Follow-up they may ask: How does Rust’s borrow checker prevent this class of bug?
Why can running out of memory become a security bug?
Out-of-memory handling is a rarely tested error path. If a fatal error interrupts setup halfway, cleanup code may trust structures that were never fully initialised. Error paths need the same invariants as the happy path. Attackers deliberately trigger failures to reach this under-tested code.
Follow-up they may ask: How would you test error-handling paths such as allocation failure?
What is stale global state in a long-lived worker process?
PHP-FPM and mod_php reuse worker processes across requests. If global state outlives the request memory it points to, the next request can follow dangling references. This is why shared-nothing request isolation matters, and why a restart after patching matters too.
Follow-up they may ask: What does a process-per-request model trade away?
What is defence in depth, and where does a WAF fit?
Defence in depth layers independent controls so one failure is not fatal: patching, least privilege, network restriction, monitoring and filtering. A WAF blocks known patterns but cannot fix the underlying flaw. Cloudflare itself says its rules are an extra layer, not a replacement for the vendor fix.
Follow-up they may ask: Why can a WAF rule be bypassed by a simple configuration change?
How do you triage a critical CVE across many servers?
Start with exposure: internet-facing hosts first, then internal. Check whether it is in the CISA KEV catalog, which signals real exploitation. Inventory versions, patch in order of risk, restart workers, and verify. Document exceptions and compensating controls for anything that cannot be patched quickly.
Follow-up they may ask: What do you do when the vendor offers no fix for your PHP version?
The NexGismo verdict: I would treat this as a drop-everything patch for any public PHP server. My view is that the bigger lesson is old error paths, not PHP alone. If you are still on 8.1 or older, this is a good reason to plan the move our PHP 8.5 changes overview explains.
- PHP2Shell is two flaws, CVE-2026-109618 and CVE-2026-109619, both rated CVSS v4.0 9.2.
- Fixed releases are 8.5.12, 8.4.27, 8.3.36 and 8.2.35.
- PHP 8.1 and older have no official project fix.
- watchTowr reports exploitation in the wild since 21 October 2026.
- Restart all workers after patching; interim settings are not a complete fix.
Frequently Asked Questions
Is PHP2Shell being exploited in the wild?
Yes. watchTowr reports it saw exploitation from 21 October 2026, and says CISA added CVE-2026-109618 to its KEV catalog on 26 October. No threat actor attribution has been published. Treat unpatched internet-facing PHP servers as at risk.
Which PHP versions fix PHP2Shell?
PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 are the official fixes. PHP 8.1 and older get no project release, so use a vendor backport, PHP’s minimal source backports, or upgrade to a supported branch.
Does setting memory_limit=-1 protect me?
No. PHP states there are no complete mitigations and updating is the only safe choice. Interim settings reduce exposure to specific paths only, and Calif warns that removing the memory limit raises memory-exhaustion risk.
Does a WAF stop PHP2Shell?
Only partly. Cloudflare says its default WAF rules cover known attempts using PHP’s default upload-progress field name, but sites that changed that name are not covered. Cloudflare still recommends patching PHP.
Conclusion
PHP2Shell shows how a rarely tested error path can become remote code execution. Patch first, restart workers, and then use the interview questions above to explain the concepts clearly. Bookmark NexGismo for more security updates written for working developers.
Sources
- PHP.net — October 2026 security release
- GitHub — GHSA-w8hw-w9fx-j79w (CVE-2026-109618)
- GitHub — GHSA-6wmf-4rv5-p3rp (CVE-2026-109619)
- Calif — php2shell: A tale of two PHP remote vulnerabilities
- watchTowr — CVE-2026-109618 FAQ
- Cloudflare — protections against php2shell
- BleepingComputer — PHP ships emergency patches
- IEEE Spectrum — AI is forcing us to pay off 40 years of technical debt