PHP2Shell PHP Vulnerability: What Founders Should Do Today

Last checked: 22 Oct 2026. By Reza Pratama, Serpair — assisted by Serpy. Not legal or security advice. For your own setup, follow the official PHP advisory and your hosting provider.

On 21 October 2026, PHP shipped emergency fixes for two critical flaws in PHP itself, CVE-2026-109618 and CVE-2026-109619, known together as PHP2Shell (php.net). Wiz says frontier AI models helped its researchers find the bugs and turn them into working exploits (Wiz). The same day, Amazon said “PHP2Shell is now being broadly exploited in the wild” (AWS Security Blog).

PHP sits under WordPress, Drupal, Joomla, Magento and many hosting panels. So this PHP vulnerability reaches a lot of founder websites, including ones whose owners have never thought about PHP.

Here’s a question most founders haven’t asked: does your SEO tool check your PHP version? Search Console won’t warn you in advance. 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). In other words, it tells you after you’re hacked.

This is the plain-language version: what PHP2Shell is, how to check your PHP version, what to do today, and why it matters for your SEO, GEO, AEO and AI visibility.

What is PHP2Shell (CVE-2026-109618 and CVE-2026-109619)?

PHP2Shell is the name for two vulnerabilities in the PHP engine, published by the PHP project on 21 Oct 2026:

• 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. That means an attacker who sends crafted web requests may be able to run code on the server without logging in. Both are rated CVSS v4.0 9.2, which is critical (CVE-2026-109618 record, CVE-2026-109619 record). The PHP project says the risk is highest for Apache with mod_php, “with a demonstrated exploit where an unauthenticated request can trigger the attack before any application code runs” (php.net).

Because the flaws are in PHP itself, updating your theme or plugins does not fix them. As Cloudflare puts it, administrators “need to update the PHP software running their applications” (Cloudflare).

Cloudflare credits Calif.io, Wiz, OpenAI and Quarkslab with the disclosure. Wiz says the vulnerable code “had been present for more than a decade”, and that AI changed “the ability to understand the weaknesses and turn them into a working exploit” (Wiz). That’s the uncomfortable part for small teams: AI makes attackers faster too.

Which PHP versions fix the PHP2Shell vulnerability?

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 (php.net). Wiz says every PHP version released in the last decade, back to 5.4, is affected by at least one of the bugs (Wiz).

The fixed releases are:

PHP branch	Fixed version
8.5	8.5.12
8.4	8.4.27
8.3	8.3.36
8.2	8.2.35

Source: the PHP security advisory and the official CVE records, which list every 8.2, 8.3, 8.4 and 8.5 release below these numbers as affected.

There is no official PHP2Shell release below 8.2; patch via a vendor backport or upgrade. PHP 8.1 and older no longer get updates from the PHP project. Given the severity, the PHP security team also published minimal source backports for PHP 7.4, 8.0 and 8.1, for people who build PHP from source or have no long-term support vendor (php.net). Some Linux distributions and support vendors ship their own patched packages, and a backported fix may keep an older version number, so check your vendor’s advisory rather than the number alone (Qualys).

Is PHP2Shell being exploited?

Yes, according to Amazon. Amazon Threat Intelligence saw a PHP2Shell exploit attempt dating to 17 Oct 2026, four days before public disclosure. After the patch, it said “PHP2Shell is now being broadly exploited in the wild” (AWS Security Blog). Cloudflare reported attack traffic and attackers changing payloads to try to get past its rules (Cloudflare).

For balance: CISA’s alert on 21 Oct said “CISA has not observed exploitation of these vulnerabilities as of the time of publication” (CISA). Both statements are dated 21 Oct. AWS’s is the more recent picture.

How do I check my PHP version?

Only check sites you own or manage. Three ways, easiest first:

1. Ask your host or open the hosting dashboard. Most control panels show the PHP version per site. Ask your host in writing whether they have installed the PHP2Shell fix.
2. WordPress: go to Tools > Site Health > Info > Server. It shows the PHP version your site runs on.
3. Look at your own site’s response headers. Some servers send an X-Powered-By: PHP/8.x.y header. Many hosts hide it, and a missing header proves nothing either way.

