PHP2Shell: Two Critical RCE Flaws in PHP

Vulnerability
All News

PHP's security team shipped emergency patches today for two vulnerabilities in the PHP engine itself, tracked as CVE-2026-109618 and CVE-2026-109619 and dubbed PHP2Shell by the researchers who found them. Both allow unauthenticated remote code execution, and neither requires a flaw in your application. If you operate anything that serves PHP, whether it is a WordPress blog, a Laravel app, a custom CMS, or a forgotten script on a VPS, treat this as an emergency and patch today.

What happened

The vulnerabilities were discovered by Wiz Research in a coordinated disclosure with Calif, OpenAI, and Quarkslab. They were scheduled for release on October 22, but details leaked on Hacker News a day early, so PHP moved the release up and shipped fixes on October 21, 2026. Proof-of-concept code is already circulating, and Cloudflare reports observing live attack traffic attempting to exploit the flaws, including mutated payloads designed to bypass WAF rules.

The vulnerabilities

Both bugs are memory-safety issues rooted in how PHP handles fatal errors, particularly out-of-memory errors triggered by the memory_limit setting. A request that dies mid-flight can leave PHP's internal state corrupted or stale. A later request handled by the same worker then reuses that state before it is reset. Each carries a CVSS v4.0 score of 9.2 (critical).

  • CVE-2026-109618: RCE via OOM corruption. PHP enforces memory_limit by aborting the request with longjmp(), which can interrupt PHP while internal request data (for example, a multipart file upload) is only partially initialized. Cleanup then treats invalid data as valid and frees memory that was never initialized, memory an attacker may control.
  • CVE-2026-109619: RCE via stale global state. Request-owned internal state can survive after its backing memory has been freed, for instance after a fatal error. The next request on the same worker may consume that stale state before normal initialization resets it, yielding a use-after-free, memory disclosure, and code execution with the web worker's privileges.

Separately, Wiz demonstrated a Heartbleed-style memory disclosure. An attacker can read live worker memory that may contain passwords, session tokens, API keys, and certificates belonging to other requests, without achieving code execution, and even when the application never calls session_start().

Who is affected

Every PHP installation that serves web requests: PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP, and LiteSpeed. Every PHP version released in the last decade is affected by at least one of the two flaws, going back to PHP 5.4. Wiz confirmed pre-authentication RCE against stock deployments of WordPress, Drupal, and Joomla, but the bugs live in PHP itself, so even a "Hello World" application is vulnerable. The PHP team considers mod_php the highest-risk setup, with a demonstrated exploit where a single unauthenticated request triggers the attack before any application code runs. PHP powers roughly 70% of websites, and VirusTotal estimates over 5.1 million PHP hosts are exposed online.

What to do right now

  1. Patch. Update to PHP 8.5.12, 8.4.27, 8.3.36, or 8.2.35. Linux distributions and LTS vendors received the patches in advance, so apply your vendor's packages as soon as they appear. There is no configuration-only fix. PHP's own advisory states these measures only reduce exposure to specific attack paths, and a core developer has confirmed that no complete mitigation exists besides patching.
  2. Handle end-of-life versions. PHP 8.1 and older no longer receive updates from the PHP project. The security team published minimal source backports for PHP 7.4, 8.0, and 8.1 for source builders, but the correct move is to upgrade to a supported branch.
  3. If you cannot patch immediately, apply interim measures from the official advisory:
    • Set memory_limit=-1 via php_admin_value (FPM pool or Apache config) so applications cannot override it. This removes the controllable memory-limit failure path.
    • Set a low post_max_size (8M without uploads, 32M with) and enforce request-shape limits at the web server or proxy.
    • Set session.upload_progress.enabled=0 and restart every worker via php.ini or server config, not ini_set() or .user.ini.
    • On PHP 8.5, set fatal_error_backtraces=0 and restart every worker.
  4. Isolate what you cannot patch. CERT-EU advises isolating internet-facing PHP applications from public networks until a fix is applied and verified. The UK NCSC has told organizations to update or take systems offline.

What exploitation looks like

Because these flaws execute below the application layer, application logs may show little context. Wiz recommends watching for:

  • Unusual multipart requests followed by memory-limit errors or repeated HTTP 500 responses
  • Unexpectedly large or malformed PHPSESSID response cookies
  • Unexplained PHP worker churn

Why this one matters

The vulnerable code had been present for over a decade. What changed is that Wiz used frontier AI models to chain the bugs into a working exploit, adapting it to different applications and memory layouts. In their words, what previously would have taken a world-class team months was done by a single researcher in a week. As with Heartbleed and Log4Shell before it, PHP2Shell is a reminder that a flaw in shared infrastructure outweighs any amount of application-level hardening. The shift is uncomfortable. Memory-corruption bugs once dismissed as "theoretical" or too complex to weaponize reliably are no longer safe to defer.

The authoritative source is the PHP security advisory, and details are still developing as the industry publishes follow-up analysis. The guidance will not change, though. Patch every PHP server you run, today.

Back to top