PHP Site AuditWordPress
WordPress Site Health: what its PHP version can and cannot tell you
WordPress Site Health can show information about the server and PHP environment used by that WordPress installation. Updating WordPress core does not install a PHP runtime security fix. After a hosting-level change, use Site Health as one confirmation signal and ask the host which patched runtime is serving the site.
Where to look
In the WordPress dashboard, open Tools, then Site Health, then Info. WordPress documentation says the Server section reports aspects of the server setup and PHP variables, while the Status tab reports configuration issues and recommended improvements. This view can help a site owner identify which PHP setup WordPress is seeing.
Access to the panel may be limited, and shared hosts can route separate domains or directories to different PHP versions. For a multisite or multi-domain account, confirm each production site that matters rather than assuming one panel reading covers every host.
Keep application and runtime updates distinct
WordPress core, themes, and plugins are application files. PHP is the server runtime that executes PHP applications. Installing a WordPress update does not replace the PHP binary or vendor package beneath it. Likewise, changing the PHP selector in a hosting account does not update an old plugin or WordPress core.
For PHP2Shell, compare the actual serving runtime with PHP's release guidance and the host's package advisory. A dashboard display of 8.3.35, for example, is worth asking about against the upstream fixed release; it does not settle the matter if the host uses a backported build. Request the vendor's package evidence and consult the related fixed-version guide.
After the PHP change
Ask the provider to confirm which runtime is assigned to the domain and when it took effect. Revisit Site Health, review the site's public pages and admin area, and test important workflows such as forms or checkout. If Site Health still reports the old runtime, share the domain and a timestamp with the host. Do not create a public phpinfo() file to investigate; it can disclose sensitive configuration details.
WordPress can show information from the request that loaded its dashboard, which is useful for identifying a mismatch. Pair that clue with the hosting account's package advisory and the domain-to-pool mapping; do not publish a screenshot containing paths, usernames or other server details.
Common questions
Does WordPress Site Health prove the exact PHP package?
It reports information available to that WordPress request, but is not vendor-package attestation and may not cover other pools or hosts.
Can updating WordPress fix PHP2Shell?
No. WordPress updates do not install a fix in the PHP engine; coordinate the runtime update with the host.
Should a diagnostic page stay public?
No. Remove temporary diagnostics because they can disclose configuration without proving every serving package is fixed.