PHPPHP2ShellCVE-2026-109618CVE-2026-109619SecurityWordPressWebsite SecurityAI 安全

What Is PHP2Shell? The PHP Flaws Under 70% of the Web, and the Three Things Your Site Needs Now

·Updated · 19 min read
Table of Contents
  1. What happened
  2. Who is affected
  3. Is it being exploited
  4. Three things your site needs now
  5. One: find out which PHP version your site actually runs
  6. Two: update, then restart
  7. Three: ask your host, and look for signs of trouble
  8. What it means that AI helped find it
  9. What we don't know yet
  10. FAQ
  11. Sources

Written 2026-10-26. The facts here come from PHP's official advisory, the CVE records, the discoverers' own write-ups (Wiz and Calif) and vendor advisories, and each section names its source. Where vendors contradict each other we say so, and where we could not find something we say we don't know.

On October 21, 2026, PHP shipped an emergency security release fixing two vulnerabilities, CVE-2026-109618 and CVE-2026-109619, now known together as PHP2Shell. Both score 9.2 (Critical) on CVSS 4.0. In PHP's own words, they "can allow unauthenticated remote code execution." An attacker does not need to log in, and your application does not need a bug of its own. A crafted web request may be enough to run their code on your server.

About the "70%" in the title. It comes from Wiz, one of the discoverers: PHP powers roughly 70% of websites. That is PHP's market share, not a count of compromised sites. But Wiz also says every PHP version released in the last decade is affected by at least one of the two flaws, going back to PHP 5.4. So if your site runs PHP and nobody has touched the server this week, you are probably in scope.

The short version:

If your site runs WordPress, Laravel, Drupal, Joomla, Magento or any PHP code, confirm that the server's PHP is on 8.5.12, 8.4.27, 8.3.36 or 8.2.35 (or your host's patched package), and that the PHP processes were restarted after the update. Updating WordPress or plugins does not fix this.

What happened

Item Detail
Vulnerabilities CVE-2026-109618 (corruption during out-of-memory handling), CVE-2026-109619 (state left over after a request points to freed memory)
Severity CVSS 4.0: 9.2 Critical (both)
Preconditions No login, no user interaction; high attack complexity, specific conditions required (CVSS vector AC:H/AT:P)
CISA assessment CISA's ADP entry in the CVE records (assessed Oct 21, updated Oct 22) says no exploitation evidence and not automatable; this may change
Fixed versions 8.5.12, 8.4.27, 8.3.36, 8.2.35 (released 2026-10-21)
8.1 and older No longer updated by PHP; source patches provided for 7.4, 8.0, 8.1

Per PHP's advisory, in plain terms:

  • CVE-2026-109618: when memory runs out, PHP interrupts the request while some internal data is only half built. The cleanup step then treats that half-built data as valid.
  • CVE-2026-109619: internal state owned by one request survives after its memory has been freed. The next request handled by the same PHP worker may use that stale state before it is reset.

Both are memory-safety bugs. The real fix is updating PHP.

The timeline matters too. PHP pre-announced a 14:00 UTC release on Oct 21. Securelist and others say details leaked before then (in a Hacker News post); the advisory went out around 13:34 UTC. Wiz's timeline says it found the issues on August 19 and reported them on August 24. Calif, the other discoverer, says it found them on August 1 and reported on August 11. Calif's timeline (Aug 1) and Wiz's (Aug 19) are under three weeks apart; GitHub credits four reporters, and Wiz says it worked with PHP, Calif and OpenAI on discovery before disclosure.

Who is affected

Server setup: per PHP, every PHP installation serving web requests is at risk, including PHP-FPM, Apache mod_php, php-cgi, FrankenPHP and LiteSpeed. PHP rates mod_php highest, because there is a demonstrated exploit that fires before any application code runs.

Versions: everything before the 8.2 to 8.5 fixed releases. PHP no longer fixes 8.1 and older; Wiz says the impact goes back to 5.4.

WordPress, Laravel and other frameworks: the flaws are in PHP, not in the framework. Calif lists applications where it confirmed unauthenticated code execution under default configurations, including WordPress 7.1.2, Drupal 11.4.3, Joomla 6.1.4, Magento 2.4.9, phpMyAdmin 5.2.3, Nextcloud 35.0.1, Laravel 13.11, Symfony 8.1 and WHMCS. Wiz separately demonstrated it against the official latest container images of WordPress, Drupal and Joomla. Those are the versions Calif tested; newer releases have shipped since, and they do not change this, because the flaw is in PHP. WordPress's own October 21 announcement says the vulnerabilities are not specific to WordPress and that what site owners need to update is PHP. "My WordPress is up to date" is not a reason to feel safe.

