PHP Critical Flaws CVE-2026-109618 and CVE-2026-109619: What to Do Now

Two critical PHP flaws allow remote code execution. What NSA, CISA and PHP say, the fixed versions (8.5.12, 8.4.27, 8.3.36, 8.2.35), and what is still unknown.

Two critical flaws in PHP, the language behind a large share of the web, were fixed on 21 October 2026. Tracked as CVE-2026-109618 and CVE-2026-109619 and nicknamed "php2shell" by researchers, they can let an unauthenticated attacker run code on a server through crafted web requests. The US National Security Agency (NSA), the US cyber agency CISA, CERT-EU and the UK's National Cyber Security Centre (NCSC) all urged organisations to update, and the NSA added that systems which cannot be updated immediately should be taken offline. This page reflects primary sources as checked at about 04:15 IST on 22 October 2026 (22:45 UTC on 21 October, the evening of 21 October in the US). The story is still moving, so we say plainly what is not yet known.

On this page: What happened · Timeline · The two vulnerabilities · Who found them, and how old they are · Who is affected · What to do now · Why "take it offline" is strong wording · What we don't know yet · FAQ · Sources

9.2CVSS v4.0 score (critical) the PHP project gave each vulnerability

4supported PHP branches fixed: 8.5.12, 8.4.27, 8.3.36 and 8.2.35

1 dayhow far the PHP project moved its release forward after the CVE numbers leaked

What happened

On 20 October 2026 the two CVE numbers began circulating online before the planned disclosure. The PHP Foundation says the posts carried a wrong release time and a wrong severity score of 10.0, with no technical details. The PHP project moved its release up by a day, and CERT-EU records that PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 were released at 13:30 UTC on 21 October.

The NSA published "NSA Advisory: PHP Updates" the same day. It tells all organisations using PHP to be prepared for an update addressing two critical vulnerabilities, says such flaws often give a direct path to the server's file system or database, and promises more specific guidance. CISA, CERT-EU, the NCSC and Singapore's Cyber Security Agency (CSA) also published alerts on 21 October, and at 14:59 UTC the FBI's Cyber Division repeated the NSA's take-offline advice in a post on X.

Timeline

