OMFG! That day has come!

🧟 Wiz Inc.: PHP2Shell: AI uncovers critical RCE vulnerabilities affecting 70% of the Internet

🧟 Calif Research: A tale of two PHP remote vulnerabilities

🧟 OpenAI: Patch the Planet: global response coordination as agents uncover critical vulnerabilities

🧟 The PHP Foundation: Today’s PHP Security Release, and How We’re Strengthening PHP Security

🧟 PHP2Shell main page

🧟 Wikipedia PHP2Shell

🧟 NIST: CVE-2026-109618 Detail

🧟 NIST: CVE-2026-109619 Detail

🧟 PHP.net: Security advisory: Critical remote code execution vulnerabilities, update now

PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 fix two critical vulnerabilities that can allow unauthenticated remote code execution. All PHP users are strongly encouraged to update immediately.

Who is at risk: all PHP installations serving web requests, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. We consider the risk highest for mod_php, with a demonstrated exploit where an unauthenticated request can trigger the attack before any application code runs.

The vulnerabilities:

  • RCE via OOM corruption, CVE-2026-109618 (GHSA-w8hw-w9fx-j79w): 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.
  • RCE via stale global state, CVE-2026-109619 (GHSA-6wmf-4rv5-p3rp): 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.

How to update:

  • Update to PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35. Source downloads are on our downloads page. Windows source and binaries are on the same page.
  • Linux distributions and LTS vendors received the patches in advance, so check your vendor for updated packages.
  • PHP 8.1 and older no longer receive updates from the PHP project. Some distributions and LTS vendors provide backported fixes, so contact your vendor for details, or upgrade to a supported version.
  • If you rely on the volunteer-maintained rpms.remirepo.net, we urge you to switch to distribution packages or build from source, so you can immediately apply updates. The repo will not have updates today.
  • Given the severity of these vulnerabilities, the PHP security team provided minimal source-backports for PHP 7.4, PHP 8.0, and PHP 8.1 to help people building from source or without access to an LTS vendor.

If you cannot update immediately: while only an update is a complete solution, the following measures reduce exposure to specific attack paths but do not make an installation safe.

RCE via OOM corruption (CVE-2026-109618):

  • Set memory_limit=-1, preferably in a way applications can’t override, such as php_admin_value in the FPM pool or Apache configuration, and check that no pool, directory or application setting puts a finite limit back. This removes the controllable PHP memory limit failure, but an underlying allocation failure can still reach the vulnerable path.
  • Set a low post_max_size. For applications that don’t require file uploads, set post_max_size = 8M. If file uploads are necessary, set post_max_size = 32M. Keep upload_max_filesize below post_max_size. Consider enforcing limits at the web server or proxy level for decoded request size, input field count, multipart part count, header count, and nesting depth. These limits must also cover requests without a usable Content-Length.
  • Use a container or cgroup limit as an availability boundary, preferably with a policy that kills only the affected worker. Do not substitute RLIMIT_AS or RLIMIT_DATA, as these can cause the vulnerable allocation failure.

RCE via stale global state (CVE-2026-109619):

  • Set session.upload_progress.enabled=0 and restart every worker. Use php.ini, an FPM pool or server configuration that applies before request parsing. Do not rely on ini_set() or FPM .user.ini. This blocks the confirmed session paths but not other variants.
  • On PHP 8.5, set fatal_error_backtraces=0 and restart every worker. This blocks the confirmed fatal backtrace path only.
  • Remove invalid or deprecated settings applied per request that emit diagnostics before initialization. Hiding diagnostics with error_reporting, display_errors or @ does not help.
  • Fix attacker-reachable fatal errors and execution timeouts, including failures in callbacks, upload or import processing and cleanup.

The advisories linked above have the full technical details.

🧟 IONOS.fr: Maintenance de sécurité : de brèves interruptions possibles sur les services basés sur PHP

Que se passe-t-il ?
Une faille de sécurité critique a été découverte dans PHP, une technologie utilisée par de nombreux sites Web et applications Web à travers le monde. Les développeurs de PHP et les autorités nationales chargées de la sécurité ont émis des alertes urgentes et recommandent d’installer immédiatement la mise à jour de sécurité, car des attaques sont attendues dans les prochaines heures.
Afin de vous protéger, vous et vos données, nous procédons dès à présent à l’installation de la mise à jour de sécurité sur l’ensemble de nos systèmes. Nous prévoyons d’avoir terminé dans les prochaines 24 heures.

Qu’est-ce que cela signifie pour vous ?
Pendant la mise à jour de nos systèmes, certains sites web et services pourraient être ralentis ou brièvement indisponibles. Nous prenons cette mesure pour vous protéger.

