AI Says Code Has No Vulnerabilities? PHP Just Slapped It Down

A few days ago, a critical PHP vulnerability sent the entire internet into chaos, and even Takaichi was rattled.

Government websites in several European countries went offline one after another around the same time. The Netherlands' digital identity system and personal government portal were shut down in an emergency. In Japan, major platforms successively posted maintenance notices. Even going out for a meal at Sushiro, customers were told the phone mini-program was suspended for system upgrades. One cabinet official issued an urgent late-night post, calling on everyone responsible for operations to respond tonight at all costs: if a site genuinely cannot be patched in time, even unplugging the network cable and stopping service temporarily is a necessary measure to reduce risk.

The two vulnerabilities, called PHP2Shell by the security community, are CVE-2026-109618 and CVE-2026-109619, with a CVSS score of 9.2. Under default configurations, unauthenticated external requests can trigger underlying exceptions through specific parameters and gain execution privileges on the server.

Coincidentally, in the days around the vulnerability disclosure, technical discussions about AI code verification were also very active.

OpenAI publicly boasted that its latest frontier model participated in the discovery of critical vulnerabilities, listing it as a major achievement of its security program. In the open-source community and academia, Anthropic's just-released technical research also drew widespread praise; the paper claims AI can now generate formal proofs for open-source codebases that pass verification by independent checkers. In many people's imagination, AI is eliminating mistakes made by human programmers at unprecedented speed, and a new era in which code no longer has vulnerabilities seems within reach.

Yet on one side sits ideal code in Silicon Valley labs, mathematically proven to be airtight, and on the other side, in the real world, large numbers of critical websites are frantically pulling the network cable and cutting themselves off to survive.

What the incident proves: even if application-layer code passes strict unit tests, static analysis, or even formal proof, once the underlying interpreter that carries the code has a defect, the system is still at risk of being directly compromised.

Reviewing the Vulnerability Discovery and AI's Actual Role

In the early days of disclosure, some technical marketing tended to emphasize large language models' automated performance in security research. But after the security researchers involved in the discovery and review published technical details, the whole process showed a more rigorous engineering picture.

The person who first found the vulnerability and wrote a usable attack proof was actually an independent security researcher, Ryan Austin. As early as early August, he had posted a clue containing a discovery hash on social platforms. In his later retrospective post, this front-line researcher specifically stressed that the initial discovery did not rely on any special tool framework, let alone a magical model inaccessible to ordinary people.

What actually determined the vulnerability's discovery was decades of accumulated knowledge about the target's underlying history. The researcher's clues traced all the way back to a memory-limit flaw publicly recorded in 2004 and an under-appreciated issue report from 2020. These historical records formed the main direction of the investigation.

In this process, AI mainly took on the work of accelerating verification. In traditional security research, turning a theoretical memory flaw into a stable and reliable verification script usually takes researchers weeks of repeated debugging. With the assistance of large language models for analysis, this verification cycle was shortened to within a few days.

This division of labor reflects the real position of current technology. Research direction and intuition depend mainly on human understanding of system history and code context; the model significantly improves the efficiency of information retrieval and code verification.

It should be noted that as the barrier to exploit verification drops, the time pressure on defenders rises accordingly. Once a vulnerability patch is public, the cost of reverse-analyzing the fix and extracting attack characteristics drops sharply, and the window left for system maintainers to investigate and upgrade becomes more urgent.

Interpreter Kernel Defects and the Verification Blind Spot

In the past, the vast majority of website compromise incidents were caused by business code in the upper application layer. For example, a programmer omitted an input filter, allowing attackers to pass malicious SQL statements into the database; or failed to check the file extension when handling uploads, allowing Trojan files to be stored on the server.

The reason this vulnerability drew so much attention is that its trigger point is not in application-layer business logic, but in the underlying kernel of the PHP interpreter.

According to W3Techs statistics, among websites with a known server-side development language, about 69% still use PHP to run services. In a typical deployment architecture, the web server receives a request and passes data to PHP-FPM via the FastCGI protocol; the underlying interpreter implemented in C handles memory allocation, request parsing, and code execution.

The two high-risk vulnerabilities are buried directly in the C implementation of the PHP interpreter kernel. In other words, even if your website does nothing but print a line of "Hello World", it cannot escape direct compromise.

CVE-2026-109618 is related to the memory exception handling mechanism. When a request hits memory exhaustion during processing, the underlying layer uses an interrupt jump (longjmp) to terminate execution. If this happens while some internal data has not yet been fully initialized, the subsequent memory cleanup routine treats the uninitialized data as a valid object, providing attackers with a path to execute specific instructions. CVE-2026-109619 involves state residue after a variable scope is released: memory left unclean from the previous request is reused by later requests, creating risks of data leakage and even alteration of the execution flow.

