Quick answer: Two critical remote code execution flaws in PHP core were published, informally nicknamed PHP2Shell. CVE-2026-109618 and CVE-2026-109619 both carry a CVSS v4.0 score of 9.2 critical. Early and still unverified PoC reports describe the root cause as two heap use after free bugs reached through multipart upload handling and the session.upload_progress callback. The supported 8.2 through 8.5 branches received patches on 2026-10-21, while 8.0 and 8.1 are end of life and get no fix. Confirm the exact patched versions from the php.net announcement and update today.

PHP still powers the large majority of websites on the internet. Enterprise systems built on WordPress, WooCommerce, Laravel and Magento all sit on top of this engine. The two flaws announced through php.net on 21 October 2026 target exactly this broad base. Because the embargo leaked before release, the update was pulled forward and defenders were left with a very narrow window. This article focuses solely on the PHP core flaw and explains, without overclaiming and on an evidence basis, what happened, who is affected and what you should do today.

What PHP2Shell is and why it is critical

PHP2Shell is an informal nickname circulating in the security community for two separate CVEs, not an official brand. Both records fall in the memory corruption class that can lead to remote code execution inside PHP core. The CVSS v4.0 scores were given as 9.2, which sits at the upper end of the critical range and usually points to flaws that need no authentication, can be triggered over the network and have high impact.

Early technical reports describe the root cause as two heap use after free bugs. An important caveat applies, these reports are still unverified and early stage. According to the narrative, the first bug lives in the session.upload_progress handler, that is the php_session_rfc1867_callback path inside ext/session/session.c, and is reached during a multipart upload. The second bug sits in the multipart parser itself, so it can be triggered by any POST request that carries a multipart/form-data body. The watchTowr team reported producing a working process for CVE-2026-109618. The honest boundary here is that the full chain from a use after free bug to reliable code execution was not fully demonstrated in public. The exploitability is real, but how easy weaponization is was not clear at the time of release.

Who is affected

The surface of this flaw is exceptionally wide because the problem is not in a plugin or a framework but in the core of the language. The second bug, the one touching the multipart parser, is especially notable, because even an endpoint that accepts no file uploads can enter the parsing path if it receives a multipart/form-data body.

Every unpatched 8.x install should be treated as at risk. We want to stress that a version match means potentially affected, not definitely vulnerable, because some distributions may have backported the fixes or applied extra hardening. The end of life 8.0 and 8.1 branches have no official patch, which turns them into a structural risk. The 5.x and 7.x lines were also claimed to be affected, but that claim is unverified and no patches are issued for those branches anyway. We covered why end of life runtimes form a separate threat category in our end of life runtime risk and version migration guide.

Which version is safe, the required version matrix

The table below summarizes which branch received a patch. Always confirm the exact version numbers from the official php.net announcement before updating, because these figures are single sourced and were published on release day.

PHP branch Current status Patched version State
8.5 Supported 8.5.12 Patched, update now
8.4 Supported 8.4.27 Patched, update now
8.3 Supported 8.3.36 Patched, update now
8.2 Supported 8.2.35 Patched, update now
8.1 End of life None No patch, migration required
8.0 End of life None No patch, migration required

To learn your running version, check the php dash v output on the server or the PHP version field in your hosting panel. If your version is older than the patched number above, treat it as potentially affected and update. If you use containers, updating the package alone is not enough, you must rebuild and redeploy the image.

What to do, urgency and mitigation

The priority is the patch. If you run a supported branch, plan to update today. If you cannot patch immediately, there are temporary mitigations that narrow the attack surface, but none of them replace the patch.

The first mitigation is setting session.upload_progress.enabled to Off in php.ini. This closes only one of the suspected paths, it does not close the second bug in the multipart parser. The second mitigation is to limit or inspect POST requests carrying multipart/form-data at the WAF or reverse proxy layer on endpoints that accept no uploads. Because this is a remote code execution class, you can find the baseline defense logic in our command injection and RCE protection article.

Let us be clear about urgency. The embargo leaked early around 20 October 2026 and the release was pulled forward because of it. Widespread active exploitation was not definitively confirmed at the time of release, and this information is single sourced for now. Even so, the combination of a CVSS 9.2 score, core memory corruption and an embargo leak places this flaw in the class that cannot wait. A shrinking patch window works in the attacker's favor.

For hardening enterprise WordPress installs and cleaning up after a possible breach, see our enterprise WordPress security guide, and for the online retail side covering PCI DSS and Magento or WooCommerce, see our electronic commerce data recovery article. If you want to build a broader patch discipline, our patch management guide walks through the process end to end.

As a note, a Node.js security release shipped on the same day. Because DSET infrastructure runs on Next.js and Node, that release concerned us directly rather than PHP, and you can find the details in the Node.js October 2026 security update guide and a sibling remote code execution flaw in the Node.js Brotli RCE article.

The KAOS and DSET approach

KAOS, the local artificial intelligence engine inside DSET, follows an evidence based and measured path when assessing a flaw like this. The first step is version detection, that is determining the PHP branch and version a target system runs through passive and active methods. The second step is matching that version against known CVE records. The third step is prioritization using inputs such as KEV lists and exploitation likelihood.

The principle we want to highlight is that a version match is a hypothesis, not proof. The overclaim brake inside KAOS does not automatically declare a version match to be a confirmed vulnerability. A backport may be present, a mitigation may be applied, or the endpoint may accept no multipart requests at all. Firm confirmation requires authorized active validation, and for this flaw in particular, because the code execution chain was not fully shown in public, that validation is carried out with equal care. Our goal is not panic but correct prioritization and fast application of the patch.

Frequently asked questions

Is PHP2Shell an official name, and is it one flaw or two? PHP2Shell is an informal nickname, not an official name assigned by php.net or NVD. Behind it sit two separate CVEs, CVE-2026-109618 and CVE-2026-109619, both in the remote code execution class inside PHP core and both rated critical at CVSS v4.0 9.2. Because the name was coined by the community, it may appear with small differences across sources, and the firm reference is always the CVE identifiers.

I cannot patch, is disabling session.upload_progress enough? No, on its own it is not enough. Setting session.upload_progress.enabled to Off closes only one of the two paths described in early reports. Because the second bug is described in the multipart parser itself, it can be triggered by any POST request carrying a multipart/form-data body, and this setting does not close that path. So the session setting is only a temporary risk reduction, and the real fix is moving to a patched version on a supported branch.

I use an old PHP 7 or PHP 8.1, what should I do? These branches are end of life and receive no official patches. The claim that 7.x lines are affected is unverified, but even if it were confirmed the outcome would not change because no patch is coming. The only safe path is migrating to a supported branch, that is 8.2 or above. This migration matters not only for this flaw but so you can keep receiving the steady stream of other fixes, because an end of life runtime is a permanent and compounding risk.

Sources

To assess your PHP based enterprise system against this flaw, build a patch plan and set up the temporary mitigations correctly, contact DSET. Our team provides penetration testing, incident response and security consulting from the Ankara Hacettepe Teknokent campus.