PHP2Shell Flaw Leaves Millions of Websites Open to Takeover

More than 22 million PHP installations sat exposed online this week, facing two flaws that need no password. The details leaked before a patch existed. Updating WordPress does not fix it. The flaw is in PHP itself, the back end of most of the web.

On Tuesday, October 20, details of two unpatched holes in PHP started spreading online. A post on Hacker News announced that someone would disclose the bugs on October 22, with no patch ready. The post came down, but the screenshots had already gone around, including one of an exploit tool called PHP2Shell. Security firm watchTowr looked at what leaked and confirmed the flaws were genuine and allowed remote code execution. PHP had planned a quiet, scheduled fix. Instead it had to put one out while the details were already public.

The PHP team set an emergency release and said it might ship sooner if attacks appeared. Cloudflare reported early attacks against PHP sites on Wednesday morning and rolled out firewall rules to blunt them. The patch arrived in the afternoon, a little earlier than the planned 14:00 UTC release.

You could see how seriously people took it by what went dark. In the Netherlands, the site digid.nl, the government’s main login, showed a plain page: this website is temporarily unavailable. MijnOverheid went down with it, and so did the website of the national parliament and the site of the cyber agency, the NCSC, the people whose job is to warn the public. Logging in with DigiD on other services still worked, but its own site, and plenty of others, were gone. Tweakers and Security.NL, two of the country’s best-known tech sites, were offline as well.

It reached far past one country. Reuters reported that government websites in Europe and elsewhere went offline on Wednesday, with agencies in Finland among those that pulled their sites as a precaution. Cybersecurity agencies in Europe, Australia, Japan and Britain told PHP users to update at once or take their sites offline until they could. The EU’s CERT-EU said much the same: patch the moment a fix exists, and where that is not possible, consider cutting internet-facing applications off from the public internet until it is.

In Germany, Freiburg University took its central websites offline at 10:39 that morning, along with its intranet, the ILIAS learning platform and webmail for student addresses, and told its departments to pull their own PHP systems too. None of these were confirmed break-ins. They were organisations deciding it was safer to be unreachable than to keep running a version of PHP that someone could take over.

To understand why a government would rather go dark, you have to know where PHP sits. PHP runs the back end of most of the web. W3Techs puts it at 69.3% of all the sites whose server-side language it can identify, and WordPress, which by itself runs nearly 40% of all websites, runs on it. So do Magento for shops, Drupal and Joomla for larger sites, phpBB for forums, WHMCS for hosting billing, and MediaWiki, the software behind Wikipedia. None of those applications contains the bug. It sits in the PHP underneath them, so you can write a site perfectly and it is still exposed.

The release fixed two separate problems. The first, CVE-2026-109618, lives in the way PHP handles running out of memory. When a request uses too much memory, PHP jumps out of whatever it was doing to shut that request down cleanly. The trouble is that the memory for a request is sometimes reachable before it has been fully set up. If an allocation fails at that moment, PHP does not account for the early exit. The cleanup step then works on data that was never valid, and a carefully built request can turn that confusion into running the attacker’s own code on the server.

What makes it practical is how easy that out-of-memory moment is to force. PHP reads the body of a form upload, the multipart/form-data type a browser sends when you attach a file, before your application code ever runs. A request that never declares a usable length can slip past the post_max_size limit meant to stop oversized uploads. Empty file fields do not count against the max_file_uploads cap, yet PHP still builds the full set of internal records for each one. Combine enough of those and memory runs out on command, at the exact spot where the first bug lives.

The second flaw, CVE-2026-109619, is a different kind of mistake. A PHP worker keeps some state in memory between requests, things like error and session data. PHP should wipe that state before it hands the memory back. A fatal error, including one from that same out-of-memory trick, can skip the cleanup. PHP frees the memory while the worker still points at it. The next request reads a pointer to memory that no longer belongs to it. That is a use-after-free, and with the right heap layout it too ends in code running with the web server’s own privileges.

This weak spot is not new. In 2004, the researcher Stefan Esser found the first remote bug in the way PHP handles its memory limit. In 2020, a bug report flagged the same out-of-memory behaviour around file uploads. In 2024, a security audit by OSTIF and Quarkslab found a related memory problem, though researchers could not prove it was exploitable at the time. The two flaws patched today are where that long-running weakness finally turned into a working attack.

PHP rated both flaws 9.2 out of 10, critical but not a perfect score. The number reflects that the attack is not trivial: it takes high complexity and the right conditions to line up. Some early reports threw around a 10.0; the official rating is 9.2. It is still an unauthenticated attacker, reaching in across the internet, ending with code running on the server. The gap between 9.2 and 10.0 means little when proof-of-concept code is already public.

