Last updated: Oct 22, 2026, 2:00 p.m. ET. We will update this post as the situation develops.
On 20 October 2026, two critical vulnerabilities in PHP stopped being a secret.
An anonymous online post claimed that two critical remote code execution flaws in PHP would be announced on 22 October, citing a reliable source. The post was taken down quickly, but screenshots had already spread across social media, complete with the reserved CVE IDs and a claim that every PHP version since PHP 5 was affected. The same day, the leak was confirmed as real, and the PHP security team answered with an announcement of its own: a critical security release, scheduled for Wednesday, 21 October 2026, at 14:00 UTC.
The pair is being called “PHP2Shell”. PHP powers a huge part of the internet, from WordPress and Magento stores to hosting control panels and vendor appliances, and patched versions are now officially available.
How the leak unfolded
The first signal was an anonymous post online. It said two critical PHP remote code execution flaws would be announced on 22 October, and it attributed the information to a reliable source. The post was removed, but not before screenshots and summaries began circulating on social media. From there it moved fast. Posts amplified the claim, listed the two reserved CVE IDs, and said all PHP versions from PHP 5 onward were vulnerable. A short video that appeared to show exploitation was reportedly posted and then pulled. The name “PHP2Shell” began to circulate, and security researchers confirmed that the leaked vulnerabilities were real, reproducing one of them.
PHP responded on the same day. Its security team published an advance notice announcing a security release for the two vulnerabilities on Wednesday, 21 October 2026, at 14:00 UTC, ahead of the date the leak had cited. PHP’s official advisory was published with the release and says every PHP installation serving web requests is at risk.
What we know about the flaws
The vulnerabilities are tracked as CVE-2026-109618 and CVE-2026-109619. Both are described as remote code execution flaws in PHP core, which means a successful attack could let an attacker run their own code on a server.
The flaws are core engine memory-safety issues stemming from how PHP handles fatal out-of-memory errors across requests. The affected range stretches back more than a decade to PHP 5.4, meaning nearly every environment running unpatched versions is vulnerable. These flaws include session upload-progress use-after-free and process-memory disclosure primitives (CVE-2026-109618), alongside fatal-error backtrace and OPcache type-confusion flaws (CVE-2026-109619). Researchers have shown that these flaws can lead to unauthenticated remote code execution on default installations of WordPress, Drupal and Joomla. Patches are now officially available from the PHP security team to remediate these flaws at their core.
Why this one matters
Reach. PHP sits behind WordPress, Drupal, Joomla and Magento, most shared hosting, control panels such as cPanel and Plesk, and software bundled inside vendor appliances. Roughly 1.5 million internet-facing hosts advertise a PHP version, and more than half of them run PHP 8.1 or older.
Speed. Exploitation went from a few scattered attempts to millions within minutes of disclosure, and several threat groups and botnets are targeting both flaws. We have no confirmed victims yet.
End-of-life PHP. Fixed releases are available for PHP 8.2.35, 8.3.36, 8.4.27 and 8.5.12. PHP 8.1 and older have no fixed release. PHP published source-only backports for 7.4 through 8.1, and some distributions and vendors offer their own. For older systems, upgrade them, take them off the internet, or put them behind a VPN or WAF.
What to do now
Fixes are out, so the focus now is finding where PHP runs and patching the most exposed systems first.
- Use Zafran to Inventory every PHP installation. Include containers, CI runners, and PHP bundled inside appliances, control panels (cPanel, Plesk) and CMSs (WordPress, Drupal, Joomla, Magento). If you use Zafran, its software inventory is the fastest place to see where PHP is installed across your assets and which versions are running.
- Patch, starting with internet-facing systems. Install the fixed release on every PHP runtime, then restart Apache, PHP-FPM and any long-running PHP workers. Check whether your distro or hosting provider ships backported packages.
- Reduce exposure in the meantime. A few mitigations have been published, but they are partial and can be bypassed, so treat them as a short-term step while you patch. You can find the suggested steps at php2shell.com.
- Isolate end-of-life PHP. Upgrade it, take it off the internet, or put it behind a VPN or WAF until it can be upgraded.
- Watch for post-exploitation activity. Alert when PHP processes such as php-fpm, php-cgi and apache2/httpd spawn shells, interpreters or download tools like curl, wget or nc.
If you suspect a server was compromised, isolate it, preserve the web server and PHP logs, and check the web root for new files, webshells, cron jobs and accounts.
What Zafran is doing
Zafran builds a software inventory (SBOM) of your assets from the tools you already have connected. Because that inventory is already in place, you can see every asset running PHP, and which version, without waiting for a scanner to publish a detection for these CVEs.
For each asset running an affected version, Zafran adds the context that decides what to patch first:
- Whether PHP is actually running on the asset, based on EDR process data.
- Whether the asset is reachable from the internet.
- Whether your firewall, WAF or EDR already blocks the path to it, based on reading those tools’ live configuration.
This lets you start with internet-facing hosts that are running vulnerable PHP and unprotected, instead of treating every PHP install the same.
Protection you can deploy now
The Zafran Research team developed and lab-tested IPS rules you can deploy now as an immediate layer of protection while you patch. The rules detect the exploit’s signature: a PHPSESSID value and the PHP_SESSION_UPLOAD_PROGRESS field sent together in an upload.
SNORT:
alert http any any -> any any ( msg:"CVE-2026-109618/619 upload_progress trigger PHPSESSID+progress co-present"; flow:established,to_server; http_method; content:"POST", nocase; http_client_body; content:"PHP_SESSION_UPLOAD_PROGRESS", nocase; http_client_body; content:"PHPSESSID", nocase; classtype:web-application-attack; sid:1026109620; rev:1;)
Suricata:
alert http any any -> any any ( msg:"CVE-2026-109618/619 upload_progress trigger PHPSESSID+progress co-present"; flow:established,to_server; http.method; content:"POST"; http.request_body; content:"name=|22|PHP_SESSION_UPLOAD_PROGRESS|22|", nocase; http.request_body; content:"name=|22|PHPSESSID|22|", nocase; classtype:web-application-attack; sid:1026109620; rev:1;)
The Zafran Research team is tracking the situation continuously across official and unofficial sources, and is analyzing the released patches and exploit activity.
Zafran is also surfacing custom mitigations you can apply through your existing security controls, including controls with no built-in protection for these CVEs. Once vulnerability scanners publish detection rules for these CVEs, Zafran will filter out false-positive findings that don’t apply to your environment.
