WordPress does not patch PHP. Your host does.
Updating WordPress core, themes and plugins does not change the PHP binary. The runtime is set by the host or the server image, and the site's own health report is the quickest way to see which version answered the last request.
Short answer
Open Tools → Site Health → Info → Server and record the PHP version. It reflects a web request, not the CLI.
Confirm the assigned version in the host panel or server configuration. A selector can be set per domain or directory.
Ask the host to patch the runtime, or switch to a supported branch with the fixed patch level. Then test the site, not just the version number.
01Does this apply to you?
Applies when
- You run WordPress on hosting where someone else controls the PHP runtime.
- You have a PHP version selector in a control panel or a container image you maintain.
- You need to decide whether the site is safe to keep serving after a PHP update.
Does not cover
- It does not claim that a WordPress core, theme or plugin update fixes these CVEs.
- It does not cover PHP application code outside WordPress.
- It does not replace the host's evidence for a runtime you do not control.
What you need before starting
- An administrator account for the WordPress site.
- Access to the hosting control panel or the server image configuration.
- A staging copy for plugin and theme regression, where possible.
- A list of the site's critical journeys: login, publishing, media, forms, shop checkout, email.
02Steps
Establish the web runtime first. Then make the change in a controlled way and test the parts of WordPress that actually earn or serve.
- Site administrator
Read the web PHP version from WordPress
Go to Tools → Site Health → Info → Server. The PHP version shown there came from a web request handled by the site, which makes it better evidence than a CLI command.
Record the version, the date and the site URL. If the site is behind a page cache, clear the cache or use an uncached admin page so the report is current.
Repeat for each site on the account. A multisite installation shares a runtime but can have per-site domains and caches.
You should see A recorded web PHP version for each site, with the date and the page path used.If it fails If Site Health is unavailable, use the host panel and a temporary access-controlled diagnostic. Do not stop at a CLI version. - Site owner
Confirm which runtime the host assigns to the domain
Find the PHP version selector in the hosting panel, or the FPM pool or container configuration on a server you manage. Confirm the assignment for the exact domain, including www and any staging subdomain.
The panel may show an available version rather than the active one. Look for the assigned version, not the dropdown's default.
If the host controls PHP, this is also the moment to send the hosting enquiry. Ask for the exact patch level, not only the branch.
You should see The assigned runtime is identified for every domain, and any mismatch with Site Health is explained.If it fails If the panel and Site Health disagree, do not guess. Record both and ask the host which one applies to the web request. - Host or platform engineer
Get the runtime patched or moved to a patched branch
If the host patches PHP, ask for the date and the worker restart confirmation. A package installation without a worker restart does not change the runtime that answers requests.
If you control the selector, choose a supported branch with the fixed patch level: 8.2.35, 8.3.36, 8.4.27 or 8.5.12. Moving from 8.2 to 8.3 is a compatibility change; treat it as one.
If you run WordPress in a container, the PHP version comes from the image. Rebuild and replace the container; changing a plugin does not change the runtime.
You should see The assigned web runtime is a fixed version on a supported branch, and the worker restart is confirmed.If it fails If the host cannot patch, use the interim settings available and record the residual risk. Do not describe a WAF as a fix. - Site administrator
Stage the change and test plugins and themes
WordPress's own guidance is to test PHP changes in a staging environment first, because plugins and themes are the main compatibility risk. A PHP minor change can expose deprecated calls or extension differences.
Test with all plugins active, not a reduced set. A plugin that is disabled during testing is still part of the production site.
Record the previous PHP version so you can switch back if a critical plugin fails.
You should see A staging result and a rollback version recorded before the production change.If it fails If staging is not available, schedule a short window, take a backup and have the previous version ready. Do not test compatibility for the first time in production traffic. - Site owner
Run the business regression
Check login and password reset, publishing and editing, media upload, forms and email delivery, scheduled posts or cron, search, and the shop checkout if WooCommerce is in use.
Check the admin path separately from the public site. A cached public page can look healthy while the admin area is broken.
Record failures as open test bugs with an owner and a date. Do not count them as completed fixes, and do not treat a zero bug count as proof of security.
You should see Each critical journey has a pass or fail, and every failure has an owner.If it fails If a plugin breaks, decide explicitly whether to roll back PHP, replace the plugin or accept a documented exception. Do not leave a broken checkout behind a green version number. - Site administrator
Recheck and record
After the change, reopen Site Health and confirm the web version again. Clear caches and opcache where you control them.
Record the result in the workbook: the business line, the required and completed fixes, the verification state and any open test bugs.
If the host provided the patch, store the written confirmation with the site record, not only in your inbox.
You should see A current web version, a regression result and a stored host confirmation where applicable.If it fails If the recheck shows the old version, treat the change as not applied and reopen the host ticket or change record.
03What usually goes wrong
Updating WordPress and assuming PHP changed
Core, theme and plugin updates do not replace the PHP binary. Check Site Health and the host panel.
Testing with plugins disabled
The production site runs with its plugin set. A compatibility failure in a disabled plugin will appear when you re-enable it.
Using WP-CLI as web evidence
WP-CLI runs under the CLI binary. It is useful for application checks but does not prove which binary served a web request.
Forgetting per-domain overrides
A host can assign different PHP versions to different domains or directories. Check each site, not only the main domain.
04Questions that change the decision
Do I need to update WordPress core for this?
No, not for these CVEs. These are PHP runtime vulnerabilities. Keep WordPress updated for its own security, but do not record a core update as a PHP2Shell fix.
Site Health says 8.4. Can I stop there?
8.4 is a branch, not a patch level. You need the fixed patch level for that branch, or a verified backport. Ask the host for the exact version and check whether workers were restarted.
What about upload limits on shared hosting?
WordPress documents that shared hosts often set upload and timeout limits at server level. If you cannot change them, ask the host and record the setting as part of the evidence. Do not assume a control panel field changes the effective web value.
05Where to go next
06Sources and revision
Every operational claim on this page was checked against the documents below on 23 October 2026. This page was last substantively changed on 23 October 2026.
| Publisher | Document | Checked |
|---|---|---|
| WordPress Developer Resources | PHP and WordPress: compatibility and updating Published date not stated | 2026-10-23 |
| PHP Group | Security advisory: Critical remote code execution vulnerabilities, update now Published 2026-10-21 | 2026-10-24 |
| PHP Group | Supported Versions Published date not stated | 2026-10-24 |
| PHP Group | Informational advisory: Session upload progress Published 2026-10-23 | 2026-10-23 |
| PHP Group | PHP-FPM configuration directives Published date not stated | 2026-10-23 |
See the full revision log for what changed on this site.