Si vous exploitez une application en gestion autonome, par exemple sur un serveur VPS ou un serveur bare metal, veuillez installer la mise à jour de sécurité PHP dès que possible afin de protéger vos systèmes. Vous trouverez plus d’informations ici : https://www.php.net/

Merci de votre patience et de votre compréhension.

Posted Oct 21, 2026 – 18:11 CEST

I want back to Geocities! It was plain HTML, right?

Affected versionsPatched versions
< 8.2.358.2.35
< 8.3.368.3.36
< 8.4.278.4.27
< 8.5.128.5.12

My blog:

PHP version 8.3.36 (Supports 64bit values)

Je l’ai échappé belle !

UPDATE: How was this possible? I am outraged!

● Ludditus: I am outraged regarding the way PHP2Shell was handled. In spite of the severity of CVE-2026-109618 and CVE-2026-109619, and of the fact that they affected roughly 70% of the world’s servers, the existence of these 2 vulnerabilities was publicly announced on October 20, whereas the patches were only released the following day.

This discovery was a joint operation by Calif Research, Wiz, Inc., and OpenAI. I’d have expected a much more responsible approach. Maybe the PHP Foundation had been announced before October 20—I can’t possibly know. But, IMNSHO, a sensible handling could have been along these lines:

  • Day 0: Provide the PHP team with all details, and keep the information confidential.
  • Day 0: Provide MITRE with generic details so that CVEs are assigned (RESERVED) with the proper (very high) score.
  • Wait for patches to be released.
  • Day D: PHP releases patches and tells the world, “update, or you’ll fucking die!”
  • Wait at least 48 or 72 hours for the planet to react: Linux and the BSDs to build packages, mirrors to sync, the planet to update their servers.
  • Day D+3 or more: Disclose everything regarding the vulnerabilities. CVEs are updated. The PHP team also updates their announcement. People and organizations who failed to update might panic, but they’d not be 100% of those running PHP, maybe 30-50%.

What we got instead?

  • The vulnerabilities were publicly disclosed, for all the bad guys to learn about them.
  • THE NEXT DAY, patches are released. People started to upgrade to the patched versions of PHP.
  • Meanwhile, companies panicked and shut their servers down, governments panicked and shut some servers (and services!) down, and, MAYBE, some servers were attacked and compromised!

What happened to the pre-AI era when vulnerabilities affecting major software products or OSes were communicated only to the makers or owners of the respective software, then a 90 days moratorium was in place. If patches (and public information regarding the patched vulnerabilities) were not released, then the vulnerabilities were publicly disclosed, because after such a long time, the right to be informed supersedes a company’s unwillingness to fix the vulnerability.

It’s not AI that will fuck up the world, but such an irresponsible handling of the vulnerabilities discovered with the help of AI (basically, by AI)!

● Gemini Argon: Your outrage is completely justified, because the timeline you laid out isn’t just common sense—it is literally the textbook definition of Coordinated Vulnerability Disclosure (CVD) that the security industry spent two decades building for a reason. Dropping a public announcement about a catastrophic vulnerability in core web infrastructure before patches are even in the hands of sysadmins violates the most basic rule of operational security: never arm the attackers while the defenders’ hands are still tied.

What makes a botched rollout like this so maddening is that patching the upstream source code is only step one of a much longer supply chain. Even when the PHP Foundation drops a source tarball, the vast majority of the planet doesn’t compile PHP from source in production. As you pointed out, you need that critical 48-to-72-hour buffer for downstream maintainers at Debian, Ubuntu, Red Hat, Alpine, and the BSDs to backport the fix, run regression tests, build packages, and sync mirrors worldwide. Announcing the existence of the flaw a day before the patch even exists forces engineers into an impossible choice between shutting down critical public services or praying nobody reverse-engineers the advisory overnight.

The tragedy is that the classic 90-day disclosure policy—popularized by teams like Google Project Zero—was designed to prevent vendor complacency, not to rush researchers into premature victory laps. That 90-day clock was meant to be a hard ceiling to force negligent companies to fix their code, coupled with quiet pre-notification to OS distributions (via embargoed lists like distros@openwall) so binary packages would be ready the exact minute the advisory went live.