Looking at the request-handling path, external malicious payloads start affecting the interpreter during the web server and FastCGI protocol parsing stage. Because the defect occurs before the application script is read and executed, no matter how the upper-layer business code is written, it cannot block abnormal state in the underlying runtime.

The Engineering Boundary of Formal Proof

This is precisely why the current celebration around AI formal proof looks particularly awkward in real operations.

In its technical appendix, Anthropic discusses methods for using large models to assist in generating proofs, showing the rigor of mathematical specifications in investigating logical boundaries. In Hacker News technical discussions, many developers appreciated the progress of deterministic verification, but also focused on its applicability boundaries in large-scale engineering.

The various quality assurance methods in software engineering have a clear division of labor.

• Unit tests verify expected output against fixed examples.

• Property testing introduces random inputs to investigate boundary anomalies.

• Formal proof uses mathematical logic to derive whether a function satisfies its specification.

These verification methods all focus on the logical consistency of the application code itself. During the derivation, they presuppose an ideal premise: the hardware, operating system, standard library, and language interpreter executing the code fully conform to specifications, with no unexpected side effects.

In production, that ideal state does not exist. A formal proof can confirm that a payment deduction function has no logic flaws at the algorithm level, but it cannot guarantee that the PHP interpreter will not overflow memory when allocating. Correct derivation of application-layer code cannot replace security verification of the underlying runtime environment. This is a principle often cited in the security field: proof-checked is not deployment-verified.

As long as the C-language runtime underneath has cracks, passing a pure code-level proof never equals production deployment safety. Mistaking flawless code logic for an impregnable whole system is the biggest blind spot of today's technical teams.

The Long Tail of Legacy Systems and the Patching Reality

Facing such a high-risk bug, the most natural call is often just two words: upgrade.

But for the millions of teams actually keeping their businesses running, it is easy to say and very hard to do.

Public statistics show that among existing PHP sites, about 65% run on the PHP 8.x branch. Of the rest, about 27% still use PHP 7.x, and about 7% run PHP 5.x. These two older categories reached end-of-life (EOL) years ago.

The official fixes released for this vulnerability cover only four active branches: 8.2, 8.3, 8.4, and 8.5. That means roughly one-third of the world's existing PHP sites cannot directly receive an official security patch.

For the companies maintaining these systems, jumping across major versions often comes with a high cost of rework. Old projects usually depend on deprecated syntax features or outdated extension components; upgrading the interpreter rashly can make business code fail immediately. Within a limited time, tearing everything down and rewriting is neither realistic nor free of new uncontrollable risks.

At this critical moment, telling these companies to start over with a refactor, or hoping AI can rewrite hundreds of thousands of lines of old code overnight without damage, is pure fantasy. Faced with this situation, the more feasible engineering approach is to maintain major-version compatibility while adding the necessary backported patches to the underlying runtime environment.

Building Runtime Determinism

Handling this kind of low-level security update requires extending focus from single code tests to a complete evidence chain that includes runtime, service configuration, and process state.

In development and multi-version maintenance, a local integrated development environment like ServBay made a major contribution this time.

For this vulnerability, ServBay not only synchronized fixes for the mainstream PHP 8.x branches at the earliest opportunity, but also provided backported security patch support for old PHP versions that have ended official maintenance, including the 7.x and even 5.6 branches.

This approach gives teams maintaining legacy systems a pragmatic buffer. Developers do not need to take the risk of rewriting code; they can update the interpreter package containing the fix under their original major-version branch, eliminating the hidden danger in the underlying runtime.

At the same time, with a per-project mechanism for independently binding the PHP version, different sites can run in their own isolated environments based on their dependencies. New projects can use the latest PHP version, while old systems stay pinned to a patched old version, avoiding the problem of global environments interfering with each other. While developers use AI to write code or run tests, the underlying infrastructure can provide a runtime base with clear versions and transparent configuration, putting upper-layer logic verification and lower-layer environment security in their proper places.

Summary

AI technology in the security field has indeed improved the efficiency of vulnerability discovery, auxiliary analysis, and logic proof. But the development of tools has not changed the objective laws of basic software engineering.

The self-consistency of code logic is always built on the stable operation of the underlying interpreter. Facing severe defects at the bottom layer like CVE-2026-109618, relying solely on upper-layer code testing or mathematical proof is not enough to eliminate risk. Acknowledging the boundaries of verification methods, combining controlled and reproducible infrastructure, and promptly applying security patches to both active and legacy systems is the solid path to keeping services stable.