CyphrQ
Menu

php2shell (CVE-2026-109618): Two Critical PHP RCE Flaws and How to Patch Them

Two critical PHP flaws, CVE-2026-109618 and CVE-2026-109619, allow remote code execution. Fixed in 8.5.12, 8.4.27, 8.3.36, 8.2.35. What to do now.

By CyphrQ.ai

Written with AI assistance and human editorial review. Every figure linked to its source.

9 min read

On 21 October 2026 the PHP project fixed two critical flaws, CVE-2026-109618 and CVE-2026-109619 (known together as php2shell), that can allow unauthenticated remote code execution on servers running PHP. The fixed versions are PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. If you run a PHP website, find every PHP install you have, internet-facing ones first, and update them.

"Remote code execution" (RCE) means an outsider can make your server run commands of their choosing. "Unauthenticated" means they need no login first. Together, that is why PHP rated both flaws critical.

This post covers what the two flaws are, who is affected, what the sources disagree on, and a short plan. For the wider habit of ranking patches, I link to my earlier post on CVSS, EPSS and KEV instead of repeating it. More current items are on the latest vulnerabilities page.

What is php2shell?

"php2shell" is the name Wiz Research gave to its exploit script. In its write-up, Wiz says it "combined these vulnerabilities into a single exploit script, php2shell," and used it to demonstrate unauthenticated code execution on the latest WordPress, Drupal and Joomla container images at the time of testing. Wiz does not say whether the script is public. The NVD records for both CVEs list the Wiz post as a reference, and the name is now used as shorthand for the pair.

The two flaws, as described in PHP's own advisory:

CVE What PHP says it is
CVE-2026-109618 "Out-of-memory handling can interrupt PHP while internal request data is only partially initialized. Request cleanup may then treat the invalid data as valid."
CVE-2026-109619 "Request-owned internal state can survive after its backing memory has been freed. A later request handled by the same worker may use that stale state before normal initialization resets it."

In plain terms, both are memory-handling mistakes in how PHP sets up and cleans up after a web request. Memory corruption of this kind can, under the right conditions, be steered into running an attacker's code. I am not going to describe how, and the advisories don't need you to know.

Which PHP versions does it affect?

The sources do not describe this identically, so here is each one by name.

  • PHP's advisory says the risk applies to "all PHP installations serving web requests, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed." It calls the risk highest for mod_php, "with a demonstrated exploit where an unauthenticated request can trigger the attack before any application code runs."
  • CERT-EU advisory 2026-018 lists PHP 8.5 before 8.5.12, 8.4 before 8.4.27, 8.3 before 8.3.36 and 8.2 before 8.2.35, plus end-of-life PHP 8.1 and older.
  • The UK NCSC says any version of PHP is affected, and tells organisations not to limit their search to outdated versions.
  • Wiz says every PHP version released in the last decade is affected by at least one of the two flaws, going back to 5.4.

The safe reading: assume every PHP version serving web requests is affected until your vendor or the fixed release says otherwise. PHP 8.1 and older no longer get updates from the PHP project. PHP published minimal source backports for 7.4, 8.0 and 8.1, and says some Linux distributions and long-term-support vendors received the patches in advance.

How severe are the php2shell flaws?

Both carry a CVSS v4.0 base score of 9.2 (Critical), set by PHP's own security team as the CVE assigner. NVD, run by the US National Institute of Standards and Technology, adds its own CVSS v3.1 scores, and they differ.

Record CVSS v4.0 (PHP) CVSS v3.1 (NVD)
CVE-2026-109618 9.2 Critical 9.8 Critical
CVE-2026-109619 9.2 Critical 8.1 High

Source: NVD API records for each CVE, read 25 October 2026. The 8.1 reflects a "high complexity" attack rating in the v3.1 vector. It is a score of the flaw, not a statement that you can wait.

Is php2shell being exploited?

This is where careful wording matters.

  • KEV. As of 25 October 2026, CISA's KEV catalogue (version 2026.10.23) did not list them; check the live catalogue. The same was true of CVE-2026-115560, a third PHP flaw covered below. KEV is CISA's list of flaws with evidence of exploitation in the wild, so absence there means CISA has not added them, not that they are safe.
  • Proof of concept. CERT-EU's advisory states that "initial proofs of concept (PoCs) have begun to circulate," and says this "raises the likelihood that attackers are already exploiting the vulnerabilities." That is a statement of likelihood, not an observed attack.
  • Wiz. Its post reports no observed exploitation.
  • CISA data in NVD. Both NVD records include a CISA SSVC entry (a decision-tree rating) listing exploitation as "none" and automatable as "no," as of my reading on 25 October 2026. That entry can change.

I also saw secondary reports of attack attempts. I could not trace them to a primary source I opened, so I leave them out. The practical point stands without them: PHP's advisory describes a demonstrated exploit, and CERT-EU says proofs of concept are circulating. Treat it as a race you did not start.

What is CVE-2026-115560?

