On 21 October 2026, the PHP team shipped an emergency security release. It fixes two vulnerabilities which, taken together, have been named PHP2Shell — and both of them let an attacker run code on the server without authenticating.
If your site runs on PHP, as most of the web still does, this article tells you what happened, how to find out whether it concerns you, and what to do about it.
What happened, briefly
Two separate but related vulnerabilities, found in the core of PHP — in memory management and in error handling, which is to say in exactly the parts every request passes through:
- CVE-2026-109618 — code execution through memory corruption when memory runs out (out-of-memory)
- CVE-2026-109619 — code execution through global state left behind by an earlier request
Both score CVSS 9.2 out of a maximum of 10. The fix shipped in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35.
Why it is serious: one request, ahead of your code
This is what sets it apart from the usual plugin or theme vulnerability.
With the first of the two, on an Apache with mod_php setup, an unauthenticated request can trigger the problem before your application runs anything at all. It does not matter that your WordPress is well maintained, your plugins updated and your passwords good — your code never gets as far as starting. The PHP team considers mod_php the highest-risk configuration.
Code execution has also been confirmed on PHP-FPM, through paths that do pass through application code. In practice, any installation serving web requests is exposed: PHP-FPM, mod_php, php-cgi, FrankenPHP, LiteSpeed.
The two problems, in plain words
Corruption when memory runs out. PHP enforces memory_limit by cutting the offending request off abruptly. If that interruption lands in the middle of an operation — while a file uploaded through a form is being parsed, say — half-built internal data is left behind. The cleanup at the end of the request then treats it as valid and frees memory that was never initialised. That memory can hold data an attacker put there earlier.
State left between requests. A fatal error at a bad moment can leave internal state pointing at memory that has already been freed. A following request, served by the same worker, uses it before normal initialisation resets it. Hence a confirmed use-after-free, and code execution demonstrated against a real application.
How to find out which version of PHP you have
With SSH access:
php -v
If all you have is cPanel or a panel from your host, the version is usually under Select PHP Version or PHP Manager. If you cannot find it, ask your provider directly: "which PHP version does my account run, and when are you applying the patch for CVE-2026-109618?"
You are in the clear only on 8.5.12, 8.4.27, 8.3.36 or 8.2.35 — or newer. Anything else on those branches is vulnerable.
If you are on PHP 8.1 or older
This is the part that touches the largest number of sites, because the old branches are still very common on shared hosting.
PHP 8.1 and older are out of support and get no updates from the project. Because of how serious this one is, though, the PHP security team published minimal source backports for 7.4, 8.0 and 8.1, for anyone who compiles their own or has no provider shipping patches. Many Linux distributions and long-term-support vendors ship fixed builds of their own as well.
Concretely: if you are on 7.4 or 8.0 you are not automatically lost — but you depend entirely on your provider. Ask them. And if the answer is "we are not doing anything", you have also been handed the reason to move to a supported version. We wrote separately about what shared hosting means next to a VPS, because this is exactly where the difference shows: on shared hosting, somebody else applies the patch, whenever it suits them.
If you cannot update today
CERT-EU is explicit: only updating fixes the problem completely. The measures below reduce exposure on the confirmed paths, but they do not make the installation safe:
- for the first vulnerability,
memory_limit=-1enforced so the application cannot override it, plus a smallpost_max_size—8Mwhere no files are uploaded; - for the second,
session.upload_progress.enabled=0and a restart of every worker; on PHP 8.5,fatal_error_backtraces=0as well.
If even that is out of reach, the official recommendation is to isolate the application from the internet until you have applied and verified the fix. It is harsh, but it beats a compromised server.
What else happened around the release
The coordinated disclosure held until two days before the deadline. On 20 October, the two CVE numbers started going round forums and social networks — with the wrong release time and the wrong score, 10.0 instead of 9.2. No technical detail, but enough for the PHP team to bring its announcement forward and ship a day early.
Meanwhile, Amazon reported that its honeypot network had recorded an exploitation attempt on 17 October — four days before public disclosure. Cloudflare reported attack traffic, including attempts to get around its protections.
Translated for a site owner: this is not a theoretical problem, and it is no longer a race you can postpone.
What we do for the sites we maintain
For clients on a maintenance plan, security updates like this one are part of the package: we check the version, apply the patch or ask the hosting provider for it, and confirm the site still works afterwards. It is not something you have to ask us for — it is the reason the plan exists.
If nobody is looking after your site and you do not know where to start, write to us and we will work out together which version you are on and what needs doing. And if you conclude that the current site is too old to be worth maintaining, we can talk about a new one — but patch it first, because that part is urgent and cheap.
The rest of what we do is here.
