On 20 October 2026, the instructions for taking over a large slice of the web leaked online. Not the day after a fix shipped, the day before. For nearly 24 hours, anyone could get hold of a working attack against PHP while no patch yet existed.
The flaw carries a nickname that says it all: PHP2Shell. Like Log4Shell in 2021, it sits inside a software component so widespread that almost no one can say “this doesn't affect me” without checking first. Here is what it is, how to tell whether you are exposed, and what to actually do about it.
PHP2Shell is the name given to two critical flaws in the PHP language, found at almost the same time: CVE-2026-109618 and CVE-2026-109619.
Both score 9.2 out of 10 for severity, right at the top of the scale. Both allow the same thing: running code on your server with no password, no account, no authentication whatsoever.
PHP is the invisible engine behind a huge part of the web: roughly 70% of sites with a known server-side language rely on it. WordPress, Drupal, Joomla, Magento, your online shop, your intranet, the little in-house tool cobbled together six years ago: underneath, it is very often PHP. That is exactly what makes PHP2Shell dangerous: the flaw is not in an application, it is in the engine itself.
The fixes landed on 21 October at 16:00. Too late to get ahead of it: the exploit code was already circulating, and Cloudflare saw the first attacks before the patch was even released. Germany's cybersecurity agency (BSI), CERT-EU and the UK's NCSC all issued emergency alerts. In the Netherlands, some public services were simply taken offline as a precaution. This is not a sysadmin footnote.
To picture it, think of a server's memory as a shared desk. On every visit to your site, PHP lays out its files on the desk, does its work, then tidies everything away before the next visit.
Both flaws abuse that tidy-up.
The first (CVE-2026-109618) strikes when PHP is abruptly interrupted, for instance because a request exceeds the allowed memory: the cleanup goes wrong, and bits of files are left lying on the desk.
The second (CVE-2026-109619) abuses ghost data from an earlier visit that survives and is mistaken for current data on the next one.
In both cases, an attacker sending carefully crafted requests can slip their own code into those leftovers and have it executed.
The known trigger is a simple file-upload request (in technical terms, multipart/form-data), handled by PHP before your application code even starts. In other words, even a site with perfectly clean code is vulnerable, because the flaw plays out upstream. What's worse, the default feature that tracks upload progress (session.upload_progress) is one of the confirmed entry points, and it is on out of the box. Beyond takeover, these flaws can also leak memory (passwords, session tokens, API keys).
The flaw lives in the PHP engine, not in your applications. It covers every way of serving PHP over the web: Apache mod_php, PHP-FPM, php-cgi, LiteSpeed. The vulnerable code has existed since PHP 5.4, released in 2012. Researchers confirmed unauthenticated takeover against applications as common as WordPress, Drupal, Joomla, Magento, MediaWiki, Nextcloud, phpMyAdmin, Roundcube, Laravel, Symfony and WHMCS. If you host any of those, assume you are affected until proven otherwise.
The first step is not to patch, it is to take inventory. You cannot fix what you don't know you have. List every PHP install across your estate: web servers, business applications, vendor appliances, containers, and anything running a CMS.
For each install, compare the version against the ones that fix the flaw: PHP 8.2.35, 8.3.36, 8.4.27 or 8.5.12. Below those, you are vulnerable. PHP 8.1 and earlier branches no longer receive an official fix, only source-code patches for 7.4, 8.0 and 8.1. The command-line version (php -v) gives a first clue, but watch two traps:
- The version served to the browser can differ from the command-line one, and above all, what matters is the version actually loaded in memory by the web server, not the ones installed on disk. A fix installed without restarting the processes offers no protection: the old PHP processes are still running the old code. So the rule is: patch, then restart Apache, PHP-FPM and all workers.
- An important and reassuring point: an old PHP version that is installed but not used poses no risk for this attack. PHP2Shell needs a web request reaching a PHP interpreter that is in use. A PHP binary sitting idle on a disk, exposed by no web server, listening on no port and handling no HTTP request, is not affected by this exploit. Updating or removing it is still good hygiene, but it is not the same order of emergency as a PHP exposed to the internet. The absolute priority is the exposed installs.
Take a fictional but realistic SME of 30 people. The main website is up to date and well looked after. Except that on the same server sits an old internal tool, a leave-request form built seven years ago, running on PHP 7.4 under mod_php, reachable from the internet “because a salesperson needed it on the road”. No one thinks about it any more. It gets no updates.
This is exactly the kind of tool you need to pin down. The monitored website will be patched fast. The forgotten form, though, is an entry point on PHP 7.4 (with no official fix), exposed, and off everyone's radar. When we are called in on this kind of incident, the first thing we look at is not the main site: it is the forgotten services.
The only complete fix is updating to a patched version, followed by restarting the services. When you cannot patch within the minute, the flaw's official site (php2shell.com) lists several interim mitigations. The most useful ones:
session.upload_progress.enabled = 0) in the server configuration. PHP's developers warn that this measure alone is not enough.multipart/form-data requests outright at the front end.post_max_size) and the nesting depth (max_input_nesting_level) to what the application strictly needs.display_errors = 0), and on PHP 8.5, disable error backtraces (fatal_error_backtraces = 0).expose_php = 0): it reduces the information handed to attackers, even if it fixes nothing.A web application firewall (WAF) can help filter known attacks while you patch, we cover this in our article on CrowdSec in front of HAProxy, but it is a temporary net, never a substitute for the fix. And for any server that genuinely cannot be updated quickly: isolate it or take it off the network, full stop. Finally, if you have the slightest doubt about a compromise, assume everything the PHP process could read may have leaked, and rotate your passwords and keys.
Before restarting a suspect server, preserve the logs: they are what will tell you whether someone merely knocked, or got in. When in serious doubt, your best insurance remains a clean, tested backup.
PHP2Shell is not one more flaw in some obscure plugin: it is a defect at the heart of the engine that runs half the web, exploitable without a password, with attack code already in the wild. Take inventory before someone else does it for you.