Then compare with the fixed list above. If you’re on a fixed release, or your vendor confirms a backported fix, you’re patched for PHP2Shell. If you’re on 8.1 or older, read the section below.

One more catch from Qualys: the version that php -v shows on the command line “may belong to a different installation from the one serving web requests” (Qualys). Check the version your website actually runs.

Avoid leaving a phpinfo() page online to check. It shows your server details to anyone.

Is my WordPress site affected by this PHP vulnerability?

If your WordPress site runs on an unpatched PHP version, it is in scope, because the flaw is in PHP, not in WordPress. Wiz says it demonstrated remote code execution without authentication on standard WordPress, Drupal and Joomla installs, using their latest container images (Wiz). Updating WordPress core and plugins is still good practice, but it doesn’t fix PHP2Shell. The PHP runtime itself has to be updated, usually by your host.

If you use a fully hosted builder (for example Webflow, Shopify or Wix), the platform runs the servers. Ask the vendor rather than assuming either way.

What if I’m on PHP 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 (php.net EOL list). 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” (CISA).

In practice: ask your host today for a patched build or a move to a supported branch. Also note that PHP 8.2 security support ends on 31 Dec 2026, while 8.3 is supported until 31 Dec 2027 (php.net supported versions). If you’re upgrading anyway, aim for 8.3 or newer.

What should I do today? The 5-step PHP2Shell checklist

1. Find every PHP site you own. Main site, blog, landing pages, old microsites, staging. PHP also ships inside other products, and CISA notes that “PHP is often a component of other software” (CISA). NCSC-NL keeps a list of third-party products that bundle PHP (NCSC-NL on GitHub).
2. Check the PHP version of each one (see above).
3. Update, or get your host to confirm in writing. Move to 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or have your host confirm a patched build. Managed hosts may already have done it.
4. Keep a firewall on while you patch. Cloudflare says its PHP2Shell protections are “deployed automatically on all plans with WAF deployed, including Free users”, and still tells customers to patch (Cloudflare). The PHP project says its temporary mitigations reduce some attack paths but “do not make an installation safe” (php.net).
5. Watch for signs of trouble. Amazon says to start investigations from 17 Oct, not from the disclosure date (AWS). 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).

Does Google rank sites lower for running an old PHP version?

Not directly, as far as Google documents. No Google page lists your software version as a ranking signal. Google’s John Mueller has said Google’s systems “don’t focus on how the page was created. Instead, they focus on the final result” (Search Engine Journal, quoting Mueller).

The problem is what an old version lets in. Google’s own help page names it as a way attackers get in: “By exploiting a vulnerability in software running on your site, such as a content management system. For example, you might be running an older, insecure version of Drupal, Joomla! or WordPress” (Search Console Help).

Can a hacked site lose Google rankings and AI visibility?

It can. A hacked site can get a “This site may be hacked” label, drop out of results and out of AI Overviews:

• The label. Google shows “This site may be hacked” when it believes “a hacker might have changed some of the existing pages on the site or added new spam pages” (Google Search Help).
• Out of results. “Google tries its best to keep hacked content out of our search results”, and hacked content breaks Google’s spam policies: “Sites that violate our policies may rank lower in results or not appear in results at all” (Search Console Help, Google spam policies).
• Out of AI Overviews. To be a supporting link in AI Overviews or AI Mode, “a page must be indexed and eligible to be shown in Google Search with a snippet” (Google Search Central). A page that drops out of Search loses that eligibility too.
• Slow way back. You clean the whole site, close the hole and request a review. Google says “A review can take from a few days to a few weeks to complete” (Search Console Help). Mueller has said “it certainly can take a few months for things to really settle back down, depending on how & how long the site was hacked” (Search Engine Journal).

So patching PHP is now part of protecting your SEO, GEO, AEO and AI visibility. Checking your PHP version takes a few minutes. Cleaning up a hack can take months.

