PHP2Shell: What We Know About the Two Leaked Critical PHP Flaws

On the afternoon of 20 October, a post on Hacker News claimed that two critical PHP vulnerabilities were about to be made public. It was deleted, but not before screenshots spread. Later that day, PHP confirmed two critical vulnerabilities and set an emergency release for the next afternoon. By the next morning, the Dutch government had taken DigiD and MijnOverheid offline as a precaution. PHP released the fixes on 21 October, a little ahead of schedule.

PHP runs most of the web: W3Techs puts it behind about seven in ten websites whose server language is known, including WordPress, Drupal, Joomla and Magento. So when its maintainers call two bugs critical and tell everyone to update immediately, it is worth paying attention.

This post covers what PHP’s advisory confirms, who found the flaws, whether your setup is affected, and what to do.

Last updated: 21 October 2026, 13:45 UTC, after PHP’s security release.

What happened

All times are UTC.

• 20 Oct, 15:20. A Hacker News user posts that two PHP remote code execution flaws are about to be disclosed. The post is deleted, but screenshots spread.
• 20 Oct, later. watchTowr confirms the vulnerabilities are real. Its CEO says they were due to be disclosed on Thursday 22 October.
• 20 Oct, later. PHP publishes an advance notice: two critical vulnerabilities, both CVSS v4.0 9.2, fixes on 21 October at 14:00 UTC. CERT-EU issues an advisory.
• 21 Oct, 02:13. A PHP core developer says updating PHP is the only real fix.
• 21 Oct, 07:34. Patchstack starts getting reports of attacks from hosting companies it works with.
• 21 Oct, 07:43. Cloudflare’s CTO says Cloudflare is seeing early attacks and has deployed firewall rules for all customers.
• 21 Oct, 08:48. The PHP Foundation warns that Remi’s repository, a popular source of PHP packages for Red Hat style Linux servers, will not have updates that day.
• 21 Oct, morning. The UK NCSC tells organisations to prepare. In the Netherlands, DigiD, MijnOverheid, the House of Representatives, the NCSC, Tweakers and others go offline as a precaution.
• 21 Oct, about 13:35. Ahead of the 14:00 schedule, PHP releases 8.5.12, 8.4.27, 8.3.36 and 8.2.35 with a security advisory and the full technical details.

What is PHP2Shell?

PHP2Shell is the nickname for two vulnerabilities, CVE-2026-109618 and CVE-2026-109619. The name comes from the leaked exploit tool, and it says what it does: turn a request to a PHP site into a shell on the server.

PHP’s advisory confirms that both can allow unauthenticated remote code execution. The attacker does not need an account or a password, and the code runs with the permissions of the web server’s PHP process. Both are rated critical, 9.2 out of 10 on CVSS v4.0.

CVE-2026-109618, “RCE via OOM corruption”. When PHP runs out of memory, it jumps straight out of whatever it was doing. If that happens while PHP is still setting up a request, it can leave half-built data behind, and the clean-up at the end of the request then trusts that broken data. An attacker can make PHP run out of memory on purpose with a crafted file upload request (a multipart/form-data request), for example with a huge number of headers or empty file fields. On Apache with mod_php, this works before the website’s own code even runs.

CVE-2026-109619, “RCE via stale global state”. A PHP worker handles many requests, one after another. Some internal state can survive the end of a request while still pointing at memory that has been freed, and the next request on the same worker can use it before PHP resets it. This is a “use after free”, a classic way into running your own code. The confirmed paths go through session upload progress, a PHP feature that is on by default and works even if the website never uses sessions, and through PHP settings applied per folder, such as in .htaccess files.

The two are linked: running out of memory is one of the ways to leave that stale state behind, and PHP asks everyone to follow the advice in both advisories.

Why 9.2 and not 10, as some early reports said? The official score says the attack is not trivial: it needs the right conditions, such as the attacker’s requests landing on the same PHP worker. That makes attacks less reliable, not impossible. PHP itself calls the risk highest for mod_php, where a working exploit has been demonstrated.

Who discovered it, and how did it leak?

The official credits. PHP’s two advisories credit four reporters, by their GitHub names: lcfr-hax, sagitzadik-wiz, tomash-areion and amyb-oai. They do not name the organisations behind them. The fixes were written by PHP core developers (arnaud-lb, iluuu1994, bukka and ndossche on GitHub).

What the leak said. Before the release, the only names came from leaked material:

• A screenshot of the exploit tool, named PHP2Shell, credits Calif (calif.io), a security team whose clients describe it as Thai Duong’s team. He is one of the researchers behind POODLE, the 2014 attack on SSL 3.0, which he found at Google with Bodo Möller and Krzysztof Kotowicz.
• Researcher Kirill Firsov shared a short video of the exploit and credited it to a researcher called LCFR and Calif, according to Tenable. That matches lcfr-hax in PHP’s credits.
• The disclosure was planned under embargo for Thursday 22 October. A Hacker News user posted about it two days early, and the exploit video was also briefly online.

That leak is why the timeline was so compressed. Normally, defenders get the fix and the details at the same time. This time, attackers knew something big was coming a day before anyone could update.

Does it affect Windows, Linux, or both?

