INDEPENDENT AI JOURNALNEWS / ANALYSIS / RESEARCH
canberk.meAI NEWS
TR
Tools & Products

Critical PHP RCE found with AI: patched versions and mitigations

PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 fix two critical RCEs found with AI help. What is affected, how to mitigate, and who found what.

··8 min
Wiz Research illustration for PHP2Shell with the PHP logo held in a pink elephant's trunk, warning marks around it and the identifier CVE-2026-109618/9.
Illustration: © Wiz Research, from its PHP2Shell post.
In this article

If you run PHP, update to a release dated October 21 or later. PHP shipped fixes today for two critical bugs in its core engine, found with help from frontier AI models, that can allow unauthenticated remote code execution. We read PHP’s two security advisories, Wiz’s research post and OpenAI’s disclosure post in full. This article lists the fixed versions, what is known about exposure, the interim mitigations and who credits whom for the discovery. It leaves out exploit details.

What is the PHP vulnerability?

Two critical memory-safety bugs in PHP’s core, tracked as CVE-2026-109618 and CVE-2026-109619. Both are rated CVSS v4.0 9.2. The advisories describe them this way:

  • CVE-2026-109618 (OOM corruption): PHP uses longjmp() to exit when it runs out of memory. In some contexts request memory is reachable before it is fully initialized, so an early exit leaves it in an invalid state that the request shutdown then reads. Several multipart parsing problems can push a request into out-of-memory while it stays inside its apparent limits.
  • CVE-2026-109619 (stale global state): Some global state, such as error, session, object and extension state, points to memory owned by one request. A fatal error can abandon an operation before the matching reset, and a later request handled by the same worker can then use the stale state before normal initialization.

Wiz groups four bugs under the two CVEs: an upload-progress unserializer use-after-free and a remote memory disclosure, a fatal-error backtrace use-after-free, and an OPcache type confusion. It says other tracked and untracked variants exist and that the PHP patch fixes the problem at its core.

Which PHP versions are fixed?

PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. The advisories list each branch as vulnerable below those versions. Older branches are a different case:

  • PHP 8.1 and older no longer get updates from the project. php.net says minimal backports for 7.4, 8.0 and 8.1 exist in the php-src repository. Wiz says every release from the last decade has at least one affected issue, back to PHP 5.4.
  • PHP 8.2 reaches end of life on December 31, 2026.
  • Distributions and LTS vendors received patches in advance, according to php.net, so check your vendor’s package.
Card of the PHP fix and its interim mitigations: fixed versions 8.5.12, 8.4.27, 8.3.36 and 8.2.35, the only complete fix; partial mitigations are memory_limit set to minus one administratively, session upload progress disabled, fatal error backtraces off on PHP 8.5, conservative request size limits; do not use RLIMIT_AS or RLIMIT_DATA.
Fixed versions and partial mitigations, summarized by canberk.me from php.net and the advisories.

Who is exposed, and how badly?

It depends on how PHP is run. The CVSS vector for both advisories rates attack complexity as high and says attack requirements are present, so a 9.2 does not mean every server falls to a single request. What the advisories say:

  • Apache mod_php: remote code execution was validated over HTTP with default PHP input and memory limits and normal prefork setups with several workers. For CVE-2026-109618, mod_php runs request shutdown even when startup failed, so the attack happens before any application code runs.
  • FPM: it exits the child when request startup fails, which stops that exact sequence. The advisories call FPM susceptible by source analysis. For CVE-2026-109618 they say no complete FPM exploit has been demonstrated. For CVE-2026-109619 a validated FPM path depends on a suitable application operation.
  • FrankenPHP: source analysis suggests it is likely susceptible to application-independent attacks, like mod_php. LSAPI is modeled like FPM, with application-specific exploits likely but unvalidated.
  • Applications: Wiz demonstrated unauthenticated code execution against the latest WordPress, Drupal and Joomla container images and says a plain “Hello World” app on an affected version could be vulnerable, because the bugs are in PHP itself. It also demonstrated unauthenticated reading of worker memory, which it says can include passwords, tokens and API keys.

What can you do if you cannot update yet?

Reduce exposure, knowing none of this is complete. The advisories and php.net say these steps are not substitutes for updating, and that each setting must be applied administratively, not through ini_set() or .user.ini, followed by a restart of every worker:

  • memory_limit=-1 as an admin value removes the predictable limit that the confirmed OOM attack relies on. It is not complete, because other allocation failures can still trigger the vulnerable exit. Do not use RLIMIT_AS or RLIMIT_DATA, which make the vulnerable path more likely.
  • Keep post_max_size conservative and enforce decoded request size at the frontend. Bound multipart parts, headers per part, uploads and input nesting, or block multipart requests at the frontend if you do not use them.
  • session.upload_progress.enabled=0 removes the demonstrated session producer and consumer. The advisory suggests keeping it off even after patching if you do not need the feature.
  • On PHP 8.5, fatal_error_backtraces=0 removes the producer used by the confirmed code execution case for CVE-2026-109619.
  • Cgroup or container memory limits may help but are not guaranteed and can kill the master and every worker unless each has its own group.