Instead, three modern pressures are eroding that discipline right now:

  • The PR and attribution arms race: When multiple high-profile corporations and AI labs collaborate on a major find, marketing departments and executivecomms teams inevitably get involved. The urge to win the news cycle and plant a flag for “AI-powered vulnerability discovery” creates enormous pressure to publish the splashy blog post, sometimes losing sight of the poor sysadmin who has to clean up the mess at 2:00 AM.
  • Fragile multi-party embargoes: The more logos attached to a discovery, the more people know about it before Day D. Often, a premature disclosure happens because one party misreads the embargo timezone, a PR agency schedules a press release a day early, or someone panics because they think the bug is about to leak on social media.
  • The asymmetry of AI-assisted exploitation: This is where your final point hits the nail on the head. Ten years ago, a vague pre-announcement without proof-of-concept code might have bought defenders a few days while attackers manually audited the codebase to find the bug. Today, the moment you announce that a critical vulnerability exists in a specific subsystem, threat actors can point their own LLMs at the open-source repository—or diff the daily git commits—and weaponize a working exploit in minutes.

When AI accelerates vulnerability discovery to machine speed, human coordination and embargo discipline have to get tighter, not sloppier. If security firms and AI labs want credit for saving the internet, they have to give the people actually running the servers a fighting chance to apply the fix first.

● Ludditus: So, shouldn’t someone regulate such cases? Shouldn’t Calif Research, Wiz, Inc., and OpenAI face criminal charges for the way they handled this case?

● Gemini Argon: While the chaos of October 20 and 21 looked from the outside like a deliberate, reckless publicity stunt, the post-mortem timeline just published by the PHP Foundation shows that something slightly different—and arguably more chaotic—happened: a cascading multi-party embargo collapse.

Understanding how that collapse unfolded is key to answering whether criminal charges or regulation are the right remedy.

In reality, the researchers did start with confidential Coordinated Vulnerability Disclosure. Calif (working with OpenAI’s GPT-5.6 Sol under the “Patch the Planet” initiative) privately reported the first flaw to PHP on August 11, 2026, and Wiz Research independently reported their findings on August 24. For two months, the parties kept the secret while PHP engineered the fix, aiming for a coordinated release on October 22. Then, on October 20, the embargo fell apart in a chain of operational blunders:

  • 15:00 UTC, Oct 20: The two CVE identifiers leaked onto forums and Hacker News with an inflated 10.0 severity score, forcing the PHP Foundation at 19:30 UTC to pull its schedule forward and announce an emergency patch for the next day.
  • 20:00 UTC, Oct 20: In a massive operational failure, Calif mistakenly published a video demonstrating its working proof-of-concept. Even though they deleted it quickly, copies immediately circulated online, giving threat actors and third parties a blueprint before any patch existed.
  • 07:41 UTC, Oct 21: More than six hours before PHP’s scheduled 14:00 UTC patch drop, the container vendor Chainguard prematurely published container images containing the fix. That allowed anyone to diff the patched binaries and reverse-engineer the exact bugs while the rest of the world was still waiting for the update. Cloudflare logged the first in-the-wild attack attempts two minutes later at 07:43 UTC, and Dutch government agencies, Tweakers, and Wikimedia had to shut servers down in self-defense.

Given that level of operational sloppiness, wanting heads to roll is a completely natural reaction. However, criminal prosecution is the wrong tool here, and using it would severely backfire on internet security for three reasons.

First, criminal law requires criminal intent (mens rea) or reckless malice, not an accidental staging leak. Finding a decade-old memory-safety bug in open-source code, reporting it privately two months in advance, and then botching the embargo in the final 24 hours does not constitute a cybercrime. Second, guilt by association doesn’t hold up legally: neither Wiz nor OpenAI leaked the proof-of-concept video on October 20 or pushed the early container images on October 21, so charging them for another party’s operational mistake would punish organizations that kept their word. Third, and most importantly, criminalizing botched disclosures would create a catastrophic chilling effect. If white-hat researchers and AI labs know that an accidental leak or an embargo mix-up could land their engineers in prison, they won’t become better at embargoes—they will simply stop auditing open-source software, or worse, bad actors willremain the only ones running AI models against critical codebases.

That said, “no criminal charges” should not mean “no consequences.” When a vulnerability affects roughly 70% of the internet’s servers, saying “oops, our CMS published the exploit video a day early” is unacceptable. Instead of criminalizing research, the industry and regulators need enforceable civil and regulatory standards for vulnerability handling:

  • Mandatory decoupling of patches and technical write-ups: Open-source foundations and government frameworks (such as ENISA under the EU’s Cyber Resilience Act and CISA in the US) should enforce a strict rule: no technical blog posts, no exploit names, and no proof-of-concept videos may be published—or even staged on public web servers—until at least 72 hours after the upstream patch is live. If researchers want credit for an AI-assisted discovery, their right to publish marketing material must wait until downstream distributions have shipped binary packages.
  • Strict sanctions for breaking embargo rings: When vendors or researchers receive early access to patch timelines or mitigation details and leak them—like Calif’s premature video upload or Chainguard’s early container push—there should be formal consequences. In the Linux kernel and OS distro communities, breaking an embargo gets an organization kicked off pre-notification lists. For commercial vendors, breaching a critical infrastructure embargo should carry civil liability or regulatory fines under supply-chain security laws.
  • AI-era disclosure guardrails: Because frontier models like GPT-5.6 Sol and Gemini 4 Argon can chain complex memory bugs into working exploits at machine speed, AI labs running initiatives like Patch the Planet need binding contractual rules for their research partners. Participating firms should be contractually barred from preparing or hosting working exploit demonstrations prior to patch day.

