PHP's 21 October 2026 Security Release: How to Tell If Your Website Is Exposed
PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 fix two critical flaws that can let an unauthenticated attacker run code on your server. Which versions are safe, how to check your site, and why an old-looking version number is not always a problem.
On 21 October 2026 the PHP project released PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. They fix two critical vulnerabilities that, under the right conditions, let an unauthenticated attacker run code on a server running PHP.
If your website runs on PHP, and most WordPress, Drupal, Magento and WooCommerce sites do, it needs updating now. This article covers what was fixed, which versions are safe, and how to check where your site stands.
What was fixed
Both flaws sit in parts of PHP that nearly every request touches: memory management and error handling.
Memory corruption at the memory limit
A request that hits memory_limit at exactly the wrong moment can leave half-built internal data behind, which PHP later treats as valid.
Stale state after a fatal error
A fatal error at the wrong point can leave internal state pointing at memory from a previous request, which a later request then reuses.
The PHP Foundation’s announcement explains how the issues were found and fixed. The advisory on php.net has the technical detail and update instructions.
Which versions are safe
Each supported branch has one release that carries the fix. That release, or anything later on the same branch, is patched.
| Branch | Patched from | Status |
|---|---|---|
| 8.5 | 8.5.12 | Supported |
| 8.4 | 8.4.27 | Supported |
| 8.3 | 8.3.36 | Supported |
| 8.2 | 8.2.35 | Supported |
| 8.1 and older | No fix | End of life |
There is no fix for PHP 8.1 or anything older. Those branches have reached end of life, so a site on them needs to move to a supported branch, not wait for a patch.
Check your site
There are two ways to find out which version a site is running.
Run php -v on the server
The first line shows the version. If your host offers several PHP versions, the website may use a different one from the command line, so check the site’s own setting too.
Check your control panel, or ask your host
cPanel lists the site’s version under MultiPHP Manager and Plesk under PHP Settings. Managed hosts often patch for you; it is still worth confirming they have.
When an old-looking version is not a problem
Ubuntu, Debian and Red Hat ship their own PHP packages and backport security fixes into them without changing the main version number. Ubuntu 22.04, for example, reports PHP 8.1.2 and keeps patching it for as long as that Ubuntu release is supported.
A version with a distribution suffix cannot be judged against the table above. Red Hat’s builds, and rebuilds such as AlmaLinux and Rocky Linux, usually report a plain upstream number instead, so if your server runs one of those, go by the advisory rather than the number.
After you update
Restart PHP
Updating the package is not enough while the old PHP-FPM or Apache processes keep running. Restart them so the new version is the one serving requests.
Check again
Run php -v or look in your control panel to confirm the patched version is the one serving the site.
Stop publishing the version
Set expose_php = Off in php.ini, and on Apache set ServerTokens Prod and ServerSignature Off. This fixes nothing on its own, but it stops advertising what to target next time.
Look for changes you did not make
If the site ran a vulnerable version, check for unfamiliar files, new administrator accounts and scripts you did not add.
Patching closes the hole. It does not tell you whether anything got in first.
Website Malware spots hidden code, card-stealing scripts and vandalised pages on your own sites from the outside, with evidence your team can act on. Website Monitoring keeps watching your pages and the code they load, so a change you did not make is flagged when it appears, not when a customer reports it.