A third identifier appeared on 23 October. CERT-EU added CVE-2026-115560 to its advisory as a remote code execution issue with no technical details yet. PHP's own 23 October follow-up describes a lower-risk issue, promises a full advisory with the next bugfix release, and recommends session.upload_progress.enabled=0 until then. I have not read a full record for it, so I don't say more.

Which PHP versions fix php2shell, and what should site owners do now?

Do these in order. The first three cover most small organisations.

  1. List where PHP runs. Your main website, a shop, a forum, a staging site, an old microsite, a hosting account someone set up years ago. Do not limit this to outdated versions, as the NCSC says.
  2. Update to a fixed version. On managed or shared hosting, ask the host which version and package you are on, and ask them in writing. On your own server, use your distribution's PHP packages or the fixed releases from php.net.
  3. Internet-facing first. Public sites before internal tools.
  4. If you cannot update today, apply PHP's interim settings (below), and consider isolating or taking the site offline, as the NCSC suggests. PHP says these measures "reduce exposure to specific attack paths but do not make an installation safe."
  5. Check what bundles PHP. Appliances, control panels and hosted services can ship their own PHP. The NCSC points to an inventory of potentially affected products published by NCSC-NL.
  6. If an unpatched system was exposed, look for signs of compromise and backdoors, and get help from an incident response provider if you need it.

Going deeper: for security and IT teams

Mechanism and weakness types. Per NVD, CVE-2026-109618 arises because PHP uses longjmp() to abort request handling on out-of-memory errors, and some contexts fail to initialise request memory before an allocation, so later cleanup reads or branches on that memory. CVE-2026-109619 is global state that temporarily points to request memory and can be left referencing freed memory for a later request. PHP's CNA tags both with CWE-416 (use after free), CWE-755, CWE-824 and CWE-1325. The CVSS v4.0 vector is AV:N/AC:H/AT:P/PR:N/UI:N with high confidentiality, integrity and availability impact: network reachable, no privileges, no user interaction, with a precondition the attacker must arrange.

Find PHP versions across an estate. - Hosts: php -v shows the CLI binary only, which may differ from the web SAPI. Check the one serving traffic: php-fpm -v, or apachectl -M | grep -i php for mod_php, and a phpinfo() page only on a protected internal host. - Containers: php -v inside each running container, and docker run --rm <image> php -v for images in your registry. A base image tag such as php:8.3-fpm only helps if you rebuilt after the fix. Wiz tested the latest WordPress, Drupal and Joomla images, so rebuild the base layer, not just the app. - Distro backports: version strings may not change. Distributions can fix the flaw inside an older version number, so confirm through the vendor's changelog or tracker (for example rpm -q --changelog php | grep CVE-2026-109618 or apt changelog <package>), not the number alone. CERT-EU also notes that users of rpms.remirepo.net should switch to distribution packages or build from source, as that repository would not have updates on release day. - Embedded PHP: use the NCSC-NL inventory for vendor products.

Interim settings from PHP's advisory. For CVE-2026-109618: memory_limit=-1 set so applications cannot override it (php_admin_value in the FPM pool or Apache config), a low post_max_size (PHP gives 8M without uploads, 32M with), and limits on request size, field count, multipart parts, headers and nesting at the web server or proxy, including requests with no usable Content-Length. PHP warns not to use RLIMIT_AS or RLIMIT_DATA, which can trigger the vulnerable allocation failure. For CVE-2026-109619: session.upload_progress.enabled=0 in php.ini, the FPM pool or server config (not ini_set() or .user.ini), restarting every worker, and on PHP 8.5 only fatal_error_backtraces=0. PHP says these block confirmed paths only and an update is the complete fix.

WAF as a stopgap only. PHP's guidance puts request-limit controls at the web server or proxy. A web application firewall may help you limit request size and shape, but nothing I read shows a WAF rule that reliably blocks the underlying flaw, and my judgement is that signature rules for a memory-handling bug will be easy to get around. Use it to buy hours, then patch.

Logs and signals to review. Wiz lists three things to watch until you are patched: unusual multipart requests followed by memory-limit errors or repeated HTTP 500 responses; unexpectedly large or malformed PHPSESSID cookies; and unexplained PHP worker churn. Add web server error logs, FPM logs showing workers killed or restarted, new or modified files in web roots, and unexpected child processes spawned by the web server user. Absence of these signals is not proof of safety.

Questions for vendors and hosts. Which PHP version and SAPI do you run for us? Have you applied the fix or a backport, and which advisory ID did you use? Do any of your products embed PHP?

Key takeaways

  • Two critical PHP flaws, CVE-2026-109618 and CVE-2026-109619, were fixed on 21 October 2026 in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35.
  • Both are rated CVSS v4.0 9.2 by PHP and can allow unauthenticated remote code execution.
  • Assume every PHP install serving web requests is affected. PHP 8.1 and older need a vendor backport or an upgrade.
  • As of 25 October 2026, CISA's KEV catalogue (version 2026.10.23) did not list them; check the live catalogue. CERT-EU says proofs of concept are circulating.
  • Interim settings reduce exposure but do not make a server safe. Update first, internet-facing systems first.

Learn more

Sources