Will a PHP security update break my WordPress site? Patch releases vs upgrades
Short answer
A security patch stays in the same PHP series: 8.3.35 to 8.3.36, as in October 2026’s PHP2Shell release. PHP’s release rules allow only bug fixes there and require backward compatibility, so your plugins see the same PHP: no compatibility check is needed, just the update. An upgrade changes the series: 8.1 to 8.3. That’s where functions are removed and behaviours change, and where a plugin can break: check first. A host could do both at once, for example moving an unsupported version up while patching, so look at the version before and after.
Read the three numbers
A PHP version like 8.3.36 has three parts: 8 major, 3 minor, 36 patch. The first two together are the series; your plugins’ compatibility depends on the series.
| Change | Example | What it brings | Check plugins first? |
|---|---|---|---|
| Patch | 8.3.35 → 8.3.36 | Bug fixes only, backward compatible | No |
| Minor | 8.3 → 8.4 | New features, deprecations, and changes that can stop old code (8.4 removed five MySQLi constants) | Yes |
| Major | 7.4 → 8.0 | Removed functions, stricter types | Yes, carefully |
What PHP’s rules say
From PHP’s release process, for a patch, x.y.z to x.y.z+1: “Bugfixes only (with a room for exceptions on a case by case basis and only for small self contained features additions).” and “Backward compatibility must be kept (internals and userland)”. For a major version: “Backward compatibility can be broken” (PHP RFC: Release Process).
And php.net describes supported branches this way: “bugs and security issues that have been reported are fixed and are released in regular point releases.” (php.net)
Where October 2026 fits
The PHP2Shell fixes came as patches: 8.2.35, 8.3.36, 8.4.27 and 8.5.12 (php.net). For sites on those series, it’s a patch: update, confirm, done (how to confirm).
For sites on 8.1 or older, there is no patch to install. Getting the fix means changing series, an upgrade, with a compatibility check first: how to upgrade safely.
When to check first
Before any change of series, check every plugin and your theme for the target version. CompatNav, free on wordpress.org, reports only what changes between the series your site runs and the one you choose:
That finding concerns the 7.4 to 8.0 upgrade; no patch release within 7.4 or 8.0 would have caused it. Why patches still matter even when nothing breaks: PHP2Shell.
Key takeaways
- Patch: same series, third number changes (8.3.35 → 8.3.36). Bug fixes only, backward compatible.
- Upgrade: the series changes (8.1 → 8.3). Removals and changes; plugins can break.
- The October 2026 security fixes are patches: 8.2.35, 8.3.36, 8.4.27, 8.5.12.
- Sites on 8.1 or older can’t get them as a patch: for them it’s an upgrade.
- Check plugins before an upgrade; after a patch, just confirm the new number.
Frequently asked questions
Has a PHP patch release ever broken a site?
Patch releases fix bugs, and a bug fix can change a result that some code relied on, so it’s not impossible. It’s rare enough that PHP’s own advice for these releases is to update immediately. Keep a backup, as for any change.
My host updated PHP and something broke. Was it the patch?
Compare the version before and after in Site Health. If the series changed too (say 8.1 to 8.3), the upgrade is the likely cause.
Do I need to run CompatNav after a patch?
No: CompatNav checks what changes between PHP versions, and a patch doesn’t change the version it checks against. Run it before an upgrade.
Check your own site before you upgrade
CompatNav is a free WordPress plugin. It reads the code of your plugins and themes on your own server and tells you, in plain words, what will break and what will only show notices on the PHP version you choose. It never changes your code. It can’t see problems that only appear while code runs with real data, so a quick check of your site after the upgrade still matters.
Sources
About the code examples: each output is the real output of the code shown, run with the official PHP builds, without a php.ini, with all errors reported and displayed. Only the file path was replaced by a neutral server path.