PHP2Shell: Two Critical PHP Flaws, and the Controls That Decide Whether You’re Exposed

On October 21, 2026, the PHP project released emergency security updates for two critical vulnerabilities, now nicknamed PHP2Shell: CVE-2026-109618 and CVE-2026-109619. Both allow an unauthenticated attacker to run code on a web server, and both are rated 9.2 on CVSS v4.

PHP runs a large share of the web, including WordPress, Drupal, Joomla, Magento, and countless internal tools. These flaws sit in the PHP runtime itself, so a well-written application is still exposed if the server underneath it hasn’t been updated.

What happened

  • CVE-2026-109618: memory corruption when a request runs out of memory partway through processing. Crafted requests can trigger it, and on Apache with mod_php it can fire before any application code runs.
  • CVE-2026-109619: a use-after-free, where leftover state from one request points to memory that a later request on the same worker can reuse.
  • Affected deployments: PHP-FPM, Apache mod_php, php-cgi, FrankenPHP, and LiteSpeed. The PHP project rates mod_php as the highest risk.
  • Exploitation: Cloudflare and watchTowr reported exploitation attempts within hours of disclosure. At the time of writing, neither CVE was listed in CISA’s Known Exploited Vulnerabilities catalog, and no successful compromise had been publicly confirmed.
  • Timing: the CVE IDs leaked a day early, so the PHP team moved the release up. Attackers had a head start.

Which versions are fixed

PHP branchFixed inNotes
8.58.5.12Supported
8.48.4.27Supported
8.38.3.36Supported
8.28.2.35Security-only support, ends December 31, 2026
8.1 and olderNo official releaseSource backports only for 7.4 to 8.1; 7.3 and older get nothing

Linux distributions and long-term support vendors received the fixes in advance, so a patched distribution package can carry an older-looking version number. Check the package changelog for both CVE IDs rather than relying on the version string.

What to do this week

  • Inventory every PHP runtime. Include web servers, containers and base images, hosted and managed WordPress sites, developer machines, and vendor appliances. Vendors such as Cisco have already published advisories for products that embed PHP.
  • Patch to a fixed version and restart every PHP worker. Updating WordPress or your application does not update PHP. The fix comes from your server packages, your host, or your container image, and it only takes effect after Apache, PHP-FPM, and long-running workers restart.
  • Get written confirmation from hosts and vendors. Ask which PHP version and package build each environment runs, and when it was patched.
  • Apply interim mitigations only if you can’t patch yet. The PHP project and researchers describe these as partial: set memory_limit=-1 at the administrator level, set session.upload_progress.enabled=0, set fatal_error_backtraces=0 on PHP 8.5, enforce request-size limits at the proxy or web server, and restart workers. A WAF rule helps only for traffic that passes through it.
  • Look for signs of earlier attempts. Watch for unusual multipart requests followed by memory-limit errors, bursts of HTTP 500 responses, oversized PHPSESSID cookies, and unexplained worker restarts.
  • Plan the next upgrade now. PHP 8.2 stops receiving security fixes at the end of 2026. If you’re on 8.2 or older, today’s patch buys you weeks, not years.

Why this is a controls story, not a patch story

Emergency patches are a test of the program you already have. The organizations that will close this out in a day aren’t faster at typing update commands. They already know where PHP runs, who owns each system, how risk gets recorded, and how an emergency change gets approved. Five disciplines decide the outcome:

  • Asset management: you can’t patch what you can’t find. PHP hides inside marketing sites, plugins, appliances, and container images that nobody thinks of as PHP.
  • Vulnerability and patch management: a defined remediation window for critical, internet-facing flaws, plus a tested emergency-change path so the window is achievable.
  • Risk register: record the exposure with an owner, a due date, any compensating controls, and a formal exception if a system can’t be patched on time. A risk that isn’t written down isn’t being managed.
  • Lifecycle management: track end-of-life dates for runtimes, not just operating systems. Unsupported software turns every future vulnerability into a permanent one.
  • Third-party oversight: much of your PHP exposure sits with hosts, SaaS providers, and appliance vendors. Contracts and reviews should give you a way to get patch status in writing, fast.

How the response maps to common frameworks

If you report against more than one framework, the same evidence can satisfy several of them. Here’s how the core controls line up, from finding the exposure through confirming your providers have closed it:

Control areaNIST (CSF 2.0 / SP 800-53)ISO/IEC 27001:2022CSA CCM v4FFIEC IT HandbookSOX (ITGCs)
Asset inventoryID.AM-01, ID.AM-02 / CM-8A.5.9DCS-06Information Security II.C.5Scoping of in-scope systems
Vulnerability identification & threat intelID.RA-01, ID.RA-02, ID.RA-08 / RA-5, SI-5A.8.8, A.5.7TVM-05, TVM-07, TVM-08Information Security III.A; AIO VI.B.3IT operations monitoring
Patching (flaw remediation)PR.PS-02 / SI-2A.8.8TVM-03Information Security II.C.10(d); AIO VI.B.3Change management
Change & configurationPR.PS-01 / CM-3, CM-6A.8.9, A.8.32CCC-01, CCC-06Information Security II.C.10(a)Change management
End-of-life softwareID.AM-08 / SA-22A.5.9, A.8.8TVM-05, DCS-06Information Security II.C.11IT operations; change management
Risk register & treatmentID.RA-05, ID.RA-06 / RA-3Clauses 6.1.2, 6.1.3, 8.2, 8.3GRC-02Information Security II.ACOSO Principles 7 and 11
Detection & incident responseDE.CM-09, DE.AE-02, RS.MA-01 / SI-4, IR-4A.8.16, A.5.24, A.5.25, A.5.26LOG-03, LOG-05, SEF-03, SEF-06Information Security III.B, III.C, III.DIT operations (incident management)
Third-party & hosting providersGV.SC-07 / SA-9, SR-6A.5.19, A.5.21, A.5.22STA-08, STA-12Information Security II.C.14, II.C.20SOC 1 reports and complementary user entity controls

Notes: SOX does not prescribe patching directly. It reaches it through IT general controls over systems that support financial reporting, so an unpatched, internet-facing server in that scope can undermine reliance on those controls. Control identifiers refer to NIST CSF 2.0, NIST SP 800-53 Rev. 5, ISO/IEC 27001:2022 (Annex A and clauses), CSA Cloud Controls Matrix v4.0, and the FFIEC IT Examination Handbook (Information Security and Architecture, Infrastructure, and Operations booklets). Confirm mappings against the versions your organization is assessed on.

For small businesses: three questions to ask today

  • Ask your web host: which PHP version is my site running, and is it patched for CVE-2026-109618 and CVE-2026-109619?
  • Ask your IT provider or software vendors: do any of our systems or appliances use PHP, and have they been updated?
  • Ask yourself: do we have a list of our websites and systems, and who’s responsible for each? If not, that list is your first project.

Want help checking your exposure, or building a patch and asset management program that holds up under audit? Book a free 30-minute consultation.

Framework references

Want to go deeper? Here’s where to get each framework from its official source.

Sources