PHP Vulnerability (PHP2Shell): Which Versions to Update and Is WordPress Affected?

Last updated: November 9, 2026. By Veer. Facts checked against reporting by SecurityWeek and BleepingComputer (October 23), the PHP project’s security advisory and release notes, PHP’s supported versions page and ChangeLog, alerts from CISA, the UK NCSC and ENISA, the WordPress.org announcement, research from Wiz, watchTowr, Amazon Threat Intelligence and Datadog Security Labs, host and vendor notices from Cloudflare, cPanel and Hostinger, and reporting by the BBC. This is a researched explainer, not an exploit write-up.

What is the PHP vulnerability (PHP2Shell)?

PHP2Shell is the nickname for two critical remote code execution (RCE) bugs in the core PHP engine, fixed on October 21, 2026. PHP is the server-side language behind WordPress, Drupal, Joomla, Magento, MediaWiki (Wikipedia) and a huge share of the web. Cloudflare says PHP is used by “almost 70% of websites,” and Wiz calls the findings among “the most severe vulnerabilities discovered in PHP, and arguably in software history.”

Both bugs come from the same root problem: how PHP cleans up memory when a web request fails partway through, especially when it runs out of memory. The PHP project describes them this way:

• CVE-2026-109618, “RCE via OOM corruption”: “out-of-memory handling can interrupt PHP while internal request data is only partially initialized. Request cleanup may then treat the invalid data as valid.”
• CVE-2026-109619, “RCE via stale global state”: “request-owned internal state can survive after its backing memory has been freed. A later request handled by the same worker may use that stale state before normal initialization resets it.”

In plain English, a specially crafted web request can leave PHP’s memory in a broken state, and an attacker can steer that broken state into running their own commands on the server. No username or password is needed. Wiz says the same family of bugs can also leak memory from the PHP process, which “may contain passwords, authentication tokens, API keys and certificates belonging to other requests or the server itself.”

What makes this different from a typical WordPress plugin bug is where it lives. As Wiz puts it, the flaws are “in PHP itself, independent of the application running on top of it.” Wiz says even a simple “Hello World” app on an affected PHP version can be vulnerable, and Datadog Security Labs says its reproduction ran the attacker’s command “while it cleans up the failed request,” before the request ever reached the application’s code.

Sources: PHP security advisory, watchTowr, Wiz.

Which PHP versions are affected, and which are fixed?

Every PHP version before 8.5.12, 8.4.27, 8.3.36 and 8.2.35 should be treated as vulnerable. Wiz says every PHP version released in the last decade is affected by at least one of the bugs, “going back to version 5.4.” The PHP project’s own advisory says the people at risk are “all PHP installations serving web requests, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed,” and that it considers the risk “highest for mod_php.”

Here’s what to install, based on the branch you run:

Sources: PHP security advisory and release notes (October 21, 2026); PHP supported versions (checked October 22, 2026).

A few details from the advisory are worth knowing:

• PHP 8.1 and older “no longer receive updates from the PHP project.” Because the bugs are so severe, PHP’s security team published “minimal source-backports for PHP 7.4, PHP 8.0, and PHP 8.1” for people who build PHP themselves, but these aren’t official releases. Some Linux distributions and long-term-support vendors ship their own backported fixes.
• Linux distributions got the patches early, so the PHP project tells you to “check your vendor for updated packages” rather than compiling PHP yourself.
• If you use the volunteer-run rpms.remirepo.net repository, PHP’s advisory says “the repo will not have updates today” (October 21) and urges switching to distribution packages or building from source.
• PHP 8.2 reaches end of life on December 31, 2026. The 8.2.35 fix buys you time, not a long-term home. If you track end-of-support dates for other software, our Windows end-of-support calendar uses the same “patch now, plan the move” logic.

Is WordPress affected?

Update (November 9, 2026): PHP2Shell itself still needs a PHP fix, not a WordPress one. Separately, WordPress core now has its own actively exploited flaw, CVE-2026-119977, in versions 4.7 through 7.1.3, fixed in WordPress 7.1.4. See our WordPress vulnerability 2026 explainer for how to update safely.

