The PHP security breach has triggered an urgent global "unplug the network cable" response, don't count on AI to save the Internet.

A terrifying 48 hours for the internet is unfolding right now.

Figure | Source: Wired

Last night, government websites of multiple European countries went offline one after another at around the same time.

The Finnish Transport and Communications Agency shut down some of its online services; the Dutch e-ID system DigiD, the Dutch government's personal service platform MijnOverheid, and all government service portals suspended services. Even the website of the Dutch National Cyber Security Centre itself was temporarily shut down...

In Japan, multiple well-known internet community platforms, including pixiv (Japan's largest illustration, manga and novel submission community), Niconico (Japan's long-established bullet comment video site), and BOOTH (the creator e-commerce platform under pixiv) all announced emergency maintenance.

Even Sushiro announced on its official platform that its mini-program would be suspended today due to system maintenance and upgrade.

What has put so many institutions on high alert are two newly publicly numbered vulnerabilities: CVE-2026-109618 and CVE-2026-109619.

The security community has given them a straightforward nickname PHP2Shell. It means that an attacker can send a single request to your website to get a shell (command line entry) on your server, that is, full control to do whatever they want.

On October 21, the PHP official released emergency updates 8.5.12, 8.4.27, 8.3.36 and 8.2.35, and confirmed at the same time: both vulnerabilities have a CVSS severity score of 9.2 (out of 10), and can be exploited remotely without an account password.

Moreover, under Apache, the world's oldest open source web server software and the most common deployment method for PHP, the attack is triggered before the website's own code even starts running.

The rumor of a "full-score vulnerability" turned out to be true

The opening of this storm was quite dramatic.

According to the original plan, the vulnerability details were supposed to be disclosed in a coordinated manner on October 22. But on the afternoon of October 20, a post appeared on Hacker News claiming that PHP had two remote code execution vulnerabilities with a score of 10.0.

Figure | Source: Reuters

Although the post was deleted soon, the screenshots had already spread. The security company watchTowr came forward to confirm within a few hours that the leak was real, the vulnerabilities were genuine, and they had already reproduced one of them.

The PHP security team issued an emergency warning that night, advancing the release time by 24 hours, and rarely added a sentence: "If the vulnerability details are made public, or evidence of in-the-wild exploitation appears, we reserve the right to further advance the release."

The chaos continued. That night, Calif, the security company involved in discovering the vulnerabilities, mistakenly posted a demo video showing that their attack code ran successfully on multiple real targets, and copies of the video immediately spread wildly on social platforms.

The next morning, Chainguard, a distributor that got the patch in advance, unilaterally broke the non-disclosure agreement and preemptively released the image containing the fix. The patch itself is a "vulnerability map": as long as attackers compare the binary files of the old and new versions to see which part of the code was modified, they can reverse-derive the location and principle of the vulnerability.

In the post-incident review, the PHP Foundation expressed great anger at the way the vulnerabilities were made public.

After discovering vulnerabilities of this level, the industry convention is that researchers, manufacturers and distributors agree on a unified time, and no one is allowed to disclose the details in advance. The purpose is to ensure that patches and vulnerability information reach the public at the same time: users can install the patch immediately as soon as they know about the vulnerabilities, maximizing the time window for defenders.

The affected party is the foundation of the internet

To understand why this incident is so terrifying, you first need to understand what PHP is.

It is the "back kitchen" of the internet. When we log in, search, place orders and leave comments on the front end, PHP processes requests, reads and writes databases, and sends results back to the browser on the server side. WordPress, Drupal, Joomla, Magento, and MediaWiki behind Wikipedia — all run on PHP.

According to data from W3Techs, among websites whose server-side technologies can be identified, 69.3% use PHP; the second-ranked JavaScript accounts for only 8.1%.

We also searched all records containing WordPress in FOFA, the domestic cyberspace mapping search engine developed by Whitecap, and we can see why Europe, America, Japan and other regions responded first: these regions have the largest number of asset entries matching the WordPress fingerprint rule.

In most past news of "PHP websites being hacked", the problem lay in a certain plugin or a certain application. This time the vulnerabilities are located in the core of the PHP interpreter, which has nothing to do with upper-layer applications. In the words of Wiz, one of the discoverers: "Even if your website only runs a Hello World, it will still be affected."

The technical principles of the two vulnerabilities are not new, but what is powerful is that they have been proven to "actually work".

CVE-2026-109618: PHP handles "out-of-memory" conditions in a rude emergency stop manner (longjmp).

If the stop happens at a very subtle moment, the internal data is only half initialized, but the subsequent cleanup process will treat these semi-finished products as normal data for processing, and attackers can use this to make the server execute their own code.

The official has verified: under the default configuration, by constructing a special multipart request to "just exactly" exhaust the memory, the attack can be completed before the application code runs.

CVE-2026-109619: After a request is processed and the memory is released, some global states are not completely cleared.

When the same worker process processes the next request, it may reuse these already invalid memory. This classic "use-after-free" can be carefully stacked into code execution, and can also leak passwords, tokens and API keys of other users in the memory.

It is worth noting that one of the confirmed exploitation paths goes through the session.upload_progress (session upload progress) function, which is enabled by default, and the application does not even need to call session_start().

The fixed versions currently only cover the four PHP branches from 8.2 to 8.5, while the same-day data from W3Techs shows that among all PHP websites, 27.0% still run on PHP 7.x and 7.7% run on PHP 5.x, and these long-discontinued versions cannot get official patches.

Hal Pomeranz, a computer forensics expert, mentioned that "there are too many embedded installations that will never be patched, too many forgotten, unmaintained applications. This time, the long tail will be very long."

AI found it? One week, and several months

As soon as the vulnerabilities were made public, OpenAI published an article listing this incident as part of its AI security achievements: Calif researchers used GPT-5.6 Sol to find the key defects, and multiple teams cooperated to complete verification and response.

As people familiar with the publicity routines of AI companies, we will probably subconsciously ask: Did the model really dig out the vulnerabilities, or did they just put an AI label on human research results again?

On the day of disclosure, Calif publicly "vindicated" on X, stating that Ryan Austin was the first person to discover and create usable attack code, and the evidence was that he sent a tweet containing the discovery hash on August 5.

This is the official technical review written by the first discoverer of the vulnerabilities himself, and it is also one of the most important first-hand materials of this incident.

Ryan emphasized in the article that the initial discovery did not rely on special tool frameworks, nor did it use models that the public could not access. His understanding of the target's history determined where to investigate; simple prompts are still not enough to make the model find all vulnerabilities.

The discovery chain he described traces all the way back to the first PHP memory limit vulnerability found by Stefan Esser in 2004, a neglected bug report in 2020, and an audit in 2024 that failed to prove exploitability.

Figure | Source: https://calif.io/php2shell

The implication is that AI only compressed the verification time, and the sense of direction still comes from humans.

The PHP Foundation's review also confirmed that the OpenAI team independently reported the same root cause on August 11, and later supplemented the attack path. Their article records in detail how the vulnerabilities were discovered and fixed, as well as the full record of the out-of-control disclosure.

Figure | https://the