Is there a free PHP vulnerability scanner?

Some security vendors offer scanners, and your host can confirm your PHP version and patch status. For most founders, the checklist above is the fastest safe route: find, check, update, firewall, watch. Don’t wait for Search Console to tell you. By then the site has already been hacked.

We built a PHP2Shell checker into Serpair

Because so many founders asked “which of my sites is affected?”, we added a free PHP2Shell check to Serpair. It does two separate things, and it’s important to be clear about what each one means.

1. A passive version check (free, no setup). We read the PHP version your server already advertises publicly and compare it against the official fixed releases (php.net advisory). If your version is affected, you get a plain-language result and the exact fix. This is version-based detection — the same method CISA, Qualys and Nessus use for this CVE. It tells you your PHP version is one PHP2Shell affects; it does not attempt the exploit and does not claim your server is provably exploitable. If your server hides its version, we say so rather than pretending you’re safe.

2. A deeper scan for exposed files (verified owners only). Beyond the version check, Serpair can actively look for genuinely confirmed problems — a public phpinfo() page, a downloadable .env, an exposed .git folder, a wp-config.php backup. These are verified exposures: we fetch the path and confirm the sensitive content is actually served. Every finding comes with a concrete fix.

Because the deep scan actively probes your site, we only run it after you prove you own the domain — you add a DNS TXT record we generate, and we confirm it before any active check runs. We will never run intrusive checks against a site without a verified, consenting owner behind it.

What Serpair deliberately does not do: it doesn’t exploit PHP2Shell, doesn’t run the use-after-free, and never claims to have “hacked” or “confirmed RCE” on your server. Patching the PHP runtime is still the only real fix — the checker just tells you, honestly, whether you need to.

Run the free PHP2Shell check on your site →

And since a hacked site can drop out of Google results and AI Overviews, keeping PHP patched protects your SEO and AI visibility too. If you also want to see where your site stands on SEO and GEO today, you can run a free SEO and GEO analysis.

FAQ

What is PHP2Shell? PHP2Shell is the name for two critical vulnerabilities in the PHP engine, CVE-2026-109618 and CVE-2026-109619, fixed on 21 Oct 2026. Both can allow unauthenticated remote code execution on servers running unpatched PHP.

What is the PHP2Shell CVE number? There are two: CVE-2026-109618 (out-of-memory corruption) and CVE-2026-109619 (stale global state). Both are rated CVSS v4.0 9.2.

Which PHP version fixes PHP2Shell? PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. There is no official PHP2Shell release below 8.2; patch via a vendor backport or upgrade.

How do I check the PHP version of my website? Check your hosting dashboard, ask your host, or in WordPress open Tools > Site Health > Info > Server. Some servers also show it in an X-Powered-By response header, but many hide it.

Is PHP 8.1 end of life? Yes. PHP 8.1 reached end of life on 31 Dec 2025. PHP 8.2 security support ends on 31 Dec 2026.

Does updating WordPress fix PHP2Shell? No. The flaws are in PHP itself, so the PHP runtime has to be updated, usually by your host.

Does Google penalize sites running an old PHP version? Google doesn’t document a ranking penalty for a software version. But Google’s help page on security issues names an older, insecure CMS version as a way hackers get in, and a hacked site can be labelled or removed from results.

Can a hacked website lose Google rankings and AI visibility? It can. A hacked site can get a “This site may be hacked” label, drop out of results and out of AI Overviews, since AI Overview links must be eligible to be shown in Google Search. A Search Console review after cleanup can take from a few days to a few weeks.

Does Search Console warn me about an outdated PHP version? No. The Security issues report shows findings once Google determines a site was hacked or could harm visitors, so it tells you after the fact. Check your PHP version yourself or with your host.

Over to you

Did PHP2Shell reach you? Did your host patch for you, or did you have to do it yourself? Do you know which PHP version your site runs? Tell us what you found and what you changed in the comments or on Indie Hackers, and we’ll add the best tips to this checklist.