PHP2Shell WordPress Fix: Check and Patch PHP Now

Direct answer: If your WordPress site runs PHP, verify the server version now. The fixed releases are PHP 8.5.12, 8.4.27, 8.3.36, and 8.2.35. Older patch releases are vulnerable to two critical flaws that can allow an unauthenticated attacker to execute code under the right conditions.[2]

Five-minute WordPress action checklist

1. Find the PHP version: In WordPress, open Tools → Site Health → Info → Server, then expand the Server section and note the PHP version.[1]
2. Compare it with the fixed version: PHP 8.5 must be 8.5.12 or newer; 8.4 must be 8.4.27 or newer; 8.3 must be 8.3.36 or newer; 8.2 must be 8.2.35 or newer.[2]
3. Create a fresh backup: Back up both files and the database before changing the runtime.
4. Patch through your host: Use the hosting control panel’s PHP selector or ask support to confirm that your account is running a fixed build. A host saying “we patched our platform” is useful, but ask for the exact PHP version attached to your site.
5. Test after the switch: Check the homepage, login, forms, checkout, search, scheduled tasks, and one uncached page. Purge application and CDN caches only after the site works.
6. Review security signals: Check recent administrator accounts, modified files, security-plugin alerts, web-server logs, and unexpected PHP worker activity. Patching closes the vulnerability; it does not prove that an earlier vulnerable server was untouched.

Patched PHP versions

Your PHP branch	Minimum fixed release	What to do
PHP 8.5	8.5.12	Update to 8.5.12 or a later vendor build
PHP 8.4	8.4.27	Update to 8.4.27 or later
PHP 8.3	8.3.36	Update to 8.3.36 or later
PHP 8.2	8.2.35	Patch now, then plan a newer branch because PHP 8.2 security support ends on December 31, 2026
PHP 8.1 or older	No current upstream supported release	Move to a supported branch or obtain an explicit vendor-maintained security backport

What PHP2Shell means for WordPress

“PHP2Shell” is the informal name used for CVE-2026-109618 and CVE-2026-109619. The first issue involves out-of-memory corruption; the second involves stale global state and use-after-free behavior. The PHP Foundation says both can lead to remote code execution under the right conditions, including demonstrated paths involving Apache with mod_php and PHP-FPM.[2]

This is a PHP runtime problem, not a WordPress core vulnerability. WordPress.org says no WordPress update is required or planned specifically for these issues; the required action is updating PHP on the server.[1] Updating WordPress plugins alone will not replace a vulnerable PHP runtime.

How to check without WordPress admin access

If you manage the server, check the command-line version:

php -v

That result may not match the PHP version serving the website. PHP CLI and PHP-FPM can use different packages or sockets. Check the active FPM services and installed packages as appropriate for your distribution:

systemctl list-units --type=service 'php*-fpm.service'
php-fpm -v 2>/dev/null || true
php -r 'echo PHP_VERSION, PHP_EOL;'

For Docker or Kubernetes, check the PHP version inside every running application container. Updating the host package does not alter an old PHP binary baked into an image. Rebuild from a patched base image, redeploy, and verify the new container rather than relying only on the image tag.

Safe patch sequence for a production WordPress site

1. Inventory before changing anything

• Record the current PHP branch and patch release.
• Check whether the site uses Apache mod_php, PHP-FPM, CGI, LiteSpeed, a container, or managed hosting.
• List staging, cron, command-line workers, queue workers, and forgotten subdomains that may use a separate PHP installation.
• Confirm that a restorable database-and-files backup exists.

2. Apply the patch

On managed hosting, use the control panel or open an urgent ticket. Ask: “Which exact PHP build is serving this domain, and is it patched for CVE-2026-109618 and CVE-2026-109619?” Distribution vendors sometimes backport fixes without making the displayed version identical to PHP.net’s release number, so request the vendor security advisory when the number looks older.

On a self-managed server, use your operating system’s supported repositories and normal package manager. Avoid copying commands from an unrelated distribution or replacing production repositories during an emergency. Restart the relevant PHP-FPM or web-server workers after packages are updated so old processes do not continue serving requests.

3. Verify the live runtime

• Re-open Tools → Site Health → Info → Server.
• Confirm the exact fixed or vendor-patched build.
• Test logged-out and logged-in requests.
• Check PHP and web-server error logs for new fatal errors.
• Remove any temporary public phpinfo() file immediately after verification; it exposes sensitive server details.

If you cannot patch immediately

A web application firewall may reduce exposure, but WordPress.org still tells site owners to update PHP as soon as possible.[1] The UK National Cyber Security Centre advises identifying all PHP systems, prioritising internet-facing services, monitoring for malicious activity, applying updates, and considering taking a system offline when immediate remediation is not feasible.[3]

For a business-critical site, a short maintenance window can be safer than leaving a known vulnerable runtime online. Do not attempt public exploit tests against production. Use host confirmation, package advisories, version checks, logs, and an authorised security review.

Copy-paste message for your hosting provider

Please confirm the exact PHP version currently serving my domain and whether your build contains fixes for CVE-2026-109618 and CVE-2026-109619. PHP.net’s fixed upstream releases are 8.5.12, 8.4.27, 8.3.36, and 8.2.35. If you use a vendor backport, please share the relevant package version or security advisory. Also confirm whether PHP workers were restarted after patching.

Frequently asked questions

Do I only need to update WordPress?

No. WordPress.org states that these vulnerabilities are in PHP, not WordPress, and that no WordPress update is required specifically for them.[1] Keep WordPress current, but patch the server’s PHP runtime separately.

Is PHP 8.2.35 safe for this issue?

PHP 8.2.35 is the fixed release for the PHP 8.2 branch.[2] However, PHP 8.2 security support ends on December 31, 2026, so plan a tested move to a newer supported branch.[4]

Does Cloudflare or another WAF fully fix it?

No. A WAF can be a temporary risk-reduction layer, but it does not replace the vulnerable PHP runtime. The primary action from PHP and WordPress is to install a fixed PHP build.

How do I know whether my host backported the fix?

Ask for the exact operating-system package version and the vendor’s security advisory. Managed hosts and Linux distributions can patch source code while retaining a branch-specific package label, so the upstream version comparison alone may be inconclusive.

Sources

1. [1] WordPress.org: Critical PHP Security Release
2. [2] The PHP Foundation: Today’s PHP Security Release
3. [3] UK NCSC: Critical Security Issue Affecting PHP
4. [4] PHP.net: Supported Versions