Both. PHP’s advisory says “all PHP installations serving web requests” are at risk, without naming an operating system, and PHP released fixed Windows builds alongside the source code. The bugs are in PHP’s core, which is the same code everywhere.

The more useful question is how PHP is connected to your web server, because that changes the risk:

• Apache with mod_php: highest risk. PHP says a full attack was shown working through an ordinary web request with default settings, before any website code runs.
• PHP-FPM (the usual setup with nginx, and on most modern Linux hosting and control panels): at risk. The session upload progress attack was confirmed against PHP-FPM.
• php-cgi (common on Windows, where IIS runs PHP through FastCGI): at risk.
• FrankenPHP and LiteSpeed: at risk.
• PHP on the command line only (cron jobs, Composer, scripts): the advisory is about PHP serving web requests, so this is much lower risk. Update it anyway.

I think the Windows question comes from 2024. CVE-2024-4577, found by DEVCORE, really was Windows only: it abused a Windows character conversion feature to slip arguments into PHP-CGI, and was exploited by ransomware groups. PHP2Shell is not like that. Most PHP sites run on Linux, so Linux servers are the bigger target here.

Which PHP versions are affected?

• Affected: every version before 8.5.12, 8.4.27, 8.3.36 and 8.2.35.
• Fixed: update to PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35. PHP says Linux distributions and long-term support vendors got the patches in advance, so updated packages should be arriving from them too.
• PHP 8.1 and older: no longer supported, so there is no new release. Given the severity, PHP has published minimal source code patches for 7.4, 8.0 and 8.1 for people who build PHP themselves, and some distributions and vendors backport fixes. The real fix is upgrading to a supported version.
• PHP 8.2 reaches end of life on 31 December 2026, so plan that upgrade too.

Is it being exploited?

Yes, in a limited way so far, and it will get worse now the fix is public:

• Cloudflare said at 07:43 UTC on 21 October that it was seeing early attacks, and deployed firewall rules for all customers, free plans included.
• Patchstack reported attacks from several of the hosting companies it works with on the morning of 21 October.
• PHP says a working exploit has been demonstrated against Apache with mod_php.
• watchTowr, Huntress and the Dutch NCSC had not seen attacks themselves when they published.
• Sansec expects mass attacks within minutes of the fix, because a fix shows attackers exactly where to look.

Estimates of how many PHP servers face the internet range from about 1.3 million (researcher Silas Cutler) to over 1.9 million (a Shodan search by Henk Poley).

What to do now

If you run PHP anywhere, in this order:

1. Find every PHP install. Web servers, WordPress and other CMS sites, control panels, staging sites, containers, internal tools, and appliances or Windows software that bundle PHP. Check the PHP that actually serves your website (PHP-FPM or the Apache module), not just php -v on the command line: they are often different versions.
2. Update now, starting with anything facing the internet: to 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or your distribution’s patched package. Restart PHP-FPM or Apache afterwards so the old code is no longer running.
3. If you use Remi’s repository, PHP recommends switching to your distribution’s packages or building from source, because Remi will not have updates straight away.
4. If you are on PHP 8.1 or older, plan the upgrade now. Until then, use a vendor that backports fixes, apply PHP’s source patches if you build PHP yourself, or take the site offline.
5. If you cannot update today, PHP lists ways to reduce the risk. None of them make a server safe:
   • Turn off session.upload_progress.enabled in php.ini or the server configuration (not with ini_set() or .user.ini) and restart every worker. PHP suggests leaving it off after updating too, if you do not need it.
   • On PHP 8.5, set fatal_error_backtraces=0 and restart every worker.
   • Lower post_max_size (8M if you do not need uploads, 32M if you do), and block file upload requests at the web server or proxy if your site does not use them.
   • Put the site behind Cloudflare (or a similar firewall) and only accept traffic through it.
6. Watch for the signs of a break-in: PHP or web server processes starting shells or tools (sh, bash, cmd.exe, powershell.exe, curl, wget), new PHP files in your web folders, new scheduled tasks or cron jobs, and new admin accounts.
7. If you think you have been hit, take the server off the network, keep its logs, and look for web shells before you put it back.

If you use WordPress or a hosting company

Most WordPress sites are on managed hosting, so updating PHP is your host’s job, not yours. It is still worth logging in today to check:

• which PHP version your site runs (most hosts show it in the control panel). You want at least 8.5.12, 8.4.27, 8.3.36 or 8.2.35. If you are on 8.1 or older, switch to a supported version if your host offers one;
• whether your host has said anything about PHP2Shell. Many have been updating servers today.

Updating WordPress itself or its plugins does not fix this, because the bug is in PHP, underneath WordPress. And be wary of any plugin or copy-and-paste snippet claiming to fix PHP2Shell: Patchstack advises against them.

Be careful with “proof of concept” code

Since the leak, code has appeared on GitHub claiming to be a working PHP2Shell exploit. None had been verified at the time of writing, and fake exploits that install malware on the person running them are a well-worn trick at moments like this. If you want to test your own servers, wait for reputable scanners and vendors, and never run exploit code you have not read on a machine that matters.

What I am doing

I build most of what I make today on Cloudflare Workers, so subba and this site do not run PHP. But plenty of the businesses I work with run WordPress, and I am checking their PHP versions and hosts today. If you are not sure where your PHP is, or what to update first, I am happy to help.