全球 70% 网站一夜告急，日本首相催打补丁！详解PHP暴雷事件始末
70% of Global Websites in Crisis Overnight, Japanese Prime Minister Urges Patch! Detailed Breakdown of the PHP Outage Incident
Summary
Author｜Dongmei 1 PHP suddenly crashed, affecting up to 70% of global websites. Last night, a security crisis surrounding PHP swept the internet. The US National Security Agency (NSA), the UK National Cyber Security Centre (NC
Last night, a security crisis surrounding PHP swept the internet.
The U.S. National Security Agency (NSA), the UK National Cyber Security Centre (NCSC), and other security agencies have issued warnings, stating that two critical vulnerabilities have been discovered in PHP and urging relevant organizations to implement protective measures promptly.
The NSA further stated that these vulnerabilities are extremely serious, and if a site cannot be patched immediately, it should be taken offline until the fixes are completed. These flaws allow attackers to infiltrate the server’s file system or the databases that web applications may use.
Japanese Prime Minister Kishida Sanae also issued an urgent notice on X to the entire nation, urging the public to take action on the evening of the 21st.
She wrote: “Regarding the PHP used by many websites, the PHP security team has issued warnings about two critical vulnerabilities. Please check whether your publicly accessible sites are using PHP and be ready to apply the fix patch that will be released at 11 p.m. on October 21 (Japan time). If you cannot apply the patch in time, temporarily disabling the site and similar measures can be considered effective ways to reduce risk.”
As a server‑side programming language, PHP is widely used in web applications; statistics show that roughly 70% of websites on the Internet—over 33 million sites—are built with PHP. It is also adopted by popular content management systems such as WordPress.
Subsequently, the PHP team urgently released four security versions, fixing two high‑severity vulnerabilities each rated 9.2.
The storm was triggered by two memory‑safety bugs in PHP’s core, identified as CVE‑2026‑109618 and CVE‑2026‑109619, collectively referred to by the security community as PHP2Shell.
So, what exactly are these two vulnerabilities, and what risks do they pose?
The PHP Foundation explained the principles and impact of the two vulnerabilities in a post‑mortem article released on October 21.
The first vulnerability is CVE‑2026‑109618, which mainly concerns how PHP handles insufficient memory.
In short, PHP needs to use server memory during execution. If a request happens to hit the memory usage limit set by PHP at a certain stage, the program may terminate early, leaving some internal data uninitialized.
The problem is that PHP may later treat this incomplete data as normal, causing memory errors. If an attacker can exploit this error, they could execute malicious code on the server.
The danger of this vulnerability lies in the fact that on servers using Apache and mod_php, an attacker does not need to log into the website to trigger the flaw with a crafted request, and does not even need to wait for the site’s business code to start running. Researchers have demonstrated that, with default configuration, this vulnerability can be used for remote code execution.
In addition, researchers have also verified the possibility of remote code execution in PHP‑FPM environments by exploiting specific application code execution paths.
The second vulnerability is CVE‑2026‑109619, which primarily concerns PHP’s failure to properly clean up memory state left over from the previous request.
Under normal circumstances, after a server finishes handling a request, it should clean up memory data that is no longer needed to prepare for subsequent requests.
However, researchers found that if PHP encounters a severe error at a certain stage, some internal state may not be properly reset. When the same worker process continues to handle the next request, the program may access memory that was freed during the previous request.
This situation is technically known as “use‑after‑free.” It can cause the PHP worker process to crash, affecting website service. When specific exploitation conditions are met, an attacker may also use it to execute malicious code remotely.
Currently, researchers have confirmed that this vulnerability can cause memory errors and process crashes, and they have successfully demonstrated remote code execution in a real‑world environment using Apache mod_php.
Both issues stem from parts of PHP that are used in almost every request: memory management and error handling. Their core role in PHP makes these vulnerabilities extremely serious, and fixing them is also extremely difficult, because a fix could break compatibility, degrade performance, or force the massive third‑party extension ecosystem to change.
How were such serious vulnerabilities discovered?
In fact, these two vulnerabilities are not newly discovered. According to the complete timeline disclosed by the PHP Foundation, early signs of the related memory‑management issues were already identified by human developers as early as 2024. At that time, however, there was no clear exploitation path and the fix involved complex compatibility problems, which caused the issue to remain unresolved for a long period.
According to the security firm Calif, back in 2004 security researcher Stefan Esser from Calif discovered a remote code execution vulnerability in PHP’s memory limit mechanism. At the time the flaw was extremely dangerous, and he did not release a full exploit; subsequently security companies such as CORE and Immunity each developed undisclosed exploit tools.
Stefan Esser posted the email he wrote when he discovered the vulnerability in 2004 on x yesterday.
By 2020, a researcher reported issue #78876 to the PHP officials, pointing out that certain excessively long variables could exhaust memory and prevent temporary files from being cleaned up, but the report did not receive sufficient attention at the time.
In August of this year, multiple security research teams, leveraging cutting‑edge AI models, have successively demonstrated that the related flaw can be exploited by attackers and have uncovered additional attack vectors.
A more detailed timeline starts with an external security audit in 2024.
In 2024, the PHP Foundation received funding from Germany’s Sovereign Tech Agency and organized an external security audit through the Open Source Technology Improvement Fund (OSTIF), carried out by the security firm Quarkslab. This is also the first external security audit of this kind for PHP in many years.
While fixing an issue reported by Quarkslab, a core developer funded by the PHP Foundation noticed that PHP might have an internal state‑management flaw when handling Out of Memory (OOM) exceptions.
Under normal circumstances, PHP performs a series of initialization steps after receiving a request and cleans up related resources when the request ends. However, if memory exhaustion occurs at a critical point, the program may exit prematurely, leaving data structures that were not fully initialized. Subsequent code that continues to use these structures can cause memory corruption.
This turned out to be the root cause of the vulnerability later assigned CVE‑2026‑109618.
At the time, PHP developers theoretically recognized the potential for exploitation but could not identify a concrete attack path, nor prove that an attacker could use it for remote code execution.
But the fix turned out to be far more difficult than imagined.
The PHP security team explored several different approaches, but each came with a cost: some could break compatibility with existing applications, some could introduce new denial‑of‑service risks, and others required extensive modifications with third‑party PHP extensions.
Without clear evidence of exploitation, the security team struggled to decide which cost to bear. Moreover, the number of core developers with deep knowledge of the PHP engine is limited, causing the remediation effort to restart repeatedly and then stall. In a post‑mortem article published on October 21, the delay was described as a “structural failure,” acknowledging that the problem lay not only in the security decision‑making process but also in insufficient maintenance resources.
But the issue can’t just sit there forever without a solution.
To cope with the maintenance pressure caused by the growing number of security reports in the AI era, this May, the PHP Foundation established an ecosystem security team. This team works together with the PHP security team, handling classification, coordination, and hardening of security issues. Team members include tech veterans such as Volker Dusch, Alexandre Daubois, and Daniel Scherzer.
Volker Dusch is a veteran PHP developer with roughly 20 years of experience in the PHP ecosystem. He has contributed to PHPUnit maintenance and PHP language improvement proposals, and was one of the release leads for PHP 8.5. In May 2026, he became the PHP Foundation’s first resident AI security engineer, leading the newly formed ecosystem security team and advancing AI‑assisted vulnerability detection, security report handling, and open‑source project security governance.
Alexandre Daubois is the CTO of the French tech company Les-Tilleuls.coop, familiar with open‑source projects such as Symfony, FrankenPHP, the PHP core, and Scrutineer, and has extensive experience handling software security issues. He joined the PHP Foundation in July 2026, primarily assisting in classifying, validating, and fixing security vulnerability reports, alleviating the pressure caused by the surge in report volume after AI tools became widespread.
Daniel Scherzer is a PHP core contributor, responsible for maintaining PHP’s Reflection extension, and serves as the release manager for PHP 8.5 and senior release manager for PHP 8.6. In September 2026, he joined the PHP Foundation’s ecosystem security team as a short‑term member, focusing on code issues that do not yet constitute formal security vulnerabilities but help improve PHP’s security and stability.
Security research firm Calif was invited to participate in OpenAI’s “Patch the Planet” initiative and decided to target PHP, which is widely used on the Internet, for auditing.
On July 30, Calif officially launched the research and contacted Volker Dusch of the PHP Foundation through security expert Stefan Esser, promoting collaboration between the two parties.
Calif disclosed that the team originally did not expect to easily find a critical vulnerability, as PHP has already undergone extensive security audits. However, after re‑examining previously identified issues and using Stefan Esser’s historical research for clues, the team discovered a severe memory exhaustion vulnerability within a few days and identified a remote code execution chain that could be used to attack WordPress sites. Subsequently, the researchers continued to look for other exploitation methods and uncovered attack vectors applicable to Apache mod_php and PHP‑FPM environments.
On August 11, a key breakthrough occurred. Calif researcher Ryan A reported to the PHP security team an attack vector that enables remote code execution, whose root cause happens to be the memory exhaustion issue discovered by PHP core developers in 2024.
On the same day, OpenAI also independently reported the same vulnerability root cause.
According to OpenAI’s official statement, Calif used GPT-5.6 Sol during its research, leveraging this model to discover a critical security flaw.
Based on this explanation, the facts are essentially clear: GPT-5.6 Sol was merely a tool used to uncover the vulnerability, not the primary entity that first noticed the issue, and it does not mean that both vulnerabilities were independently discovered by ChatGPT without any human involvement.
At the same time, Google’s security company Wiz is also conducting independent vulnerability research.
In its official technical recap, Wiz disclosed that its team used the Wiz Atlas security agent, Gemini 4 Argon, and GPT-5.6 Sol on August 19 to discover the first PHP security vulnerability.
On August 20, Wiz confirmed that unauthenticated remote code execution could be achieved in a Drupal environment; on August 21, it verified the same level of attack impact in a WordPress environment.
On August 24, Wiz formally reported the vulnerability to the PHP security team.
Wiz’s research team includes Sagi Tzadik, Shir Tamari, Nir Ohfeld, and Tomer Schwartz, among others. According to the team’s disclosure, Gemini 4 Argon played a particularly important role in the vulnerability discovery and remediation assistance process.
Similar to Calif’s findings, Wiz did not simply locate an easily identifiable erroneous line of code; instead, it focused on PHP’s exception handling, object lifecycle, and cross-request memory state, further demonstrating that these underlying flaws can lead to real-world attacks.
Wiz’s technical analysis shows that its research covers four exploitable defect instances, which are categorized under CVE-2026-109618 and CVE-2026-109619. These include use‑after‑free triggered by session upload progress deserialization, in‑process memory leaks, use‑after‑free in fatal error backtrace handling, and OPcache type confusion issues.
Wiz also combined the related attack techniques into an exploit demonstration called PHP2Shell, validating unauthenticated remote code execution risks in real‑world environments such as WordPress, Drupal, and Joomla.
However, these applications were merely the verification targets chosen by the researchers; the vulnerabilities themselves reside in the PHP engine and are not unique security flaws of WordPress, Drupal, or Joomla.
Subsequently, on September 18, OpenAI reported a new attack path, further augmenting the security team’s understanding of the underlying defects.
From this we can see that the breakthrough in the summer of 2026 was not achieved by a single company alone. Calif was the first to report a serious remote code execution path that shares the same origin as the known issue from 2024, OpenAI independently reported the same root cause on the same day and later added new attack vectors, and Wiz independently discovered and validated multiple related exploitable issues.
These research findings ultimately convinced the PHP security team that the memory safety flaw, which previously lacked clear exploitation evidence, can indeed lead to severe server compromise risks.
The PHP Foundation stated that, starting on August 11, fixing the related memory management issues became the top priority for the entire security team. Multiple engineers have devoted full‑time development effort and continue to coordinate with research teams such as OpenAI, Calif, and Wiz, with some work even extending into weekends and nights.
In the end, after about two months of coordinated fixing, the PHP project released four security versions—PHP 8.5.12, 8.4.27, 8.3.36, and 8.2.35—on October 21, patching the critical CVE‑2026‑109618 and CVE‑2026‑109619 vulnerabilities.
Looking back at the whole process, AI’s actual contribution was not, as many media outlets claimed, autonomously finding the bugs and fixing them; rather, it helped security researchers discover and validate complex exploitation paths, turning a long‑standing underlying flaw from a theoretical risk into a high‑severity vulnerability that required immediate remediation.
Wiz noted in its technical report a representative observation: the root cause of the related vulnerabilities has existed for over a decade, and the real difficulty lies in constructing a complete, reliable exploitation path. In the past, this work might have required a top-tier security team to spend months; today, with cutting‑edge AI models and appropriate research tools, a researcher can potentially complete a similar task within a week.
On the same day the PHP team released the patch, external researchers also began independently reproducing and analyzing these vulnerabilities.
On October 21, security researcher Qi Deng published a technical article on Substack titled “PHP2Shell: Dissecting a Critical PHP Vulnerability,” detailing his analysis of the PHP source code and the vulnerability verification process.
Qi Deng said he spent about 24 hours setting up the test environment, reviewing the PHP source line by line, and attempting to construct an exploitation path from scratch.
The article claims that during the research, five potential remote code execution paths were discovered, including attack ideas not present in previously leaked PoCs.
The most noteworthy part of the article is the two mechanisms directly related to the official vulnerability.
Category one: memory exhaustion causing PHP to enter the cleanup process before initialization is complete.
Under normal circumstances, when an HTTP request arrives, PHP needs to initialize the execution environment, parse input data, execute application code, and clean up resources when the request ends.
However, Qi Deng discovered that in an Apache mod_php deployment, request body parsing may occur before the application code is executed. If a request triggers an out‑of‑memory condition at this stage, PHP will exit the current execution flow using a non‑local jump mechanism such as longjmp().
The problem is that this abnormal exit can skip some normal initialization steps.
Subsequently, Apache mod_php still proceeds with request shutdown and resource cleanup, but at this point some internal state has not been properly initialized, causing the cleanup code to potentially access invalid memory.
Qi Deng demonstrated in experiments that after memory exhaustion occurs, the program still proceeds to the exception cleanup path.
The official PHP security advisory further confirms that this issue, under specific conditions in Apache mod_php, can achieve remote code execution without authentication in the default configuration, and the attack can occur before the application code actually runs. This means that even if the site itself has no obvious business‑logic vulnerabilities, runtime‑level security risks cannot be ruled out.
Category 2: The abnormal state of a previous request may affect a subsequent request.
Another vulnerability involves PHP’s handling of global state. Deployment methods such as PHP‑FPM typically use long‑running worker processes to handle multiple requests. Ideally, after each request finishes, the associated memory and state should be properly cleaned up or reset.
However, when a request encounters a fatal error, runs out of memory, or aborts abnormally, the normal state‑reset process may be skipped.
If a global pointer still points to memory that was freed by a previous request, subsequent requests that access it can cause a use‑after‑free issue.
Qi Deng used the GDB debugger to observe the order of PHP request initialization and session deserialization, and demonstrated how the state left by an abnormal request was read by later processing logic.
This type of issue is hard to detect because testing a single request in isolation may not trigger the full vulnerability. The problem only becomes apparent when two requests enter the same worker process in a specific order, and the first request leaves behind an abnormal state.
From this technical analysis we can see that the common characteristic of this security issue is: after an abnormal termination, the memory and execution state between different PHP modules may no longer be consistent. In complex software, such problems are often not as obvious as traditional input‑validation vulnerabilities. They may be hidden across multiple functions, multiple requests, and different resource lifecycles, which makes them a noteworthy application scenario for AI‑assisted security research.
This PHP vulnerability incident also raises a question: to what extent has AI changed the traditional approach to vulnerability hunting? Has it achieved breakthrough progress, or has it merely made past automated security research more efficient?
Experts from the 360 Vulnerability Research Institute told InfoQ that this incident can be seen as a validation of the “expert experience × general large model” collaboration model. It demonstrates that large models’ ability to understand code semantics is helping security researchers overcome some limitations of traditional vulnerability discovery methods.
The experts believe that the difficulty of this PHP vulnerability does not lie in finding an isolated memory error, but in understanding the complex state changes across different requests. Researchers need to determine when the program completes initialization, under what circumstances it may be abruptly interrupted, and how the state left after interruption affects subsequent execution. Only by linking these steps can one assess whether an apparently ordinary program exception can actually be exploited by an attacker.
Traditional security analysis tools have certain limitations when dealing with these kinds of issues. Fuzzing mainly generates a large number of test inputs to find anomalies, but it may not effectively cover vulnerabilities that require multiple conditions to be triggered consecutively; static code analysis is better at identifying known dangerous patterns, yet it can miss complex logical problems that span modules or requests. Manual code review can incorporate experience for judgment, but it is constrained by code size, review time, and the researchers’ energy.
In contrast, large models can start from the meaning and execution logic of the code, correlate the relationships between different files and modules, and help researchers identify potential abnormal execution paths.
However, experts especially emphasize that the fact AI can deeply analyze code does not mean it inherently knows where to start looking for vulnerabilities.
“In this study, the discoverer first relied on historical experience with the 2004 Esser series memory‑limit remote code execution vulnerability, clarified the research direction, and then used a large model for deep analysis, finding within days a deep vulnerability that had previously passed manual security review but still existed.”
According to experts, the most important value of AI in this process is helping researchers connect information scattered across different modules, shortening the time needed for vulnerability verification.
“Looking at an isolated anomaly, it might just be a program crash or resource exhaustion; to prove it is exploitable, you must chain together the execution order, state residues, and subsequent requests across different modules for analysis.”
He believes AI can leverage code comprehension and associative reasoning to combine these dispersed clues into a verifiable attack path.
“The most intuitive point of this case is that AI accelerates the speed from ‘discovering anomalies’ to ‘proving exploitability.’”
However, the analysis results presented by AI are not necessarily correct. Experts point out that large models may generate vulnerability hypotheses that appear reasonable but are actually untenable. For complex vulnerabilities, the attack path often consists of multiple stages, and any error in reasoning can cause the final conclusion to be invalid.
Therefore, after the model proposes a vulnerability hypothesis, security researchers still need to verify it through code review, dynamic debugging, and real-world testing.
“The model provides a vulnerability hypothesis that needs verification, not an inherently valid security conclusion.”
In his view, a more feasible technical approach is not to let large models completely replace traditional security tools, but to combine them with fuzz testing, static analysis, dynamic verification, and manual auditing, forming a complete process from identifying suspicious points to confirming vulnerabilities.
As AI becomes involved in increasingly complex vulnerability research, another question arises: if defenders can use AI to quickly find vulnerabilities, can attackers also leverage the same technology to discover and exploit software flaws more rapidly?
360 experts believe this shift has already begun.
From a technical standpoint, large models can help users understand the principles of complex vulnerabilities, analyze trigger conditions, and write test code to verify those vulnerabilities. Tasks that previously required long‑term accumulation of expertise can now be tackled with AI, reducing the difficulty of operation.
At the same time, AI is also changing how personnel are allocated in vulnerability research. Work that once required multiple people—such as code analysis, mapping call relationships, and risk assessment—can now be handled largely by a single researcher with AI assistance.
However, this boost in capability does not automatically make the network more secure.
360 experts believe that, in the short term, attackers may find it easier to profit from the proliferation of AI. This is because attackers typically only need to find a single weak point that can bypass defenses, whereas defenders must continuously protect a large number of systems and ensure the security of various components, versions, and runtime environments.
“In the short term, attackers indeed reap the benefits more easily: they only need to find one viable breakthrough, while defenders have to continuously protect numerous systems.”
However, he also believes that this shift does not necessarily put defenders at a disadvantage. Enterprises and security teams can also leverage AI to accelerate code review, vulnerability verification, risk assessment, and patch testing.
“The key is not who has AI, but who can apply AI capabilities to real-world scenarios faster.”
In fact, AI‑assisted vulnerability hunting has already begun to become part of everyday security work in enterprises. Experts observe that more and more companies are trying to introduce AI agents into code review and vulnerability research processes. In the past, an in‑depth manual code audit could take days or even weeks, with researchers gradually mapping code structure, function call relationships, and potential risks. Now, some preliminary analysis can be handed over to AI, allowing security experts to spend more time on judgment and verification of complex issues.
However, whether enterprises truly achieve higher vulnerability detection rates, lower false‑positive rates, and better ROI still needs to be evaluated against actual test results. Especially for complex low‑level memory bugs, spotting suspicious code does not equate to confirming a security risk; verification and remediation still require professional engineering expertise.
This recent PHP vulnerability incident illustrates exactly that.
AI has not diminished the value of security experts; instead, it enables researchers’ accumulated historical experience, vulnerability knowledge, and code comprehension to be transformed into actual discoveries more efficiently.
Regarding future security research, experts’ assessment is: “The experiential judgment of security experts and the analytical capabilities of large models are not mutually exclusive; they are forming a new collaborative approach. Experts’ knowledge and experience are being turned, via large models, into stronger vulnerability discovery capabilities.”
Reference links:
https://www.youtube.com/watch?v=cE4h79AWbT4
https://www.wiz.io/blog/php2shell-php-rce
https://openai.com/zh-Hans-CN/index/coordinated-disclosure-of-critical-vulnerabilities/
https://thephp.foundation/blog/2026/10/21/todays-php-security-release-and-how-were-strengthening-php-security/
https://assets.theregister.com/2026/10/21/202622/
https://www.theregister.com/security/2026/10/21/php-devs-publish-critical-bug-fix-as-site-owners-warned-pull-em-offline-if-youre-unpatched/5304519
Disclaimer: This article is original content from InfoQ,does not represent the platform’s views, nor does it constitute investment advice; reproduction is prohibited without permission.
AI turns the entire software ecosystem into a sieve, the darkest moment for full‑stack developers
Can’t release PostgreSQL 19? AI “nitpicking” too fast, humans can’t keep up fixing bugs
Get MirrorSpeed
Get MirrorSpeed