Is your PHP server running a version that can be taken over?
Two critical flaws in PHP itself let anyone run commands on a web server without a password. Patches shipped on 21 October 2026. Paste your version below — you will get a verdict and the exact command for your platform.
Nothing is uploaded. The check runs in your browser.
Check a server version
Paste the output of php -v, the “PHP Version” line from phpinfo(), or just the number (for example 8.3.6).
Where do I find this?
Managed hosting: look in your control panel (cPanel → “Select PHP Version”, Plesk → “PHP Settings”). WordPress users on shared hosting: the PHP version is set by the host, not by WordPress. If you have shell access, run php -v. To see the version the web server actually uses — which is the one that matters — create a temporary file containing <?php phpinfo(); or check your host's status page, then delete it.
Last verified against the PHP security advisory on 22 October 2026. If your host gives you a version with a build suffix — 8.3.6-0ubuntu0.24.04.13 — read the note under the result: distro packages backport the fix without changing the upstream number.
The short version
- It is not a WordPress, Drupal or plugin bug. The flaw is in the PHP engine, so updating your site, theme or plugins changes nothing. Only the server's PHP runtime can be fixed.
- One request is enough on Apache
mod_php. The exploit runs before any of your application code executes, so logins, firewalls inside the app, and admin-only pages do not help. - Updating is not finishing. Every PHP worker that was running before the update keeps the vulnerable code in memory. The fix is the new version plus a restart of the web server and PHP-FPM.
Fixed versions
| Branch | Fixed release | Anything below this is vulnerable |
|---|---|---|
| PHP 8.5 | 8.5.12 | 8.5.0 – 8.5.11 |
| PHP 8.4 | 8.4.27 | 8.4.0 – 8.4.26 |
| PHP 8.3 | 8.3.36 | 8.3.0 – 8.3.35 |
| PHP 8.2 | 8.2.35 | 8.2.0 – 8.2.34 |
| PHP 8.1 and older | No official release | Needs a vendor backport, or upgrade. PHP 8.2 itself reaches end of life on 31 December 2026. |
The most common mistake in this incident: a host reports “we're on 8.3.6, you're fine.” Debian and Ubuntu ship the fix as 8.3.6-0ubuntu0.24.04.13 — the upstream number never changes. Compare the full package version against your vendor's advisory, not the first three numbers.
Three things to do, in order
1. Patch
Update PHP on the server, then restart Apache, PHP-FPM and any container that runs it.
Platform commands →2. Verify
Check the version the web server reports, not the one the command line reports, and confirm the workers restarted.
Verification steps →3. Look for damage
Exploitation attempts were seen from 17 October. If the server was exposed and unpatched, treat it as possibly compromised.
Compromise checklist →What actually happened
PHP disclosed two memory-safety flaws on 20 October 2026 after the CVE identifiers leaked, and shipped emergency fixes the next day. Researchers at Calif, Wiz and OpenAI found them with the help of frontier AI models; code paths in the engine had been present since at least PHP 5.4, and a 2024 audit had flagged the underlying issue without proving it exploitable.
The US NSA advised organisations that could not patch to take systems offline. Several governments and media organisations — including parts of the Dutch and Finnish government, the BBC, and Wikimedia systems — took services down deliberately rather than run unpatched. Exploitation attempts were recorded in the wild from four days before the patch.
Full timeline and technical explanation →
Don't want to do this yourself?
Checking one site is a five-minute job. Checking a server with several PHP versions, a control panel, containers and a staging copy is not — and proving it afterwards is the part auditors ask about.
Get help with the fix Read the runbook first