PHP2Shell: Everything You Need to Know About the Two Critical PHP Vulnerabilities

Last updated: Oct 21, 2026, 11:00 a.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. Full details, affected versions and fixed versions will be published with the release, and the team reserved the right to release earlier if details became public or exploitation appeared in the wild.

Following the initial leaks, the Wiz Research Team published the official disclosure for PHP2Shell on October 21, 2026 , confirming that frontier AI models were used to chain these complex memory-safety flaws into practical, working exploits. ‍

What we know 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 official Wiz disclosure confirms that 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 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). Wiz actively demonstrated that these engine-level flaws could achieve 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.

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 attempts are expected within minutes of the patch going public, with mass exploitation forecast at 15 minutes after the release. That is a prediction, not a measurement, but with the flaws already public, defenders should assume the window will be short.

End-of-life PHP. Fixes are expected only for supported PHP 8 branches, so PHP 5 and PHP 7, and possibly other older branches, may never receive an official patch. For those systems, upgrading, isolating or shielding them is the only real option. ‍

What to do before 14:00 UTC on 21 October

Use the hours before the release to get ready, so that patching is a matter of execution rather than discovery.

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.

Pre-stage the patch. Agree who approves the change, prepare the upgrade and reload steps, and plan to start with internet-facing systems as soon as the release is out. Check whether your distro or hosting provider ships backported packages.

Reduce exposure in the meantime. One suggested stopgap is setting session.upload_progress.enabled = Off in php.ini (or .user.ini / .htaccess where allowed) and reloading. It is unverified and based on the suspected root cause. It may not cover every attack path, and it is not a substitute for patching.

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.

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.

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;)

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 will analyze exploit code and patches as soon as they are published.

We are also building an in-platform mitigation and will release it when it is ready. Once vulnerability scanners publish detection rules for these CVEs, Zafran will filter out false-positive findings that don’t apply to your environment.

Traditional vulnerability management must change. So many are drowning in detections, and still lack insights. The time-to-exploit window sits at 5 days. Implementing a Continuous Threat Exposure Management (CTEM) program is the path forward. Moving from vulnerability management to CTEM doesn't have to be complicated. This guide outlines steps you can take to begin, continue, or refine your CTEM journey.