To check a WordPress PHP vulnerability after PHP2Shell, identify the PHP runtime serving your site, ask your host which fix it deployed, and verify the site after that deployment. Updating WordPress alone does not establish that PHP has been patched.
The WordPress security announcement of October 21, 2026 directs site owners to update PHP and explains that these vulnerabilities are not specific to WordPress. This guide focuses on what a WordPress administrator can inspect and what the hosting provider must confirm.
How to check your WordPress PHP version
Use the administration area of the affected website:
- Open Tools → Site Health.
- Select Info, then expand Server.
- Record the PHP version, the website hostname, and the time of the check.
- Compare that information with the PHP configuration assigned to the same domain in your hosting panel.
WordPress documents this route in its PHP security announcement. The Site Health documentation explains its Status and Info tabs.
Check each installation separately. A production domain, staging site, subdomain, and scheduled task can use different PHP installations. If you cannot access administration, use your host’s domain-specific runtime information or contact support.
What the version number can and cannot tell you
The upstream fixes start with PHP 8.2.35, 8.3.36, 8.4.27, and 8.5.12. Later supported patch releases can also contain the fixes. See the PHP release announcement and our PHP2Shell affected-version and patch guide.
A distribution can apply a security fix while retaining an older upstream version number. Ask for the complete package revision or runtime build and the vendor advisory covering both CVE-2026-109618 and CVE-2026-109619. A dashboard label such as “PHP 8.3” identifies a branch, not a particular patch.
Site Health is a useful observation of the WordPress runtime. A displayed version or a general health status does not, by itself, certify the vendor’s backport or every server instance behind the site.
Does updating WordPress fix this PHP vulnerability?
WordPress, plugins, and themes run on PHP. Their updates address application code; the hosting provider or server administrator controls the interpreter. For this incident, WordPress says no WordPress release is required or planned specifically to fix these PHP issues. Continue maintaining the application, and obtain separate confirmation of the PHP fix.
| Action | What it establishes |
|---|---|
| Update WordPress, plugins, and themes | Application components have been updated; PHP status still needs checking |
| Select a PHP branch in a hosting panel | The domain is assigned that branch; the exact deployed build still matters |
| Obtain the vendor’s fixed-build details | There is an identified fix to compare with the installation |
| Verify the running web runtime after deployment | The site is using the expected runtime; confirm all instances with the host |
What to ask your host about PHP2Shell
Ask about the specific website rather than relying on a general announcement. You can adapt this support request:
For example.com, please confirm:
1. The PHP package revision or runtime image currently serving HTTP requests.
2. The vendor advisory confirming fixes for CVE-2026-109618 and CVE-2026-109619.
3. Whether all relevant workers, containers, and server instances were replaced or restarted.
4. Any temporary protections still in use and the remaining patch work.
5. The completion time and how I can verify the deployed runtime.Automattic’s October 21 platform announcement states that sites on WordPress.com, WordPress VIP, WP Cloud, Pressable, and Tumblr were protected. That statement applies to its named platforms. A self-hosted WordPress installation at another provider needs that provider’s confirmation, including whether protection means a runtime fix, temporary filtering, or both.
How to update PHP for WordPress
Follow the procedure for your host and installation. The WordPress PHP update guide covers preparation and coordinating the server change with the hosting provider. Use the current PHP security advisory to choose the fixed build; an old compatibility recommendation is not evidence of an incident-specific fix.
- Prepare a recoverable backup. Include the database and site files, and establish who can restore them. Keep a known-good copy separate from the live installation.
- Check compatibility. Identify the active theme, required plugins, custom code, and PHP extensions. Use a staging copy to test the intended runtime where available.
- Deploy the vendor-confirmed fix. For managed hosting, have the provider apply it to the correct website. If you administer the server, use the package and worker verification procedure.
- Recheck the running site. Reopen Site Health in a fresh administration request. Ask the host to confirm the expected build across every backend instance.
- Test the features your site actually uses. Record the results before treating the update as complete.
If a plugin breaks on the target runtime, investigate it in staging and ask whether a maintained, fixed build exists for the compatible PHP branch. Returning an unpatched installation to public service leaves the original problem unresolved. Use controlled access or another verified containment plan while resolving compatibility.
Verify the fix beyond a successful update message
Use this acceptance record with your host or administrator:
| Evidence | What to record |
|---|---|
| Website and runtime | Hostname, PHP branch, full package revision or image digest |
| Fix coverage | Vendor notice covering both CVEs and that exact build |
| Deployment | Completion time and confirmation that old workers were replaced on all instances |
| Web observation | PHP version seen in WordPress Site Health after deployment |
| Functional checks | Public page, administration login, media upload, and required forms or checkout |
| Background work | Scheduled jobs, queues, and their PHP installation where applicable |
An SSH command such as php -v checks the PHP selected by that shell. It may differ from the PHP process handling WordPress requests. An image pull can also leave an old container running. Those are reasons to verify the serving process, not just a downloaded package.
What if your host cannot patch immediately?
Ask for its containment plan and a patch deadline. Cloudflare’s PHP2Shell protection notice describes WAF protections and still recommends updating PHP. Filtering can reduce exposure; it does not establish that the interpreter is fixed.
Have the administrator assess the legacy PHP mitigation options. If adequate protection cannot be established, WordPress’s incident announcement advises considering taking the affected system offline until it can be mitigated. A maintenance page generated by the vulnerable PHP application is not the same as blocking access before PHP executes.
When the immediate risk is controlled, use our WordPress migration and alternatives decision guide to decide whether changing hosts or platforms would address the maintenance problem.
Reviewed on October 22, 2026 against the linked first-party guidance. These are verification steps for your deployment; this article does not claim that BuzzPHP has tested your WordPress installation or certified a host’s fix.