Yes. WordPress sites are affected because WordPress runs on PHP, but there is no WordPress update to install for this. WordPress.org’s own announcement on October 21 says the vulnerabilities “are not specific to WordPress and affect any server that hosts a PHP application. No WordPress update is required or planned for these issues.”

Wiz says it showed unauthenticated code execution against standard WordPress, Drupal and Joomla installs using the latest official container images. That’s a demonstration of impact, not a sign that WordPress code is at fault. Hostinger’s notice sums up the practical point well: “because the flaw is in PHP itself, updating WordPress, themes, or plugins won’t fix it. Only a patched PHP does.”

How to check your WordPress site’s PHP version: in the WordPress dashboard, go to Tools > Site Health > Info, then open the Server section and look at “PHP version.” WordPress.org notes many hosts also show it in the hosting control panel. If it reads 8.5.12, 8.4.27, 8.3.36 or 8.2.35 (or higher), the main fix is in place. If it shows something lower, or a version like 8.1 or 7.4, contact your host today.

One caveat: a distribution or control panel can backport the fix into an older-looking version number. cPanel, for example, lists patched builds such as ea-php81: 8.1.34-5 and ea-php74: 7.4.33-19, so the version Site Health shows (8.1.34 or 7.4.33) won’t tell you on its own whether the backport is installed. On those older branches, ask your host directly.

CloudLinux servers are a special case. cPanel’s notice lists the patched CloudLinux EasyApache 4 builds with the old upstream numbers, for example ea-php82: 8.2.34-2, ea-php83: 8.3.35-2 and ea-php84: 8.4.26-2. CloudLinux’s separate alt-php packages are patched the same way. So on a lot of shared hosting (often LiteSpeed plus CloudLinux), Site Health can show 8.2.34 even though the fix is in. Seeing 8.2.34 doesn’t prove you’re patched or unpatched. Only your host can confirm the build.

How to check your PHP version in cPanel

1. Log in to cPanel and open Software > MultiPHP Manager. It lists each domain and the PHP version it uses (for example “PHP 8.2 (ea-php82)”). The ea-php label tells you the branch, not the patch build.
2. If your host uses CloudLinux, you may see Select PHP Version under Software instead, or as well. It shows the “current PHP version” (like 8.2 or alt-php82) and lets you switch branches.
3. For the exact build number, use Tools > Site Health > Info > Server in WordPress, then compare it with the table above, keeping the backport caveat in mind.
4. Don’t move to an older branch to “get away from” the bug. Every unpatched branch is affected. If you change versions, pick 8.3 or newer and test your site afterwards.

What to ask your host

Send support a short ticket like this:

“Has my server’s PHP been patched for CVE-2026-109618 and CVE-2026-109619 (PHP2Shell)? Please confirm the exact PHP package or build serving my site (for example ea-php82 8.2.34-2, alt-php82 or 8.2.35), that the PHP workers (PHP-FPM, LiteSpeed LSAPI or mod_php) were restarted after the update, and whether you’ve checked my account for signs of compromise since October 17.”

A good host can answer this in a line or two. If they can’t say whether the fix is installed, or you’re on PHP 8.1 or older with no backport, ask them to move you to a patched build, or move hosts.

If you build or run WordPress sites with AI tools, as in our guides to building a WordPress website with Claude and connecting Claude to WordPress, nothing about those workflows changes. The risk sits one layer below, in the server’s PHP.

Is PHP2Shell being exploited?

Yes. Several security firms report active exploitation, and Amazon says it is now broad. The sources disagree slightly on timing and scale, so here is what each one actually says:

• Amazon Threat Intelligence (October 21): it found a PHP2Shell exploitation attempt against its MadPot honeypots dated October 17, four days before disclosure, from “a commercial anonymization network.” It saw multiple proof-of-concept exploits from about 02:00 UTC on October 21, and after the patch “additional proof-of-concept exploits appeared within hours.” Its conclusion: “PHP2Shell is now being broadly exploited in the wild.” Amazon advises investigating from October 17 onward, not from the disclosure date.
• watchTowr (October 21): it is “observing active exploitation attempts of both CVE-2026-109618 and CVE-2026-109619.”
• Cloudflare (October 21): it “observed attack traffic targeting our customers” after the details leaked, and watched attackers mutate payloads to try to get around its rules. Cloudflare CTO Dane Knecht told the BBC the company was “seeing early attacks emerging.” SecurityOnline reports that Cloudflare CEO Matthew Prince posted that attempts went from thousands before the announcement to “millions now.”
• Sophos, Hunt.io, SOCRadar and others (October 22–23): attempts continue, including one tied to the Mirai-derived “Potassium” botnet, but SecurityWeek reports no firm has confirmed a successful compromise. Sophos says “the lack of successful exploits in the wild suggests threat actors are also struggling.”
• CISA (October 21): at the time its alert was published, CISA had “not observed exploitation of these vulnerabilities.” CISA revised its alert on October 23 to add a SIGMA detection rule for spotting suspicious activity, fold in partner resources and reinforce its mitigation guidance; the revised alert still says CISA had not observed successful exploitation. CISA then added both CVEs to the Known Exploited Vulnerabilities list on October 26, 2026 (catalog version 2026.10.28).

Exploitation attempts aren’t the same as successful break-ins. Amazon notes “it’s unclear if any of these attempts would have succeeded in real-world systems.” But with public exploit code circulating, an unpatched internet-facing PHP server is a realistic target. A similar pattern played out this month with the Plex2Shell vulnerability, which went from public proof of concept to CISA’s exploited list within days.

Also patch your Node.js and Python stacks this week: a separate critical bug in the Brotli decompression library, CVE-2026-111497 (nicknamed HTTP2Shell or Node2Shell), was fixed on October 21 in Node.js 22.23.4, 24.22.1 and 26.12.1, Python Brotli 1.2.1 and Bun 1.4.4. Our Node.js vulnerability guide covers who is exposed and how to patch.

Why did websites go offline?

Because government agencies told organizations that couldn’t patch right away to take PHP systems offline. The details leaked online on October 20, before the planned release, so the usual quiet window for patching disappeared.

• CISA said organizations that can’t update immediately, “or that continue to use PHP 8.1 or earlier unsupported versions, should take PHP-based systems offline until they can be patched or updated.”
• The UK NCSC said that if you can’t update or apply PHP’s temporary mitigations quickly, “you should consider taking the system offline until it can be fully mitigated.”
• The NSA said in an October 21 advisory that PHP2Shell “could allow attackers to take control of affected web servers without prior access or authentication.” It recommended taking systems offline if an immediate update isn’t feasible. The FBI’s cyber division also warned the flaws could let attackers run code remotely, AP reported.
• ENISA, CERT-EU, Europol EC3 and the EU CSIRTs network issued a joint statement advising “immediate action.”

The BBC reported that the Finnish government temporarily shut its public web services, the Dutch cybersecurity agency took its own site offline, Edinburgh council’s site went down, and pages for several BBC programmes were taken offline. The Wikimedia Foundation told the BBC it took “a number of other systems” down as a precaution, which briefly affected parts of Wikipedia.

What should you do now?

Update PHP to a fixed version, restart every PHP worker, and check for signs of compromise from October 17 onward. What that means depends on who runs your server.

Sources: WordPress.org, cPanel, Hostinger, Cloudflare, watchTowr.

If your host manages PHP

Most WordPress site owners fall in this group. The fix happens on the host’s side, but it’s still worth confirming:

1. Look for an email or status update from your host. Hostinger says that on all its hosting plans except VPS there’s “nothing to do,” that “the circulating exploit did not work against our servers,” and that it is installing PHP’s fix on every server. WP Engine’s status page said on October 21 that it was deploying patches across its platform for every PHP version it runs, with protections already active at the CDN layer through Cloudflare and Fastly.
2. Check the PHP version in Site Health or your control panel.
3. If your site runs PHP 8.1 or older, ask the host whether a backport is installed, and plan an upgrade to 8.3 or newer. Old PHP was already a risk; this week made it urgent.
4. Keep WordPress, themes and plugins updated anyway. They don’t fix PHP2Shell, but an attacker who gets in through PHP will look for other weak spots.

If you run your own server