One detail in the advisory matters if you run a server. For the first bug, PHP’s own analysis proved the full attack over HTTP on Apache with mod_php, the classic setup where PHP runs inside the web server, on default settings. It calls PHP-FPM, the setup many managed hosts use, susceptible too, though no complete exploit of that first bug has been shown against it. The second bug changes the picture. PHP says the session route reached working code execution on both mod_php and FPM, so FPM is not the safer option it might look like. Both setups need the patch now.

The flaws did not come from attackers. They were reported to the PHP team, which worked on a fix before the details were meant to be public. The repair is in the core of PHP. The developers took out the risky jump-out-on-low-memory step at the root of the first bug, and made the worker clear its leftover state properly to close the second. That is what today’s release fixes.

The patched versions are:

• → PHP 8.5.12
• → PHP 8.4.27
• → PHP 8.3.36
• → PHP 8.2.35

Anything below those is vulnerable. PHP 8.1 and older no longer get updates from the PHP project, and one scan on October 20 found around 884,000 internet-facing servers still running 8.1 or older. The PHP team put out minimal backports for 7.4, 8.0 and 8.1 for people who build PHP from source, but anything past that is on its own. In India, one scan counted 19,847 servers on versions that no longer get security fixes. And PHP 8.2, the oldest branch still supported, reaches end of life on December 31, 2026, so sites on it should patch now and plan the move to a newer version.

Different scanners give different totals, but they point the same way. VirusTotal fingerprinted around 5.1 million internet-facing addresses running PHP. Palo Alto’s own scan flagged more than 22.6 million instances as potentially vulnerable. The exact figure matters less than what it shows: PHP is one of the most widely installed pieces of software on the internet, on millions of servers at once. Security officials put what exposure means in plain terms. A server that gets taken over can have its data stolen, its logins broken and its pages pulled down.

If you run a WordPress site, this is the part that catches people out. Updating it does not close the hole, and neither do your plugins, because the fix is to PHP, which lives on the server underneath them. The same goes for any PHP application, whatever it runs on. The only thing that matters is the version of PHP your host runs, and whether they have updated it. If you do not manage your own server, the only fix is the one your host installs, so ask your hosting provider to apply the PHP update now.

The good news is that checking where you stand takes a minute. On your own server you can ask PHP its version:

1

php -v

One catch: that shows the command-line PHP, which is not always the version your website runs. Check what the site itself reports, for example with php-fpm8.3 -v or a phpinfo page. If it comes back below 8.2.35, 8.3.36, 8.4.27 or 8.5.12, you are exposed and need the patch. After updating, restart PHP-FPM or Apache, because workers that are already running keep the old code until you do. On shared hosting where you cannot run any of this, the safer move is to contact your host today and ask one question: have you applied the October 21 PHP security release. The configuration tweaks going around, like turning off session upload progress, only block one path and do not make the server safe. Only the patch closes the hole.

A newer version number is not always proof you are safe. Distributions often patch by backporting the fix into a package that still shows an older version, so the number alone can mislead. The surer check is the package changelog. On Debian or Ubuntu, running apt changelog php8.3-cli lists the recent changes; on Red Hat systems, rpm -q --changelog php does the same. If one of the two CVE numbers shows up there, the fix is in. If it does not, the package has not been touched yet, whatever the version says.

Whether attackers are already using this against live sites is not clear. Cloudflare saw attack attempts against PHP sites on Wednesday morning, and hosting companies reported the same. As of October 21 there was no confirmed break-in: the Dutch cyber agency said it had seen no active abuse, and neither flaw appeared yet on the US government’s list of known exploited vulnerabilities. Unit 42 said it had seen proof-of-concept code, not a live intrusion. By late afternoon the patch was out, a little before the planned 14:00 UTC release, though many sites that had gone dark stayed down into the evening.

What took government websites offline in country after country was a flaw that had sat in the most common software on the web for years, until the day its details leaked. Public proof-of-concept code is out now, and after a leak like this, mass scanning usually starts within hours. If you own anything that runs PHP, a blog, a shop, a forum, a company site, what counts now is whether your server was patched before someone came looking.

Do you know which version of PHP your own site runs on, and what an attacker sees when they scan it from the outside?

My Ethical Hacking Complete Course Zero to Expert takes you there step by step: reconnaissance, scanning, exploitation and traffic analysis, hands-on, from your first day with no Linux or hacking background.

→ Join my complete ethical hacking course

Hacking is not a hobby but a way of life.

Sources: PHP Security Advisory | CVE-2026-109618 Advisory | CVE-2026-109619 Advisory