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

Last updated: Oct 21, 2026, 7: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 the fix has not been released yet. 
‍

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.
‍

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 reported to be memory-corruption bugs in PHP's session upload-progress feature, with CVE-2026-109618 described as a use-after-free.

The affected range is not confirmed. It is believed to reach back to PHP 5, so until PHP publishes its advisory, assume that every PHP version in your environment is potentially affected. The root cause, the attack conditions and the exact fixed versions are also still unpublished. No exploitation in the wild has been confirmed so far.
‍

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 attempts are expected within minutes of the patch going public, with mass exploitation forecast at about 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.

1. 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.
2. 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.
3. 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.
4. 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.
5. 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

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 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.