PHP2Shell (CVE-2026-109618, CVE-2026-109619): How to Tell If You Are Actually Patched

On 21 October 2026 the PHP project shipped emergency patches for two vulnerabilities that are about as bad as web infrastructure bugs get. Both are rated CVSS 9.2. Both allow an unauthenticated attacker to run code on your server. And unlike the usual stream of WordPress plugin advisories, these are in the PHP runtime itself, which means no amount of careful application code protects you.

The pair has been nicknamed PHP2Shell. If you run PHP anywhere that serves web requests, you need to read the short version below and then go and check your hosting.

The short version

• CVE-2026-109618 and CVE-2026-109619, both CVSS 9.2, both unauthenticated remote code execution.
• They affect the PHP runtime, not a framework or a plugin. Apache mod_php and PHP-FPM are both affected.
• Patched releases: PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35.
• PHP 8.1 and older get no standard upstream release, but that does not mean no fix. Source-level backports exist for 7.4, 8.0 and 8.1, and vendors are shipping patched packages — AlmaLinux has patched every PHP stream it ships, including 7.4. Check your vendor before assuming you are stranded.
• Technical details leaked publicly on 20 October, before the patch was available. Security researchers have confirmed a working exploit.
• The PHP team is explicit that updating is the only complete mitigation.

Why this one is different

Most critical web vulnerabilities live in application code. A plugin mishandles an upload, a framework deserializes something it should not, a route forgets an authorization check. The fix is to update that component, and the blast radius is whoever installed it.

PHP2Shell sits underneath all of that. The vulnerable code runs as part of handling the HTTP request, which means it can be reached before your application has made a single decision. Your authentication does not help. Your input validation does not help. A site with no plugins, no user accounts and no upload forms is still exposed, because the attack surface is the interpreter.

This is why the advisories have been unusually blunt. PHP states that every installation serving web requests is at risk in a default configuration.

The patched versions

If your PHP is at or above these, and your build genuinely includes the fix, you are patched:

• PHP 8.5 branch: 8.5.12
• PHP 8.4 branch: 8.4.27
• PHP 8.3 branch: 8.3.36
• PHP 8.2 branch: 8.2.35

Older branches are a more nuanced story than "end of life, bad luck". There is no standard upstream release for 8.1 and below, but there are source-level backports for 7.4, 8.0 and 8.1, and distributions that still support those branches are shipping fixed packages — AlmaLinux published patched builds for every stream it ships, its 7.4 stream included.

So if you are on an older branch: do not assume you cannot be patched, and do not assume you have been. Ask your vendor specifically. What is true is that you are relying on someone else's goodwill for security fixes on a branch upstream no longer supports, and this is a reasonable moment to start planning the upgrade you have been postponing.

The trap: your version number probably cannot answer this

Here is the part that catches people, and the reason we are not going to pretend a scanner can settle it for you.

Linux distributions routinely backport security fixes without changing the upstream version number. Debian, Ubuntu, RHEL and others take the patch, apply it to the version they already ship, and increment their own package revision instead. The result is a server reporting PHP 8.2.11 that is fully patched, sitting next to a server reporting PHP 8.2.11 that is not.

That cuts both ways:

• A version number below the fixed release does not prove you are vulnerable. Your distribution may have backported the fix hours ago.
• A version number at or above the fixed release is good evidence, but only if the build really is the upstream one.

Any tool that reads a version string off an HTTP header and tells you confidently that you are vulnerable is guessing. So is any tool that tells you confidently that you are safe. The only authority on whether your server carries this patch is whoever builds your PHP: your hosting provider, your distribution, or you.

How to actually find out

If someone else runs your hosting — shared hosting, a managed WordPress host, a platform — ask them directly. The question to send is specific: "Which PHP build are you running, and does it include the fixes for CVE-2026-109618 and CVE-2026-109619?" A good host will have published a status page entry already. Most of the large ones patched within hours.

