PHP2Shell vulnerability explained: 5 steps from the official advisories

Two PHP flaws, CVE-2026-109618 and CVE-2026-109619, were fixed on 21 Oct 2026. Together they're called PHP2Shell. Both can allow unauthenticated remote code execution, and both are rated CVSS v4.0 9.2 (php.net). The fixed releases are 8.5.12, 8.4.27, 8.3.36 and 8.2.35.

There's a lot of noise about this PHP vulnerability. So here are the 5 steps, each one backed by what an official advisory or vendor actually says.

1. Find every PHP site you own

The source: CISA notes that "PHP is often a component of other software" (CISA). The PHP project says "all PHP installations serving web requests" are at risk (php.net).

What it means: your main site isn't the whole list. Count the blog, landing pages, old microsites, staging, and anything that ships PHP inside it. NCSC-NL keeps a list of third-party products that bundle PHP (NCSC-NL on GitHub). PHP also sits under WordPress, Drupal, Joomla and Magento.

2. Check the PHP version

The source: Qualys warns that the version php -v shows on the command line "may belong to a different installation from the one serving web requests" (Qualys).

What it means: check the version your website actually runs. Your hosting dashboard usually shows it. In WordPress, go to Tools > Site Health > Info > Server. Some servers send an X-Powered-By header, but many hide it, and a missing header proves nothing either way.

3. Update, or get your host to confirm in writing

The source: Cloudflare says administrators "need to update the PHP software running their applications" (Cloudflare).

What it means: move to 8.5.12, 8.4.27, 8.3.36 or 8.2.35. There is no official PHP2Shell release below 8.2; patch via a vendor backport or upgrade. A backported package may keep an older version number, so check your vendor's advisory rather than the number alone. PHP 8.1 reached end of life on 31 Dec 2025, and CISA says those who can't update, or still run PHP 8.1 or earlier, "should take PHP-based systems offline until they can be patched or updated". PHP 8.2 security support ends on 31 Dec 2026, so aim for 8.3 or newer when you upgrade.

4. Keep a firewall on while you patch

The source: Cloudflare says its PHP2Shell protections are "deployed automatically on all plans with WAF deployed, including Free users", and still tells customers to patch. The PHP project says its temporary mitigations reduce some attack paths but "do not make an installation safe" (php.net).

What it means: a firewall buys you time. It doesn't replace the update.

5. Watch for signs of trouble

The source: Amazon said "PHP2Shell is now being broadly exploited in the wild", and says to start investigations from 17 Oct, not from the disclosure date (AWS Security Blog). For balance, CISA's alert on 21 Oct said it had not observed exploitation at the time of publication. The AWS statement is the more recent picture.

What it means: turn on Google Search Console, check its Security issues report, and rotate passwords and API keys if anything looks off. Wiz showed the flaws can leak "passwords, tokens, and API keys" from server memory (Wiz).

Why this is also an SEO problem

Does your SEO tool check your PHP version? Search Console only tells you after you're hacked. Its Security issues report shows findings once Google determines a site "was hacked, or that it exhibits behavior that could potentially harm a visitor or their computer" (Search Console Help). The same help page names "an older, insecure version of Drupal, Joomla! or WordPress" as a way attackers get in.

A hacked site can get a "This site may be hacked" label, drop out of results and out of AI Overviews. Google says a supporting link in AI Overviews "must be indexed and eligible to be shown in Google Search with a snippet" (Google Search Central). After cleanup, "A review can take from a few days to a few weeks to complete".

A quick first look

I work at Serpair. Our free check checks whether your site advertises a PHP/CMS version affected by PHP2Shell and known CVEs. It's passive: it reads the publicly advertised version and sends no attack traffic. One possible result is "version hidden / not exposed", and hidden doesn't mean patched, so confirm with your host. A passive check isn't a full security audit. Enter your site and work email for a partial report by email, then register on Serpair for the full report. Free, no credit card required.

All sources and the check are in the founder checklist for PHP2Shell.

Which of the 5 steps took you longest? Did your host patch before you asked, or did you have to chase them?