1. Update PHP from your distribution or vendor to 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or a package that carries the backport. On cPanel servers, cPanel’s guidance is to refresh the package cache and run /scripts/rpmup, then confirm with rpm -q --changelog ea-php81-php-cli | grep -m1 CVE-2026-109618 (swap in your PHP version).
2. Restart every PHP worker. watchTowr stresses that you need to restart workers “so the fix takes effect across the environment.” A patched binary on disk doesn’t protect a long-running PHP-FPM pool that hasn’t restarted.
3. Find PHP you didn’t know you had. CISA warns that “PHP is often a component of other software and prevalence may not be directly observable.” Control panels, appliances, phpMyAdmin and vendor products can bundle their own PHP.
4. Look for compromise. CISA says to watch for “PHP worker processes launching shells or downloading tools.” Amazon suggests looking for POST requests containing the PHP_SESSION_UPLOAD_PROGRESS string and for unexpected file changes. watchTowr recommends checking for new web shells, unexpected cron jobs and newly created accounts, and preserving logs before you change anything.

If you can’t patch right away

The PHP advisory lists temporary measures, but it’s blunt that “only an update is a complete solution.” The main ones:

• For CVE-2026-109619: set session.upload_progress.enabled=0 in php.ini or the FPM pool config (not .user.ini or ini_set()), then restart every worker. PHP says this “blocks the confirmed session paths but not other variants.” On PHP 8.5, also set fatal_error_backtraces=0.
• For CVE-2026-109618: set a low post_max_size (8M if you don’t need uploads, 32M if you do) and enforce request-size limits at the web server or proxy.
• Put a WAF in front. Cloudflare says its free and paid WAF customers were protected by default from 03:02 UTC on October 21, and CISA says a WAF “may provide some protection until systems are updated.”

watchTowr is more skeptical than PHP about config changes, warning that .ini mitigations “should be understood to be ineffective and not suitable to prevent exploitation.” Treat them as a stopgap for hours, not days. If none of this is possible, the agencies’ advice is to take the site offline until it’s patched.

How was PHP2Shell found, and what does AI have to do with it?

Researchers at Calif and Wiz found the bugs using frontier AI models, with OpenAI involved in the coordinated disclosure. According to Wiz’s timeline, it discovered the first vulnerability on August 19, 2026, confirmed unauthenticated code execution against Drupal on August 20 and WordPress on August 21, reported to the PHP security team on August 24, and PHP acknowledged the reports on September 21. watchTowr credits the discovery to the research team at calif.io, and Cloudflare lists Calif, Wiz, OpenAI and Quarkslab as the disclosing parties.

Wiz says it used its own Wiz Atlas tool along with Google’s Gemini 4 Argon and OpenAI’s GPT-5.6 Sol, and that “frontier models were critical to making this process practical, enabling us to develop and adapt working exploits across multiple applications in hours.” (If you’ve followed the model race, our earlier piece on the Gemini 4 Argon release date covers that model.) The BBC reports Calif and the PHP Foundation were part of an OpenAI program called “Patch the Planet,” and that OpenAI described the discovery as “one of the most impactful security issues in recent memory.”

The flip side is the lesson Amazon draws: AI makes it cheaper to turn an advisory or patch into a working exploit, so “more actors can act within hours or even minutes.” For critical bugs in internet-facing systems, Amazon says patch timelines should be measured “in hours,” not the 7- or 30-day windows many organizations use. Our AI agent security checklist covers the defensive side of the same trend. For the rest of this month’s urgent fixes, see our October 2026 Patch Tuesday roundup.

PHP2Shell timeline

Sources: Wiz, Amazon, watchTowr, Cloudflare, PHP, cPanel, BBC.

What we don’t know yet

• How many sites have actually been compromised. As of October 23, no security firm had confirmed a successful break-in. Amazon says it’s unclear whether the early attempts would have worked on real systems.
• Which appliances are still unpatched. CISA added both CVEs to its exploited list on October 26, but many firewalls, VPNs and NAS devices embed PHP and depend on vendor firmware updates.
• How the details leaked, and how an attacker was probing Amazon’s honeypots on October 17 while the bugs were still under embargo.
• Whether more variants turn up. Wiz says there are “other tracked, and likely untracked, variants” of the same pattern, but that PHP’s patch “fixes the issue at its core and eliminates all variants in the patched release.” Older, unpatched branches won’t get that protection.

We’ll update this post as the PHP project, CISA and the major hosts publish more.

