Is your site exposedto PHP2Shell?

PHP2Shell is the nickname for two critical vulnerabilities in PHP itself, CVE-2026-109618 and CVE-2026-109619, disclosed on October 21, 2026. Under the right conditions they let an attacker run code on a web server without logging in. They are fixed in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35.

If it runs on a PHP version without the fix, yes. The flaws are in PHP, not WordPress, so any WordPress site on an unpatched PHP is exposed, whatever its plugins or theme. Most managed WordPress hosts patched or blocked attacks on October 21; on a self-managed server, whoever runs the server has to update PHP.

No. WordPress, plugin and theme updates don’t change the PHP version your server runs. The WordPress security team says no WordPress update is required or planned. Only a patched PHP fixes it.

PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35, or newer releases in those branches. Linux distributions also ship patched packages that can keep an older version number. PHP 7.4, 8.0 and 8.1 no longer get regular updates; the PHP team published minimal source backports for them, but the lasting fix is upgrading.

Mostly no, but confirm two things: that your plan is covered (some hosts treat VPS and self-managed plans differently) and that staging copies and other sites on the account were updated too. If your site was exposed between October 20 and the patch, check it for signs of compromise, because patching doesn’t remove a backdoor.

It helps, but it’s a stopgap. Cloudflare deployed PHP2Shell rules for all customers, free plans included, and many hosts added firewall rules before patching. A firewall only protects a server attackers can’t reach directly, and the PHP project says only an update is a complete fix.

Ask your host whether it has applied the PHP team’s backport or a vendor fix for your version. Then plan an upgrade to PHP 8.3 or 8.4: PHP 8.2 itself reaches end of life on December 31, 2026. Older plugins and themes sometimes break on the upgrade, so test on a staging copy first.

It loads your homepage once, the way a browser would, and looks up your domain’s public DNS records. From the response it reads what your server chooses to show (the PHP version if advertised, the platform, the host and any firewall in front) and compares that with the fixed releases and your host’s public statement. It sends no attack traffic, and we don’t keep a list of the sites people check. The plain-English summary and the email to your host are written by AI from that result, or from a template if AI is unavailable.

Not from the outside. Most well-run servers hide their PHP version, so an outside check often has to rely on the host’s public statement. Testing for the flaw directly means pushing PHP to run out of memory, which can crash its workers, so we don’t. To be sure, check the version from inside (WordPress Site Health or your hosting panel), or have someone check it for you.

Common signs are admin users you don’t recognize, new or recently changed PHP files (especially in wp-content/uploads), unknown scheduled tasks, unexpected redirects, and bursts of multipart requests followed by memory errors or 500 errors in your server logs. None of these prove it either way. If you see them, patch first, then treat the server as compromised and rotate the passwords and keys it holds.