PHP2Shell: is your WordPress site exposed?

The check reads the PHP version a server advertises in its public headers. Linux distributions and CloudLinux often backport security fixes without changing that number, so an old version string is a reason to look closer and proves nothing on its own. The upgrade removes the doubt: a supported PHP branch with the fix, confirmed on the server.

A WordPress update does not change PHP. The host or the server administrator installs PHP, so PHP2Shell is fixed on the server: a patched PHP build from the host, or an upgrade to a supported branch.

Only what any browser receives: response headers, the page source and the version tags on public plugin files. No login, no form submissions, no exploit attempts. Each report shows the date and time of its check.

Most shared hosts have a PHP version switch in cPanel, Plesk or their own panel. The switch is one click; the work is what breaks after it: old plugins, theme code, missing PHP extensions. The switch happens on a staging copy first, and the live site moves only after the fixes.

Hosting panel or SSH access and a WordPress administrator account; DNS access only where the host requires it. Credentials travel through a one-time secure link and are deleted when the job closes.

A full backup is taken before anything changes. If the upgrade breaks the site and the fix is not possible, the site returns to that backup and the fee is refunded. The terms of the PHP upgrade service set out the details.

Store data stays on the client's server, and the staging copy lives with the same host where possible. When the work touches customer personal data, a data processing agreement is signed before any access is granted.

PHP 8.2 receives security fixes from php.net until 31 December 2026. After that date new flaws in 8.2 stay unfixed upstream, which is why the upgrade targets 8.3 or 8.4 and not the latest 8.2 build.