Shared hosting: you usually cannot update PHP yourself, and you cannot apply PHP's temporary mitigations either. PHP says those settings must go in php.ini, an FPM pool or the server configuration, and explicitly not in ini_set() or .user.ini. Our inference: on shared hosting, the one thing you can do is confirm your host has patched. The third step below gives you the wording.

Is it being exploited

As of 2026-10-26, vendors disagree. Here is what each says:

  • Public exploits: Rapid7 says multiple public proofs of concept exist, but each one works only against a specific combination of operating system, PHP version and web server, and none appears to be broadly reliable. Rapid7's own attempts worked only under narrow lab conditions. Rapid7 also warns that a more portable exploit technique could emerge at any time, and that the current difficulty should be treated as a window to patch, not a reason to delay.
  • Attempts: Rapid7 reports multiple exploitation attempts but has not observed exploitation in the wild. Sophos sees scanning and a small number of failed attempts, and corrected an earlier, stronger statement on October 22. According to Help Net Security, Amazon's honeypot network recorded an exploitation attempt on October 17, four days before public disclosure.
  • A retracted intrusion report: Palo Alto Networks' Unit 42 reported on October 23 that it had seen a compromise at a European government agency, then retracted it on October 25, saying it could not confirm that initial access was tied to PHP2Shell.

Our reading: exploit code is out, people are scanning, people are trying. No confirmed mass compromise yet does not mean you can wait.

Patching has been slow. OX Security measured with Shodan and found that 24 hours after the release, 99.3% of vulnerable PHP hosts with a visible version number still did not show a patched version. (OX only reads the version string the server advertises. Our inference: distribution patches often keep the old version number and get counted as unpatched, so treat the figure as a direction, not a precise rate.) Bitsight reports that among PHP hosts whose version it could identify, only about a third run 8.2 to 8.5, the branches with official fixes, and the most common branch is 7.4.

Three things your site needs now

One: find out which PHP version your site actually runs

How you check depends on who you are:

  • On WordPress: in the admin, go to Tools, then Site Health, then Info, then Server. It lists the PHP version.
  • On shared hosting: your hosting control panel (for example cPanel's PHP version selector or MultiPHP Manager, or Plesk's PHP settings) shows the PHP version per domain. Panels usually show only the branch (for example 8.2), not the patch level, so you still need to ask your host.
  • Engineers with server access: php -v shows the command-line PHP, which may not be the one serving web pages. To see what the web server actually runs, check phpinfo() from the web context (and delete that file right after), and check package versions with your package manager, for example dpkg -l | grep php or rpm -qa | grep php.

The version number is not the final word. Linux distributions often backport the fix into an older package and keep the version number. Per Wiz's vulnerability database, for example, Ubuntu's fixed php8.1 package is 8.1.2-1ubuntu2.28, and php -v still says 8.1.2. An old-looking version may be patched, and an 8.3.x may not be. Check the package version or ask whoever provides it.

With server access you can also search the package changelog, for example apt changelog <package> | grep CVE-2026-10961 or rpm -q --changelog <package> | grep CVE-2026-10961. This only works if your distribution lists the CVE in its changelog, so no match does not mean unpatched.