If you run your own server, check your distribution's security tracker for your exact package version rather than comparing against the upstream number. Then confirm the running workers actually picked it up. Updating the package does not fix a PHP-FPM pool that has been running since last Tuesday — the old code stays resident in memory until the workers restart.

One gotcha worth knowing: the PHP you see on the command line is often not the PHP serving your site. A CLI binary and an FPM pool can be different builds with different configuration entirely. Check the version your web server is actually using, not whatever php -v prints over SSH.

If you genuinely cannot patch today

Interim measures exist, but we want to be straight about them: they are incomplete, every advisory says so, and none of them is a substitute for updating. They buy hours, not weeks.

• Limit request size. Setting a low post_max_size reduces the attacker's room to manoeuvre. Around 8M is workable for applications that do not accept uploads, 32M if they do.
• Set the memory limit where applications cannot override it, using php_admin_value in the FPM pool or Apache configuration rather than a value your application can change at runtime. Note the trade-off carefully: removing the limit entirely means a single request can consume all available memory on the box, which is its own outage.
• Container or cgroup limits can contain the damage to availability, though they are a boundary rather than a fix.

One piece of advice circulating widely deserves a flag: disabling session.upload_progress is not a reliable mitigation here. It appeared early in the response and spread fast, but analysis since suggests it does not address CVE-2026-109618 at all. If you turned it off and moved on, you are probably still exposed.

Be wary of one-line fix scripts doing the rounds too. Several appeared within hours of disclosure. Running an unreviewed script as root on a production server, during an active exploitation window, to fix a remote code execution bug, is a trade you should think about before making.

What an external scan can and cannot tell you

We build a security scanner, so it would be convenient to say we can detect this. We cannot. An external scan alone cannot reliably establish whether your PHP runtime carries these patches — not ours, and not anyone's, because the evidence simply is not visible from the outside.

What an external scan can usefully tell you right now is whether your server is advertising information it should not:

• An X-Powered-By header announcing your PHP version.
• A reachable phpinfo.php file, which publishes your exact build and configuration to anyone who asks.
• PHP error messages leaking file paths in responses.

On a normal week those are housekeeping findings. This week they are worse than that: they hand an attacker your precise patch level during a window when a working exploit exists and a public one is expected. If a scan flags them, fix them today.

But that is a different statement from "you are vulnerable to PHP2Shell", and we are not going to make the second one from the outside. A scanner that tells you your site failed a check it never actually ran is worse than a scanner that admits what it cannot see.

What to do this week

1. Find every host you own that runs PHP. Include the ones you forgot: staging environments, old client sites, that one legacy box.
2. Ask each provider the specific question above, or check your distribution's tracker for your exact package version.
3. Restart PHP-FPM or Apache after patching. The fix is not live until the workers recycle.
4. Stop advertising your PHP version. Set expose_php = Off, remove X-Powered-By, and delete any phpinfo.php you find.
5. Check your logs for the window between 20 October and whenever you patched. Leaked details preceded the patch, so that gap is the period worth reviewing.
6. If anything is still on PHP 8.1 or older, ask that vendor whether a patched package exists — several have shipped one — and start the upgrade conversation regardless.

Sources

This post was written on the day of disclosure from the following published advisories and analyses. Where they disagree — and on the technical root cause, they do — we have described the effect rather than picking a side.

• The PHP project — official advisory and patched releases.
• Tenable — FAQ, CVSS scoring and affected versions.
• Rapid7 — exploitation status and confirmation of a working exploit.
• Sansec — technical analysis of the underlying flaws.
• Huntress — disclosure timeline and the pre-patch leak.
• BleepingComputer — release coverage.
• Help Net Security — mitigation guidance.
• AlmaLinux — distribution package status, including older PHP streams.

Advisories are still being updated as analysis continues. Where this post and an official advisory disagree, trust the advisory.

Run a free scan at websentry.dev to see whether your site is leaking its PHP version, exposing phpinfo.php, or returning error messages that reveal its stack — alongside the rest of your SSL, headers, CSP, cookies and DNS posture. It will not tell you whether you are patched. Your host will.