PHP2Shell (CVE-2026-109618, CVE-2026-109619): how to check and patch your PHP version

On 21 Oct 2026 the PHP project shipped fixes for two critical vulnerabilities in the PHP engine, known together as PHP2Shell (php.net):

• CVE-2026-109618, remote code execution via out-of-memory corruption.
• CVE-2026-109619, remote code execution via stale global state.

Both can allow unauthenticated remote code execution and both are rated CVSS v4.0 9.2 (CVE-2026-109618, CVE-2026-109619). The flaws are in PHP itself, so updating your framework, theme or plugins does not fix them. As Cloudflare puts it, administrators "need to update the PHP software running their applications" (Cloudflare).

What's in scope

The PHP project says "all PHP installations serving web requests" are at risk, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. Wiz says every PHP version released in the last decade, back to 5.4, is affected by at least one of the bugs (Wiz). Wiz also says frontier AI models helped its researchers find the bugs and turn them into working exploits.

Fixed versions

There is no official PHP2Shell release below 8.2; patch via a vendor backport or upgrade. The PHP security team published minimal source backports for 7.4, 8.0 and 8.1 for people who build from source or have no long-term support vendor.

Check the runtime that actually serves requests

1. Hosting dashboard or your host. Most panels show the PHP version per site. Ask your host in writing whether the PHP2Shell fix is installed.
2. WordPress: Tools > Site Health > Info > Server.
3. Your own site's response headers. Some servers send X-Powered-By: PHP/8.x.y. Many hide it, and a missing header proves nothing either way.

Two catches from Qualys. First, the version that php -v shows on the command line "may belong to a different installation from the one serving web requests". Second, distributions and support vendors that ship their own patched packages may keep an older version number, so check your vendor's advisory rather than the number alone (Qualys).

Don't leave a phpinfo() page online to check. It shows your server details to anyone.

Mitigations are not a fix

The PHP project says its temporary mitigations reduce some attack paths but "do not make an installation safe". Cloudflare says its PHP2Shell protections are "deployed automatically on all plans with WAF deployed, including Free users", and still tells customers to patch. A WAF buys time while you update. It doesn't replace the update.

Exploitation status

Amazon Threat Intelligence saw a PHP2Shell exploit attempt dating to 17 Oct 2026, four days before disclosure, and after the patch said "PHP2Shell is now being broadly exploited in the wild" (AWS Security Blog). CISA's alert the same day said "CISA has not observed exploitation of these vulnerabilities as of the time of publication" (CISA). The AWS statement is the more recent picture. AWS also says to start investigations from 17 Oct.

On 8.1 or older

PHP 8.1 reached end of life on 31 Dec 2025, PHP 8.0 on 26 Nov 2023 and PHP 7.4 on 28 Nov 2022. CISA says organizations that cannot update immediately, or that continue to use 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, and 8.3 is supported until 31 Dec 2027, so aim for 8.3 or newer if you're upgrading anyway.

The 5 steps

1. Find every PHP app and site you run, including staging and anything that bundles PHP (NCSC-NL keeps a list of such products).
2. Check the version of the runtime serving requests, not only the CLI.
3. Update to 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or get your host or vendor to confirm a patched build in writing.
4. Firewall on while you patch.
5. Watch. Review from 17 Oct, check Search Console's Security issues report, and rotate passwords, tokens and API keys if anything looks off. Wiz showed the flaws can leak "passwords, tokens, and API keys" from server memory.

The SEO part devs tend to skip

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". Google's hacked site guide names "an older, insecure version of Drupal, Joomla! or WordPress" as a way in, and a hacked site can get a "This site may be hacked" label, drop out of results and out of AI Overviews.

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 and only reads the publicly advertised version, so it sends no attack traffic. "Version hidden / not exposed" is a possible result, and hidden doesn't mean patched. A passive check isn't a full security audit. You get a partial report by work email, then register on Serpair for the full report. Free, no credit card required. Sources and the check are in the original post: PHP2Shell vulnerability: check if your site is affected

How did patching go on your stack? Did your distro or host ship a backport, and did php -v match what your web server was actually running?