The advisory for CVE-2026-109619 says there is no complete generic configuration mitigation. Wiz suggests watching for unusual multipart requests followed by memory-limit errors or repeated HTTP 500 responses, large or malformed PHPSESSID response cookies and unexplained PHP worker churn.

Who found it, and what did AI do?

The sources credit several parties and describe the AI role differently. The advisories credit four reporters by GitHub handle (lcfr-hax, sagitzadik-wiz, tomash-areion, amyb-oai) and four remediation developers (arnaud-lb, iluuu1994, bukka, ndossche). The vendors say:

  • OpenAI: Calif identified a critical flaw using GPT-5.6 Sol under OpenAI’s Patch the Planet initiative, and Wiz independently discovered and reported both vulnerabilities. OpenAI says that “to our knowledge” frontier AI found them before attackers did.
  • Wiz: its researchers used Wiz Atlas, Gemini 4 Argon and GPT-5.6 Sol, and credit Gemini 4 Argon with contributions to finding the bug, exploit development, attack detection and patch validation. Wiz’s timeline: first vulnerability found on August 19, code execution confirmed against Drupal on August 20 and WordPress on August 21, reported to PHP on August 24, acknowledged on September 21, patched and disclosed on October 21. Wiz says a single researcher did in a week what would previously have taken a world-class team months.

Both vendors frame the story as AI changing the economics of finding and exploiting old bugs. That is their interpretation. Wiz also likens it to Heartbleed and Log4Shell, and OpenAI calls it “one of the most impactful security issues in recent memory.”

What else did OpenAI announce?

A response framework and funding. OpenAI says it led a coalition of maintainers, researchers and security providers over the past two months. It published a PHP version checker and says a Codex skill is coming, committed $1 billion in subsidized Daybreak access through Daybreak for Frontline Defenders, and proposed a five-stage process for responding to critical bugs in widely used software. OpenAI says it engaged the White House’s Super Intelligence Force, the Office of the National Cyber Director and CISA. It asks the community to comment on disclosure windows, emergency patching and early notice.

What is still unknown?

  • Exploitation in the wild. None of the sources we read reports it.
  • Other variants. Wiz says more exist, and the patch is meant to cover them.
  • How many deployments are actually exploitable. It varies by server API, configuration and application.
  • Calif’s own write-up. Wiz says Calif and OpenAI published technical blogs, and we did not read Calif’s.

What to keep in mind

These are our observations:

  • Patch first. The fixed versions are the only complete remedy, and the mitigations above leave gaps.
  • Check how you run PHP. mod_php, FPM and FrankenPHP are exposed differently, according to the advisories.
  • Treat “70% of the web” as a usage figure. Wiz’s headline applies to how many websites use PHP, not to how many are exploitable.
  • The AI claims are the vendors’ own. They are plausible and consistent across the sources, but they are not independently measured.
  • It fits a pattern. See our Cairn investigation, where AI agents were used for intrusions, and the Claude NIST curve seeds analysis.

Editorial review: October 21, 2026 (AI). Prepared from the two GitHub security advisories (read in full through the GitHub API), Wiz’s post and OpenAI’s post (both read in full in a browser), and php.net’s October 21 announcement (read through a summarizing fetch, because the announcement page itself returned an error). We did not read Calif’s write-up, test any PHP version or mitigation, or confirm any exploitation. This is not security advice for your environment; follow PHP’s and your vendor’s guidance.

Sources

  1. PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35: critical security releases (php.net, October 21, 2026) ↗PHP
  2. CVE-2026-109618: RCE via OOM corruption (GHSA-w8hw-w9fx-j79w) ↗PHP / GitHub
  3. CVE-2026-109619: RCE via stale global state (GHSA-6wmf-4rv5-p3rp) ↗PHP / GitHub
  4. PHP2Shell: AI uncovers critical RCE vulnerabilities affecting 70% of the Internet (Wiz Research, October 21, 2026) ↗Wiz
  5. Patch the Planet: global response coordination as agents uncover critical vulnerabilities (OpenAI, October 21, 2026) ↗OpenAI

Created with AI assistance.

Suggest a correction

Found an error or a missing source? Send a private suggestion to the editor. It will be reviewed and will not appear as a public comment. No name, email or account is needed.

← Back to archive

Image

100%

Comments

No account or email needed. Every comment is reviewed by an editor before it appears.