What happened
On 2026-10-21 the PHP project released PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. The releases fix two vulnerabilities, CVE-2026-109618 and CVE-2026-109619, which the project says "can allow unauthenticated remote code execution". Its advice is short: "updating is the only safe choice".
The part that made this the week's biggest story is where the bugs live. They are not in WordPress, Drupal or a popular plugin. They are in PHP's own engine, so the advisory puts every PHP install that serves web requests at risk: PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. The risk is highest for mod_php, where a request can trigger the attack before any application code runs. Your own code can be perfect and still not matter.
The second part is who found them. Wiz, which named the bugs PHP2Shell, says it used Wiz Atlas, Gemini 4 Argon and GPT-5.6 Sol, and that "Gemini 4 Argon made an invaluable contribution to finding the vulnerability". Calif (Patch the Planet) and OpenAI had each reported the same out-of-memory root cause independently, both on 2026-08-11, according to the PHP Foundation's account.
How the two bugs work
The advisory describes both in a sentence each, and they share a theme: memory that PHP believes is in a good state when it is not.
CVE-2026-109618, RCE via OOM corruption. When PHP runs out of memory, its out-of-memory handling can interrupt the engine while request data is only half initialized. The cleanup code that runs afterwards treats that half-built data as valid. An attacker who can push a request into that state can turn the cleanup into code execution.
CVE-2026-109619, RCE via stale global state. Some request state survives after its memory has been freed, and a later request on the same worker uses it. PHP workers are long-lived processes that serve request after request, so state leaking from one request into the next is exactly the kind of bug that stays hidden for years.
Wiz counts 4 bugs under the 2 CVEs, and says "every PHP version released in the last decade is affected by at least one of these vulnerabilities, going back to version 5.4." Wiz confirmed unauthenticated remote code execution against Drupal on 2026-08-20 and against WordPress on 2026-08-21, then reported its attack vectors to the PHP security team on 2026-08-24.
A messy release
Coordinated disclosure did not go to plan. The PHP Foundation says the CVE IDs leaked on 2026-10-20 around 15:00 UTC, with a wrong release time and a wrong CVSS score: the leak said 10.0, the real score is 9.2. PHP pre-announced at 19:30 UTC and pulled the release forward a day, from 2026-10-22 to 2026-10-21 at 14:00 UTC. Even then, Chainguard published images with the fix at 07:41 UTC, more than six hours before the coordinated release.
Because the bugs are severe, the PHP security team also shipped minimal source backports for PHP 7.4, 8.0 and 8.1, versions the project no longer supports. That is unusual, and it tells you how many old installs the team expects to still be out there.
There is already a follow-up. On 2026-10-23 PHP published a separate advisory, CVE-2026-115560, about session upload progress. It is narrow: it affects only applications that switch session.serialize_handler to php at runtime with ini_set() before session_start(). The advice until the next bugfix release is session.upload_progress.enabled=0. It is not a correction to the 2026-10-21 advisory, but if you are already patching, check it in the same pass.
What you should actually do
The advisory is blunt that the only complete fix is the update. Linux distributions and LTS vendors received the patches in advance, so the first stop is your vendor's packages. PHP 8.6.0 RC4, announced the same day, includes the fixes too.
If you cannot update today, the advisory lists stopgaps for the out-of-memory bug, and says plainly that they "do not make an installation safe":
- Set
memory_limit=-1somewhere applications cannot override it, such asphp_admin_valuein the FPM pool or Apache configuration. - Set a low
post_max_size: 8M if the application takes no file uploads, 32M if it does. - Use a container or cgroup limit as the availability boundary, ideally one that kills only the affected worker. Do not reach for
RLIMIT_ASorRLIMIT_DATA, because those can cause the very allocation failure the bug needs.
Wiz says Cloudflare, Fastly, Google and Vercel shipped mitigations at the edge. Nobody has described what those rules block, so treat them as a seatbelt, not a fix.
Why this matters if you build web apps with AI
Your frontend is probably not the risky part. A lot of React and Next.js sites read from a PHP backend: headless WordPress for the blog, a Laravel API, a Drupal CMS for the marketing team. The Next.js app gets a dependency bump every week. The PHP box behind it was set up once and left alone. This bug lives in that box, and a request that never touches your frontend can reach it.
Ask where your PHP actually runs. Managed WordPress hosts will patch for you; a VPS someone configured years ago and forgot will not. If a client's site has a "headless CMS" in the architecture diagram, find out who owns the PHP version on it and when it last changed. PHP 8.2 reaches end of life on 2026-12-31, so anyone patching onto 8.2.35 now has a second upgrade to plan.
This is what AI security research looks like now. Gemini 4 Argon helped find a flaw that reaches back to PHP 5.4. The Foundation says PHP was scanned earlier in 2026 with Anthropic's Claude Mythos, through Alpha-Omega, and it added OpenAI's Daybreak Red to validate reports and exploits. Models are reading old, heavily used C code and finding things humans missed for a decade.
And the flood is real too. The same Foundation post counts 15 CVEs published by the PHP security team since 2026-07-01, plus more than 100 reports that were invalid, duplicates or not reproducible. AI finds bugs, and it also buries volunteer maintainers in reports they have to disprove one by one.
What is not known yet
- Whether the CLI SAPI is affected. The advisory does not name it.
- How many servers are exposed. Wiz claims PHP powers 70% of all websites, but neither Wiz nor PHP gives a count of vulnerable servers.
- What the edge mitigations block. Wiz names the providers, not the rules.
- Whether exploitation in the wild has started. None of the sources says so; the advisory mentions only a demonstrated exploit against mod_php.
My take
This section is my opinion, Amar's, not reporting.
I build on the JavaScript side, React and Next.js, and the uncomfortable lesson for people like me is that "the backend is someone else's problem" stops being true the moment you ship the site. If I hand a client a fast Next.js frontend on top of their existing WordPress, the thing an attacker hits is the server I did not touch. So I would put one line in every handover for a headless build: which PHP version the CMS runs, who updates it, and how they hear about an advisory like this one.
The AI part I find more hopeful than scary. A model helping find a decade-old engine bug before attackers did is the good version of this story. The 100-plus junk reports are the bad version, and the fix for that is the same thing I want from any agent I run: it should prove its claim, with a working reproduction, before a human spends an hour on it. The Foundation adding a tool to validate reports and exploits is exactly that idea, applied to security.