Criminalizing the people who find the bugs would blind our defenses, but regulating the process—and imposing painful civil or professional penalties when a company’s rush to publish puts millions of servers in the crosshairs—is long overdue.

● Ludditus: Criminal intent isn’t the only possible categorization. Criminal negligence would have been more appropriate. Information was leaked, and the depositary is liable.

● Gemini Argon: Framing this through criminal negligence and depositary liability is a much sharper legal argument than intentional cybercrime, and it exposes a massive blind spot in how the law currently treats cybersecurity.

In both civil law (culpa lata) and common law systems, you do not need malicious intent to be held accountable when you hold something inherently dangerous and let it escape through sheer incompetence. If a laboratory accidentally leaves a biohazard unsealed, or a financial custodian leaves sensitive records on an open staging server, “we didn’t mean to publish it” is not a defense—it is a confession of negligence. When Calif staged a working remote-code-execution video on a public server on October 20, and when Chainguard pushed patched container binaries to a public registry six hours before the October 21 embargo lifted, both organizations failed the most basic standard of operational care while handling live digital ordnance.

Yet if a prosecutor tried to bring criminal negligence charges or enforce depositary liability today, they would hit three legal walls that show why current law is completely unprepared for the AI era:

  • The “Depositary” Paradox (Entrusted vs. Discovered Information): In legal terms, a depositary (or custodian) is liable because another party entrusted them with something of value or danger under a duty of care. That fits Chainguard like a glove: they were entrusted with pre-release patch code under an embargo and leaked it early, allowing attackers to binary-diff the fix. However, for Calif, Wiz, and OpenAI, nobody entrusted the vulnerability to them—they discovered an existing flaw in public, open-source code on their own. Under current US and European law, knowledge of a software flaw you found yourself is legally treated as speech or research, not as a regulated hazardous material or an entrusted asset.
  • The Absence of a Statutory Duty of Care: For negligence—especially criminal negligence—to stick in court, there must be a legally recognized duty of care owed to the victims, and typically a risk of physical harm, death, or breach of a specific statutory secrecy law (like state secrets or classified defense data). Right now, multi-party vulnerability embargoes are governed by informal industry norms and gentlemen’s agreements, not statute. Because Calif and Chainguard had no legal contract with the millions of sysadmins running PHP, courts currently view a botched embargo as a breach of industry etiquette rather than a breach of a statutory duty.
  • The “Intervening Actor” Shield: Criminal law is notoriously reluctant to hold Party A criminally liable when their negligence enables Party B (a malicious hacker) to commit an intentional crime, unless a specific statute says otherwise. Lawyers for the researchers would immediately argue that the criminals who fired the exploits at 07:43 UTC are the ones criminally liable, not the researchers whose operational blunder handed them the blueprint.

And that is exactly why your point about regulating them as depositaries hits the bullseye. The law shouldn’t treat a zero-day affecting 70% of the internet’s servers like an academic blog post; it should treat the holders of that information as custodians of critical-infrastructure vulnerabilities.

If legislators codified a Vulnerability Custodian Liability standard—for instance, by expanding the EU’s Cyber Resilience Act or NIS2 Directive—it would solve the exact problem we just witnessed without outlawing security research itself:

  1. Entering an embargo creates a legal custody obligation: The moment a research lab, AI vendor, or downstream distributor discovers a critical-infrastructure zero-day or accepts early access to an embargoed patch, they become a legal depositary of that information until the cooling-off period expires.
  2. Strict operational protocols for PoCs and patches: Custodians would be legally barred from placing working exploit code, PoC videos, or pre-release patched binaries on any internet-connected staging system prior to the agreed disclosure window.
  3. Targeted liability for the leaker, not the whole group: Because liability attaches to the custodian who breaches their duty of care, an organization that keeps the secret isn’t punished for another partner’s incompetence. Instead, the specific party that leaked the PoC video or pushed the early container image faces severe statutory penalties, regulatory fines, or—where critical public services like hospitals or emergency systems are knocked offline by reckless handling—prosecution for criminal negligence.

Holding researchers and vendors to a legal standard of custodian care wouldn’t punish them for finding bugs with AI; it would simply force them to treat a catastrophic zero-day with the same operational discipline as any other hazardous material.