On 21 October 2026 the PHP project closed two security vulnerabilities published under the name php2shell: CVE-2026-109618 and CVE-2026-109619. Both are rated CVSS v4.0 9.2, and both allow unauthenticated remote code execution. The problem does not sit in any single application, it sits in PHP itself. Attacks were observed before the patch was even available.
The name php2shell comes from the security research community. The PHP project itself simply lists the two flaws under their CVE numbers.
This article covers what the vulnerability is in technical terms, who is affected, what needs to happen now, and how we handle reports like this for the environments we manage.
What is php2shell?#
Both flaws are use-after-free bugs in the PHP engine, and both follow the same pattern. A fatal error during a request interrupts PHP mid-execution, typically when a request exceeds the configured memory limit. Memory is released, but a pointer to it remains in the worker process global state. The next request that hits the same worker reaches into that memory. Whoever controls what sits there by then controls the process.
The two variants differ in where the stale pointer survives. CVE-2026-109618 affects the upload progress unserializer, CVE-2026-109619 affects the stored backtrace of the most recent fatal error combined with a type confusion in OPcache.
Three properties make this dangerous. First, an attack needs no authentication and no user interaction. Second, a single request in multipart/form-data format is enough, the same format every ordinary file upload form uses. Third, the attack lands before your application code runs. The memory disclosure variant works even when the application never starts a session at all.
Confirmed impact includes remote code execution, server memory disclosure, arbitrary file reads and crashing worker processes.
Which PHP versions are affected?#
The short answer: every version since PHP 5.4, which means almost everyone running PHP.
- Every PHP version since 5.4 is affected by at least one of the two flaws, which covers practically everything shipped in the last decade.
- According to the PHP project, every PHP installation serving web requests is affected: PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed.
- A default configuration is enough. No unusual settings and no application bug are required.
One point matters for the assessment: your application is not the vulnerability. WordPress, TYPO3, Drupal, Joomla, Shopware and every in-house development run on PHP and inherit the problem from there. Updating the content management system does not fix it. PHP is what needs updating.
For scale: surveys put PHP behind roughly 70 percent of websites whose server-side language is known.
Are you affected?
Enter your PHP version, for example 8.2.12. The check runs entirely in your browser, nothing is transmitted.
Patched releases: 8.5.12, 8.4.27, 8.3.36, 8.2.35#
The PHP project published the following versions on 21 October 2026:
- PHP 8.5.12
- PHP 8.4.27
- PHP 8.3.36
- PHP 8.2.35
PHP 8.1 and older receive no official fix, because those branches have left support. The only options there are a distribution package with a backported fix or a move to a supported release. That is the uncomfortable part of this report, because in practice plenty of legacy applications still run on 7.4 or 8.0.
Timeline: leak, first attacks, patch#
The two flaws were meant to be disclosed in a coordinated way, but they came out before the agreed date. Cloudflare responded by switching its protection rules live roughly nine hours ahead of public disclosure: since 21 October at 03:02 UTC, customers on both the free and the paid WAF have been protected by default. What triggered that was not caution, it was attack traffic Cloudflare observed against its own customers.
For operations that means there was no quiet window for orderly planning. Anyone who has not updated by now is working against live attacks.
Why the php.ini one-liner is not enough#
Overnight on 21 October a one-line recommendation went around: session.upload_progress.enabled=0. This setting removes the trigger for three of the five documented attack paths. It does not close the vulnerability. The firm that originally suggested it has since said so itself. The PHP project names only one route in its security releases anyway, and it puts it plainly: all users are strongly encouraged to update immediately.
If you have good reasons why you cannot update immediately, the following measures buy time and nothing more:
- Block multipart/form-data requests at the web server or web application firewall. This usually disables file uploads and forms.
- Temporarily restrict affected services to GET and HEAD, so they run read only.
- Enable existing WAF rule sets. Cloudflare has rolled out seven rules in the free managed ruleset, seven in the paid managed ruleset and one response-based rule across all plans.
- Turn off uploads you do not need and cap the permitted upload size. That is Cloudflare's own recommendation for the window before patching.
How we protect clients from php2shell#
A vulnerability in the runtime cannot be organised away. What can be organised is the time between disclosure and an applied patch. That is exactly what a managed service is for, and this is how we work:
We know where PHP runs. For every environment we manage we maintain an inventory, including which services sit on PHP and in which version. Without that list the first question in a situation like this cannot be answered, and it is always the same question: does this affect us at all?
We assess instead of forwarding panic. Not every critical report hits every environment equally hard. Whether a service is reachable from the internet, sits behind a VPN or only answers internally determines the urgency. We make that assessment per customer before touching anything.
We inform actively, in both directions. Our customers hear from us when action is needed. They also hear from us when the outcome of the check is that their environment is not affected. That second message matters just as much, because otherwise a managing director reads a headline and is left alone with the question.
We patch in the maintenance window, and outside it when attacks are live. Which case applies is something we say beforehand, not afterwards.
We keep watching after the patch. With this vulnerability, crashing worker processes and unusual error patterns are an indicator of attack attempts. That is part of monitoring, not a separate task.
Patching php2shell: a six-step guide#
If you run your PHP systems yourself, this is the order:
- Determine the version. Running
php -von the server is not sufficient when the command line and the web service use different versions. Check the version per FPM pool and per virtual host. - Apply the patch. The target is 8.5.12, 8.4.27, 8.3.36, 8.2.35 or newer. On Debian, Ubuntu, RHEL and similar distributions use the vendor package, whose version number differs while still containing the fix.
- Restart the worker processes. An installed package alone is not enough while old processes keep running. PHP-FPM and Apache need a restart.
- Schedule your legacy versions. Wherever 8.1 or older runs, the upgrade needs a date now, not eventually.
- Ask your providers. With web hosting and external agencies, updating is the provider's job. Ask for their status and get the answer in writing.
- Review your logs. Look for clusters of worker crashes, memory errors and unusual multipart requests, particularly from 20 October onwards.
What this means for patch management#
The vulnerable code is more than ten years old. It was found now, and the researchers say openly why: they used current AI models for the analysis and for building the exploit. What would once have taken an experienced team months was feasible for one person in about a week.
That is the lesson reaching beyond php2shell. Old code is no longer a dormant risk. The gap between "this flaw has existed unnoticed for years" and "this flaw is being exploited" keeps shrinking, and it shrinks for all software at once. Patch management has stopped being a hygiene measure. It is a question of response time.
Conclusion#
php2shell is serious: unauthenticated code execution, a default configuration is enough, attacks are live, and practically every PHP installation on the internet is affected. The patch is available, and it is the only complete answer.
The more uncomfortable question comes next. If your organisation cannot answer within an hour which PHP versions run on which systems, that is the real issue. The next report of this kind will come. If you are weighing whether to carry that yourself, our comparison MSP or in-house IT admin lays out the arguments.
Not sure whether or where you are affected? Talk to us. We will check, and we will also tell you when no action is needed.
Sources#
- php.net, security releases PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 of 21 October 2026
- Cloudflare, protection rules and observed attack traffic
- Wiz Research, technical analysis and disclosure
- Imperva, assessment of the interim measures