11 August: Calif and OpenAI independently report the same out-of-memory root cause to PHP; Wiz reports further attack paths on 24 August (PHP Foundation).
20 October, about 15:00 UTC: The CVE numbers start circulating online (PHP Foundation).
20 October, 19:30 UTC: PHP publishes its advance notice and brings the release forward from 22 October to 21 October (PHP Foundation).
20 October, evening UTC: A proof-of-concept video is published and then deleted, but copies circulate (PHP Foundation).
21 October, 03:02 UTC: Cloudflare's WAF protections start applying by default to its customers (Cloudflare).
21 October, about 13:30 UTC: Fixed PHP versions are released (CERT-EU).
21 October, after the release: Calif and Wiz publish technical write-ups (Calif, Wiz; noted in Huntress's 4:40 pm ET update).

The two vulnerabilities

CVE-2026-109618, out-of-memory corruption. PHP limits how much memory a request may use and aborts a request that hits the limit. If that happens while PHP is part-way through building some internal data (for example while parsing an uploaded form), the data is left half built, and cleanup then treats it as valid. That can let an attacker corrupt memory and run code. The PHP Foundation says that on Apache with mod_php an unauthenticated request can trigger this before any application code runs, with default settings. For PHP-FPM, PHP's own advisory says source analysis shows it is susceptible but that no complete FPM exploit for this flaw had been demonstrated; the Foundation's blog post describes code execution on PHP-FPM through application-level code paths.

CVE-2026-109619, stale global state. PHP workers keep some internal state between requests. If a fatal error (including running out of memory or exceeding the time limit) interrupts a request at the wrong moment, that state can still point to memory freed with the request, and a later request on the same worker may use it. PHP's advisory lists memory disclosure as well as code execution, with two confirmed paths: the session upload-progress feature, which is on by default, and, on PHP 8.5, fatal-error backtraces. It says code execution through the session path was validated on both mod_php and PHP-FPM.

Both records carry the same CVSS v4.0 vector: reachable over the network, no privileges, no user interaction, high impact on confidentiality, integrity and availability, with attack complexity rated high and attack requirements present. Code runs with the privileges of the web server account. Both flaws sit in PHP's core, not in a plugin or application.

Who found them, and how old they are

The CVE records credit Calif and Wiz as reporters and OpenAI (finder on CVE-2026-109618, reporter on CVE-2026-109619), plus four PHP developers for the fix. OpenAI's own post says Calif identified a flaw using an OpenAI model under its Patch the Planet programme, and that Wiz independently discovered and reported both. So OpenAI is credited, but as one of three parties rather than the sole discoverer.

On age, Calif says the earliest affected code path it found dates to PHP 5.4.0, and php.net lists PHP 5.4.0 as released on 1 March 2012. Wiz says the code had been present for more than a decade. So "since 2012" is consistent with the oldest version researchers traced, but the CVE records give no introduction date. Calif and the Foundation also trace related out-of-memory reports to 2020 and a 2024 audit, where no working exploit had been shown. Social media posts have added claims beyond these records; speculation that goes past them is not supported by the primary sources we reviewed.

Who is affected

PHP says all installations serving web requests are at risk, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed, and considers mod_php the highest risk. The CVE records list these as affected: 8.2 before 8.2.35, 8.3 before 8.3.36, 8.4 before 8.4.27 and 8.5 before 8.5.12. The UK NCSC says organisations using any version of PHP are affected and not to limit their search to outdated versions.

Older branches: PHP 8.1 and earlier no longer receive official updates. PHP says some distributions and long-term-support vendors provide backported fixes, and its security team published minimal source backports for 7.4, 8.0 and 8.1 for people who build from source. Distribution packages may carry different version numbers: Debian's tracker lists 8.2.35-1~deb12u1 as fixed for Debian 12, and Red Hat issued RHSA-2026:87080 for its php:7.4 module on RHEL 8.

Applications: the flaws are in PHP itself, so applications on an affected PHP are exposed even if their own code is secure. Calif reports confirmed unauthenticated code execution in its tests against WordPress, Drupal, Joomla and MediaWiki, among others, and Wiz demonstrated it on the latest container images of WordPress, Drupal and Joomla. Cloudflare notes that updating website code or plugins does not fix this; the PHP runtime must be updated, or the hosting provider asked to do it. Huntress adds that PHP also sits inside vendor appliances, control panels and Windows software, and CERT-EU and the NCSC point to an inventory of such products kept by the Dutch NCSC. Product vendors have started their own advisories: Palo Alto Networks has published one, and Cisco lists products it is still investigating.

What to do now

Inventory every PHP install. Start with internet-facing systems, then appliances, control panels and bundled software (CISA, NCSC, Huntress).
Update. Move to PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or install your distribution's patched package. PHP says the volunteer-run rpms.remirepo.net repository would not have updates on release day.
Restart the workers. Restart PHP-FPM, or Apache if you use mod_php, so running processes load the fixed build. AlmaLinux's upgrade instructions include a restart.
If you cannot update yet, apply PHP's interim measures, which it says reduce exposure to specific paths but do not make an installation safe. For CVE-2026-109618: set memory_limit=-1 where applications cannot override it (such as php_admin_value), and keep post_max_size low (8M without uploads, 32M with). For CVE-2026-109619: set session.upload_progress.enabled=0 in php.ini or the pool configuration, and on PHP 8.5 set fatal_error_backtraces=0. Restart every worker afterwards.
Treat a WAF as a second layer, not a fix. CISA says a web application firewall may provide some protection until patching, and Cloudflare says to keep its WAF protections on while you patch.
Watch for compromise. CISA and Huntress say to look for PHP worker processes (such as php-fpm, php-cgi, httpd or apache2) launching shells or download tools. Huntress had no confirmed indicators of compromise when it published. If you find something, Huntress advises isolating the server, preserving web and PHP logs, and checking for webshells, new web-root files, scheduled jobs and accounts. PHP cautions that a clean log is not proof of safety. In the US, the FBI asks organisations to report signs of compromise to a local FBI field office.
End-of-life PHP. CISA says to take systems on PHP 8.1 or earlier offline until they can be updated. Otherwise upgrade, or use a vendor or PHP source backport. PHP 8.2 reaches end of life on 31 December 2026.

This is general information, not legal or incident-response advice.

Why "take it offline" is strong wording

Taking a public service down costs availability, so it is a heavy instruction. The NSA's text makes it the fallback: if an immediate update is not feasible, it recommends organisations "take the system offline until it can be fully mitigated." The same advisory notes that these flaws often give a direct path to the server's file system or database, and the FBI's Cyber Division repeated the take-offline wording. The agencies differ in tone. CISA says organisations that cannot update immediately, or that use PHP 8.1 or earlier, should take PHP-based systems offline. The NCSC says to consider taking a system offline if PHP's temporary mitigations cannot be applied, and CERT-EU says to consider isolating internet-facing applications from public networks. The BBC reported that the Finnish government temporarily shut down its public web services and the Dutch cyber agency took its own site offline.

What we don't know yet

How much real exploitation there is. Reports differ by vantage point. Cloudflare says it observed attack traffic targeting its customers, with attackers changing payloads to try to get past its rules. SecurityWeek reports that Hadrian, Patchstack and Vega also saw exploitation attempts; Hadrian described exploitation "at scale". watchTowr says it observed exploitation on its honeypots on 21 October, though SecurityWeek quotes it saying none had succeeded. The PHP Foundation says the security team found no functional exploits among the circulating proofs of concept at the time of release. Huntress saw none on its partner systems as of 4:30 pm ET, and CISA had observed none when it published. As of 22:45 UTC on 21 October (04:15 IST on 22 October), neither CVE was in CISA's Known Exploited Vulnerabilities catalogue (version 2026.10.21), and the NVD records showed no KEV listing.
Who is attacking, and with what success. As of the same check, we found no public attribution, no confirmed count of compromised sites and no confirmed indicators of compromise.
The NSA's promised guidance. As of the same check, it was not on the NSA's press-release or cybersecurity-advisories pages.
Further variants. Wiz says other tracked and likely untracked variants exist, and that PHP's patch fixes the issue at its core.
Unsupported versions. The CVE records list only 8.2 to 8.5, while PHP, CISA and the NCSC treat older versions as at risk.

FAQ

Is every PHP website vulnerable?

PHP says all installations serving web requests are at risk until updated, and the NCSC says any version may be affected. The CVE records list the 8.2 to 8.5 branches below their fixed versions. PHP adds that exploit reliability varies with the build, extensions and server setup.

Did OpenAI discover these bugs, and have they existed since 2012?

OpenAI is credited in both CVE records, alongside Calif and Wiz. The oldest affected code Calif traced is PHP 5.4.0, released in March 2012, but no official record states when the bugs were introduced.

Do I have to take my site offline?

The NSA, and the FBI's Cyber Division in its post, recommend it only if an immediate update is not feasible. CISA adds systems on PHP 8.1 or earlier. The NCSC says to consider it, and CERT-EU says to consider isolating internet-facing applications. PHP says updating is the only complete fix.

Will updating WordPress or my plugins fix this?

No. Cloudflare says website code and plugin updates do not fix flaws in the PHP runtime. Update PHP, or ask your host to.

Is it being exploited right now?

Several vendors report exploitation attempts, while CISA and Huntress reported none at the times they published. See "What we don't know yet" for details.

Sources

If a site you run or rely on has been compromised, or you have lost money or data as a result, see our cybercrime help hub for country-by-country reporting and recovery guides.