Two: update, then restart

  • On 8.2 to 8.5: update to the fixed release for your branch (8.5.12, 8.4.27, 8.3.36 or 8.2.35), or to the patched package from your distribution or host.
  • Restart every PHP process after updating (php-fpm, apache2 or httpd, frankenphp, or lsws/lsphp on LiteSpeed). Google Cloud's advisory calls this out: updating the packages on disk without restarting leaves the old, vulnerable processes running.
  • After updating, PHP also suggests setting session.upload_progress.enabled=0 until the next regular release (for CVE-2026-115560; php.net says apps that never switch the session serialize handler at runtime can keep it on. If you're not sure, turn it off.)
  • On 8.1 or older: PHP will not ship new releases. In order of preference: move to a patched 8.3 or later (8.2 security support ends 2026-12-31, so go to 8.4 or 8.5 if you can); or confirm your distribution, host or long-term support vendor ships a patched package; or build from PHP's source patches for 7.4, 8.0 or 8.1. Check theme and plugin compatibility before upgrading. That is why so many sites are still on 7.4, but staying put just got more expensive.

If you truly cannot update right away, PHP published temporary mitigations, and says plainly that they "reduce exposure to specific attack paths but do not make an installation safe":

; Related to CVE-2026-109619. Restart every PHP worker after changing.
session.upload_progress.enabled = 0
; PHP 8.5 only
fatal_error_backtraces = 0

; Related to CVE-2026-109618
; Set memory_limit in a way applications cannot override, such as php_admin_value
memory_limit = -1
; 8M for sites without file uploads, 32M if uploads are needed; keep upload_max_filesize below it
post_max_size = 8M

memory_limit = -1 removes PHP's own memory cap. PHP recommends pairing it with a container or cgroup memory limit so a single worker cannot take down the machine, and specifically warns against using RLIMIT_AS or RLIMIT_DATA instead. Have someone who knows your server make these changes; getting them wrong can break the site.

A WAF in front of the site adds a layer. Help Net Security quotes Cloudflare's CTO saying its rules for the known exploit vectors are available to all customers, including free plans, and per PPC Land's report Cloudflare itself says you still need to update PHP. A WAF is the second layer, not the fix.

Three: ask your host, and look for signs of trouble

On shared or managed hosting, send your host this:

Hi, I'd like to confirm how you've handled PHP2Shell (CVE-2026-109618 and CVE-2026-109619):

  1. Which PHP version and package version does my site (domain: ____) actually run?
  2. Does that version include the fixes for both CVEs?
  3. Were the PHP processes restarted after the update?
  4. If I'm on 8.1 or older, do you provide a patched build, or which version do you recommend I move to?

If they cannot answer question 2, or reply with something unrelated like "our PHP is very stable," that is your answer.

If you have server access, look for these signals (from Wiz's and Google Cloud's advisories):

  • Unusual multipart upload requests followed by memory limit errors (Wiz)
  • PHP-FPM workers respawning in bulk with SIGSEGV (exit code 139), or core dumps (Google Cloud)
  • sh, bash, curl or wget running as children of php-fpm, apache or httpd (Google Cloud)
  • Bursts of POSTs to the same URL alternating between 500 and 200 (Google Cloud)
  • Responses carrying an abnormally long Set-Cookie: PHPSESSID= (over 256 bytes) (Google Cloud, Wiz)

Not seeing these signals does not mean you are clean: Google Cloud notes at least one exploit chain leaves no crashes and no error-log entries. If you suspect a compromise, have whoever handles it capture memory before restarting PHP (Google Cloud).

If you do see these signals, keep the logs, don't reboot away the evidence, and bring in someone who handles security incidents.

The UltraProbe scan at the bottom of the page checks SEO, AEO, AAO and AI-defense signals. It does not check your PHP version or these two CVEs, so a clean scan does not mean you are patched.

What it means that AI helped find it

Wiz's headline is "AI uncovers critical RCE vulnerabilities affecting 70% of the Internet." Wiz writes that it "used Wiz Atlas, Gemini 4 Argon, and GPT-5.6 Sol throughout this research, with Argon making a particularly significant contribution to finding and helping to remediate the vulnerability." It also writes that the underlying flaws had existed for a long time, that proving them exploitable took a very complex chain of steps, and that "Frontier AI models substantially reduced that barrier, turning a longstanding flaw into an exploit." The Wiz post also quotes Google DeepMind, so the account of AI's role comes from parties with a product interest.

Calif, the other discoverer, is more measured. Calif researcher Ryan Austin writes: "No special harness, or access to models that weren't generally available to everyone were used in the initial bug discovery." He chose a target he knew well, including its vulnerability history, and went in with a specific theory. He also notes that models by default work from the newest and most prominent bugs toward nearby older code, and do not reliably start from obscure twenty-year-old exploitation techniques.

The two accounts don't conflict, and together they are closer to the truth: people who knew the target found this with AI. AI did not find it on its own. For defenders, three things are clear:

  1. The patch window is shorter. Wiz writes that adapting an exploit to different PHP versions, configurations and memory layouts used to be a real barrier, and that LLMs now help with it. Several teams found the same problems within weeks, and details leaked before the planned disclosure. The time from "someone knows" to "someone is trying" has compressed. "We'll update at next month's maintenance" is too slow for a bug of this class.
  2. Old bugs will get dug up again. This one traces back to early design decisions; Calif's timeline mentions a related memory-limit issue found back in 2004. AI makes a second look at old code cheap, which raises the risk for systems nobody has touched in years.
  3. Defense starts with knowing what you run. Whether you could handle this in a day depends on whether you can answer, right now, how many sites you have, which PHP version each runs, and who updates them. That list should exist before the next one.

What we don't know yet

  • Confirmed in-the-wild compromise: none as of 10/26. This can change at any time; follow PHP's and the major vendors' updates.
  • How many sites in any given country are affected: none of the public sources we read breaks exposure down by country, so we give no regional numbers.
  • Which attack path belongs to which CVE: PHP's advisory and Wiz's vulnerability table assign some paths differently. For site owners it doesn't change the action. Fix both.
  • Whether CISA has added these to its Known Exploited Vulnerabilities catalog: we found no record at the time of writing.

FAQ

What is PHP2Shell? The name for two vulnerabilities in PHP itself, CVE-2026-109618 and CVE-2026-109619, both CVSS 4.0 9.2. They may let someone who is not logged in run code on the server. PHP released fixes on 2026-10-21 in 8.5.12, 8.4.27, 8.3.36 and 8.2.35.

Is PHP2Shell being exploited? As of October 26, 2026, multiple public proof-of-concept exploits exist and several vendors have seen scanning and exploitation attempts. None of the major vendors we read stands by a confirmed successful compromise; Unit 42 retracted its earlier intrusion report on October 25. That does not mean you are safe. It means it is early.

My WordPress is up to date. Do I still need to act? Yes. The flaws are in PHP, not WordPress. Calif confirmed unauthenticated code execution against WordPress 7.1.2 under default configuration, and Wiz demonstrated it against the official latest WordPress container image. What needs updating is the PHP on your server.

I'm on PHP 7.4. What now? PHP no longer ships 7.4 releases but did publish source patches. In practice: first ask your host or distribution whether a patched package exists; in the medium term, move to a patched 8.3 or later (8.2 security support ends 2026-12-31, so go to 8.4 or 8.5 if you can).

I use Laravel or my own PHP code. Am I affected? Yes. Anything that serves web requests through PHP is in scope, whatever the framework. Calif's confirmed list includes Laravel 13.11 and Symfony 8.1.

I'm behind a WAF or Cloudflare. Can I skip the update? No. A WAF blocks known attack patterns, but bugs like these have many variants, and Cloudflare itself says you still need to update PHP.

Another PHP vulnerability was announced on 10/23. Is it the same thing? That is CVE-2026-115560, related to the session upload progress feature. PHP's own 10/23 advisory says it only triggers when an application switches session.serialize_handler to php at runtime with upload progress still enabled, so it is being handled in the next regular release (not out as of 10/26). PHP suggests setting session.upload_progress.enabled=0 until then, even if you have already installed the patched versions. Restart PHP after changing it.

PHP for Windows now has "-1" builds. Is that related? No. On 10/26 PHP published Windows rebuilds (8.5.12-1 and so on) that fix a Brotli vulnerability, CVE-2026-111497, unrelated to PHP2Shell. The PHP version itself is unchanged.

How do I confirm my host has patched? Ask three things: the actual PHP version and package version, whether it includes the fixes for both CVEs, and whether PHP processes were restarted after the update. There is a template above you can copy.

Sources

Update log: 2026-10-27, corrected the exception for keeping session.upload_progress on, per php.net's 10/23 advisory.

Related Posts

MCPAI 安全

The July 2026 MCP Server Auth Epidemic: 12 Projects, 19 Advisories, and the Reference SDK Itself

10 min read
GPT-6OpenAI

What Is GPT-6 Astra? Capabilities, Pricing, API Migration, and Five Safety Numbers to Read Before You Hand It an Agent

13 min read
AI 安全Prompt Injection

The Scanner Had the Bug It Was Looking For: Auditing Someone Else's Invisible-Character List, Then Our Own

16 min read

Weekly AI Automation Playbook

No fluff — just templates, SOPs, and technical breakdowns you can use right away.

Join the Solo Lab Community

Free resource packs, daily build logs, and AI agents you can talk to. A community for solo devs who build with AI.

Join Discord (Free)

Want to try it yourself?

UltraProbe is free and needs no sign-up. One scan tells you whether Google and AI engines can find your site.

Scan your site free