FAQ

What is the PHP2Shell vulnerability?

PHP2Shell is the name for two critical flaws in the PHP engine, CVE-2026-109618 and CVE-2026-109619, both rated 9.2 on CVSS v4.0. A crafted web request can corrupt PHP’s memory and let an attacker run code on the server without logging in. PHP fixed them on October 21, 2026.

Which PHP version fixes the vulnerability?

PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 contain the fix. PHP 8.1 and older don’t get official releases; the PHP team published source backports for 7.4, 8.0 and 8.1, and some Linux distributions and vendors ship their own patched packages.

Do I need to update WordPress to fix PHP2Shell?

No. WordPress.org says the bugs are not specific to WordPress and “no WordPress update is required or planned.” Your host, or whoever runs your server, needs to update PHP. You can see your PHP version under Tools > Site Health > Info > Server.

Is PHP2Shell being exploited right now?

Yes, according to Amazon, watchTowr and Cloudflare. Amazon says PHP2Shell is “now being broadly exploited in the wild” and saw its first attempt on October 17. CISA said it hadn’t observed exploitation when it published its October 21 alert, and it added both CVEs to its Known Exploited Vulnerabilities list on October 26, 2026. As of October 23, no security firm had confirmed a successful compromise.

Will a firewall or Cloudflare protect my site?

It helps, but it isn’t a fix. Cloudflare says free and paid WAF customers were protected by default from October 21, yet it still tells customers to patch PHP. CISA says a WAF “may provide some protection until systems are updated.”

What if my site runs PHP 7.4 or 8.1?

Treat it as urgent. Those branches no longer get official PHP releases. Ask your host whether it installed a backported package (cPanel and some distributions offer them), and plan a move to PHP 8.3 or newer. CISA says unsupported PHP systems that can’t be patched should be taken offline.

What is CVE-2026-115560?

CVE-2026-115560 is a separate PHP session upload progress vulnerability disclosed on October 23, 2026. It only affects apps that switch session.serialize_handler from php_binary or php_serialize to php with ini_set() before session_start() while session upload progress is enabled. There’s no patch yet; PHP recommends setting session.upload_progress.enabled=0 until its next regular release.

Sources

• PHP project: News archive / security advisory (October 20–21, 2026), Supported versions, PHP 8 ChangeLog
• SecurityWeek: Mirai Botnet Operators Join PHP2Shell Attacks as ASLR Bypass Exploits Emerge (October 23, 2026)
• BleepingComputer: PHP shares mitigation for new RCE vulnerability with no patch (October 23, 2026)
• CISA: Critical Vulnerabilities in PHP Require Immediate Patching (October 21, 2026); Known Exploited Vulnerabilities catalog (version 2026.10.28)
• BleepingComputer: InfraTrust report warns of exploited flaws in critical network infrastructure (October 28, 2026)
• UK NCSC: Critical security issue affecting PHP
• ENISA: Joint statement on critical PHP vulnerabilities (October 21, 2026)
• WordPress.org: Critical PHP Security Release (October 21, 2026)
• Wiz: PHP2Shell: AI uncovers critical RCE vulnerabilities (October 21, 2026)
• watchTowr: PHP Remote Code Execution (“PHP2Shell”) (October 21, 2026)
• Amazon Threat Intelligence: PHP2Shell exploitation prior to public disclosure (October 21, 2026)
• Datadog Security Labs: PHP2Shell detection, analysis and remediation (October 21, 2026)
• Cloudflare: Cloudflare deploys protections against php2shell (October 21, 2026)
• cPanel: Critical PHP Security Release (October 22, 2026)
• Hostinger: Hostinger deploys protections against php2shell (October 21, 2026)
• NSA: Critical Patches Recommended for PHP Vulnerabilities (October 21, 2026)
• AP News: Some websites go dark as operators address an AI-detected flaw (October 21, 2026)
• Qualys: PHP2Shell: PHP patches two critical RCE vulnerabilities (October 21, 2026)
• Vercel: php2shell security bulletin
• BBC News: Websites taken down worldwide as critical PHP cyber-security update issued
• SecurityOnline: PHP2Shell exploited in the wild as PoC exploits go public (October 22, 2026)