On 21 October 2026 the PHP project shipped an emergency release for two vulnerabilities that together are being called PHP2SHELL. Both are tracked as critical, at CVSS 9.2. An attacker can run code on a server with a single web request, without logging in and before any of your application code runs.
If you run a site on PHP, read the "How to check your site" section below. If a hosting company runs PHP for you, the short version is to ask them which PHP build you are on and whether it carries the fix. Our host patch-status study tracks where the major hosts stand, and our exposure checker gives you a quick read on your own site.
What PHP2SHELL actually is
PHP2SHELL is two separate bugs in how PHP handles memory during a request, disclosed together. CVE-2026-109618 can leak memory from the server, including things like session tokens and private keys, and can lead to remote code execution. CVE-2026-109619 can lead to remote code execution through reuse of internal state between requests. You do not need the technical detail to act on this: the flaw lives in PHP, it needs no authentication, and the only real fix is a patched PHP version.
Which versions are affected
The vulnerable code has been present since PHP 5.4, so in practice every PHP version is affected unless it is one of the fixed releases below or carries a vendor backport. Servers running Apache with mod_php or PHP-FPM are the most exposed.
| PHP branch | Fixed in | Notes |
|---|---|---|
| 8.5 | 8.5.12 | Update to this build or later. |
| 8.4 | 8.4.27 | Update to this build or later. |
| 8.3 | 8.3.36 | Update to this build or later. |
| 8.2 | 8.2.35 | Update to this build or later. |
| 8.1, 8.0, 7.4 | No php.net release | End of life. The fix comes from your Linux distribution, an LTS vendor, or a source backport. A backported package keeps its old version number, for example 8.1.34. |
| 7.3 and older | No fix | Upgrade to a supported, patched branch. |
The PHP project published the fixed builds on 21 October 2026. There is no configuration change that fully closes the hole, so a patched PHP version is the fix.
Are you affected?
Assume yes if any of these is true and you have not updated PHP since 21 October 2026:
- You run a server with PHP installed, such as a VPS, a dedicated server, or a cloud instance you manage.
- You run WordPress, Drupal, Joomla, Laravel, Magento, or any PHP application on hosting you control.
- You maintain a custom PHP site.
You are likely covered already, but should confirm, if a managed host runs PHP for you and has deployed the patch.
How to check your site
If you manage the server yourself, check the installed PHP version against the table above, then confirm the patch is actually in your package. On Debian or Ubuntu:
zgrep CVE-2026-109618 /usr/share/doc/php*-common/changelog.Debian.gz
On RHEL, AlmaLinux, or Rocky:
rpm -q --changelog php-common | grep CVE-2026-109618
A match means the fix is installed. After updating, restart every PHP worker (PHP-FPM, or Apache if you use mod_php), or the old code stays in memory.
If a hosting company manages PHP for you, you usually cannot read the exact patch level from outside. Ask your host directly whether they have applied the 21 October PHP security release, or check their status page. Our study collects what the major hosts have said so far.
How to fix it
- Update PHP to the fixed build for your branch. This is the fix. Nothing else closes the hole on its own.
- Restart your PHP workers after updating.
- On an end-of-life branch (8.1, 8.0, 7.4), get the backport from your distribution or an LTS vendor, or upgrade to a supported branch. On 7.3 or older, upgrade.
- If a host runs PHP for you, confirm they have patched rather than assume it.
If you cannot patch immediately
A few stopgaps reduce exposure, but none is a substitute for the update, and some can break your site:
- A web application firewall can block known attack patterns. Cloudflare, for example, pushed rules for these CVEs on 21 October to all plans, including the free tier. Keep a firewall on while you patch, but do not treat it as the fix.
- The UK's National Cyber Security Centre advises taking any system that cannot be patched quickly offline until it can be.
Blocking file-upload requests or changing PHP session settings only reduces the risk partially and can stop uploads from working, so patch as the real remedy.
Is it being exploited?
Exploitation attempts have been reported in the wild since disclosure, and one honeypot logged an attempt four days before the public announcement. Researchers disagree on how easily the flaw can be weaponised against a default setup. As of 22 October 2026 neither CVE is in the US CISA Known Exploited Vulnerabilities catalog. The safe assumption is to patch now rather than wait for that to change.
FAQ
- Does updating WordPress or my plugins fix PHP2SHELL?
- No. The flaw is in the PHP runtime, so only a patched PHP version fixes it. Keep your applications updated for other reasons, but that is separate.
- I'm on managed hosting. Do I need to do anything?
- Confirm your host has deployed the patch. Many have, some are still rolling it out, and on unmanaged plans it is your responsibility. See our host patch-status study for where each host stands.
- Which PHP versions are safe?
- 8.5.12, 8.4.27, 8.3.36, 8.2.35, or a build from your distribution or LTS vendor that carries the backport for an older branch.
- Can a firewall protect me instead of patching?
- It helps while you patch. It is not a replacement, because the flaw is in PHP itself.
Keep reading: Which hosts have patched PHP2SHELL and the exposure checker.
By W. Miller · Editor, Digital Hosting ·