On this page (7 sections)
PHP has released versions 8.5.12, 8.4.27, 8.3.36 and 8.2.35 to fix two critical vulnerabilities, according to a Wordfence notice published on 2026-10-20. Wordfence's key warning is that WordPress updates will not apply this fix, so the PHP version on your server has to be updated separately.
If you run a WordPress site, a PHP application or a hosting server, this applies to you. Only one publisher has covered the story so far, and the research behind this article contains no details of the two flaws. This article therefore sticks to what is confirmed and to how you can check and update your own PHP version.
What happened
Wordfence's notice, titled as a heads-up about an upcoming critical PHP security release, states that PHP has released four patch versions across the 8.5, 8.4, 8.3 and 8.2 branches to fix two critical vulnerabilities. Wordfence says it has published a separate advisory with details, but that advisory was not included in the research we reviewed. We therefore cannot describe the nature of the flaws, how they are triggered or what an attacker could achieve.
What is confirmed is the list of fixed versions and Wordfence's statement that WordPress updates will not apply the fix.
Why a WordPress update will not fix this
Wordfence says WordPress updates will not apply this fix. The following is general background, not something taken from the notice: WordPress, WooCommerce and other PHP applications run on top of the PHP interpreter installed on the host, so updating the application changes only its own code. The interpreter is normally updated through your hosting control panel, your operating system's package manager or your container image. On shared hosting that is usually a setting or a request to your provider. On a VPS or dedicated server it is your responsibility.
Who is affected
The research does not list affected version ranges, so the points below are general guidance based on the fixed versions Wordfence named, not confirmed exposure criteria.
- Sites running PHP on the 8.5, 8.4, 8.3 or 8.2 branch at a patch level below the fixed release for that branch are the most likely to need the update.
- Sites on other branches: the research does not say whether older or unsupported branches are affected or will receive a fix. If you run an end-of-life branch, plan a move to a supported one.
- Managed hosting customers, where the provider may update PHP for you. Confirm this rather than assume it.
- Docker and container users, where PHP is typically part of the image and needs a rebuilt image or a newer base image tag.
How to check your PHP version
Start by finding out which version your site actually runs. The checks below are standard, documented ways to do that and are general guidance rather than steps from the Wordfence notice. The command line version can differ from the version your web server uses, so check both when you can.
php -vLook for one of the fixed releases or newer: 8.5.12, 8.4.27, 8.3.36 or 8.2.35. A lower patch number on the same branch means you still need to update.
wp cli infoAs documented for WP-CLI, this output includes the PHP binary and PHP version that WP-CLI uses. Also as general background, the WordPress admin screen under Tools, then Site Health, then the Info tab, normally shows the PHP version the web server is using.
What to do now
0 of 7 done
On Debian, Ubuntu and RHEL-family servers, PHP packages usually come from your distribution or a third-party repository. As general background, distribution maintainers sometimes backport fixes without changing the upstream version number, so a package version that looks old may or may not be vulnerable. Confirm the exact fixed package version in your distribution's or repository's security notice instead of relying on the upstream number alone.
sudo apt update
apt list --installed 2>/dev/null | grep -i '^php'rpm -qa | grep -i '^php'Monitoring after you update
The research does not confirm the technical details or exploitation status, so treat this as a patch-promptly situation. The points below are general hygiene after any server update, not signs of a specific attack:
- Confirm the site loads normally and that PHP error logs show no new errors caused by the update, such as plugin or theme incompatibilities.
- Keep a list of PHP versions across your sites so the next release does not require a search. A WordPress security checklist can help you build that routine.
- If you ever suspect a compromise, the guide on how to check if a website is hacked walks through the checks.
An outside-in scan looks at a site from the internet and cannot reliably tell you which PHP patch level runs on the server, so confirm the version on the server itself. For ongoing checks of your public site, Webforta Scan offers read-only scans of sites you verify.
What we do not know yet
- The names or CVE identifiers of the two vulnerabilities.
- Their CVSS scores and the type of weakness involved.
- Whether either is exploited in the wild.
- Which versions on each branch are affected.
We treat these as unknown until the PHP project or other sources confirm them. The Wordfence notice is the only source we have reviewed, and it says a separate Wordfence advisory contains further details.
Sources
This article is based on the public sources below. Details can change as vendors and researchers publish more; check the original advisories before acting on version numbers.