PHP2Shell: AI Found the Memory Bugs Days Before the Patch, and Attackers Were Already Exploiting Them

When the urgent update notice arrives, the attack has already begun

Opening PHP's security advisory for October 21, 2026, the headline contains two words: update now.

Update immediately.

Read further, and two core vulnerabilities can let an unauthenticated attacker execute code on the server. PHP officially notes that a mod_php exploit demonstration can trigger the attack before business code begins running. Authentication checks and permission checks haven't executed yet at that point.

The people maintaining websites have to first confirm whether the PHP carrying that code has been patched. PHP official advisory

But external requests won't wait for the update to finish.

Cloudflare CEO Matthew Prince said that within the first ten hours after the advisory, Cloudflare's network saw thousands of exploitation attempts; within 45 minutes after the advisory, tens of thousands; within two hours, hundreds of thousands, eventually rising to millions. 404 Media's coverage cites these figures.

The numbers count exploitation attempts, including blocked requests, and cannot be converted into a count of successful intrusions. Cloudflare's observations also do not represent a complete tally of the entire internet.

Even so, two hours is enough to make people reconsider whether security updates can continue to be scheduled slowly.

I re-checked the original reports from researchers and maintainers. This time, the most pressing question is no longer just whether AI can find vulnerabilities.

Why did a long-standing problem become an emergency now? Defense teams had prepared in advance, so why, at the time of public disclosure, do websites still need to race against the clock?

Let me put several parallel threads together: researchers finding the issue, maintainers coordinating the fix, external exploitation, and public disclosure do not all happen on the same timeline.

The timeline nodes in the image are compiled from the original materials cited below, as of October 23, 2026; node spacing does not represent actual durations, and the sequence does not necessarily indicate confirmed causal relationships.

The risk of PHP2Shell can't be measured by the number of vulnerabilities alone

PHP2Shell is the collective name for CVE-2026-109618 and CVE-2026-109619. The issues sit in the PHP runtime, involving uninitialized data and freed memory being reused after memory exhaustion or fatal errors.

This layer is what's fixed. Updating only plugins or changing business code on top does not cover the problem.

Wiz's research report says affected versions trace back to PHP 5.4, and virtually every PHP version released in the last decade is affected by at least one of the two issues. The research team also demonstrated a path that reads passwords, tokens, and API keys from process memory without needing remote code execution. Wiz research report

So, focusing only on whether the server has had commands executed may also miss information disclosure.

It's also important to be clear that PHP is widely used and this cannot be written as an equal percentage of all websites globally being compromised. Actual risk depends on runtime version, deployment method, exploitable paths, and defenses. A researcher's successful demonstration does not mean every environment can be penetrated with the same program.

It is precisely this last point that makes AI's role concrete.

What AI changed, from discovering the issue to building a working exploit

OpenAI confirmed that Calif used GPT-5.6 Sol within the Patch the Planet program to find a critical vulnerability, and Wiz independently discovered and reported both vulnerabilities. PHP maintainers led the fix and release, with partners providing research, technical support, and coordination. OpenAI incident statement

Screenshot from OpenAI's official Chinese version, captured on October 23, 2026.

Wiz detailed the difficulties in its research process more clearly. Complex memory vulnerabilities require chaining multiple issues, and encountering different PHP versions, configurations, and memory layouts demands re-testing and debugging. Wiz said the research used Wiz Atlas, Gemini 4 Argon, and GPT-5.6 Sol; the models helped the team adjust the exploit program, analyze failures, and iterate verification, reducing the professional effort required for cross-environment adaptation.

This is more noteworthy than a blanket statement that AI found the bug.

In the past, even when a flaw existed, complex exploitation conditions could limit its real impact. When analysis, debugging, and adaptation become easier, that limit weakens. This is Wiz's assessment of the research and explains why counting only the number of vulnerabilities misses the full scope of this change.

However, the research team openly using models to develop exploits is a different thing from every attacker on the internet using AI. The latter cannot be inferred from request counts.

Why the fix was slow, and why disclosure was moved up

The PHP Foundation's retrospective fills in the maintainer's side of the story. After the 2024 audit, the team had found early signs of the OOM issue, but at the time there was no clear remote code execution path. Several fix approaches ran into compatibility issues, denial-of-service risks, and extension adaptation, compounded by staffing and decision-making constraints. Work repeatedly stalled. The Foundation acknowledged this as a structural failure. PHP Foundation retrospective

I think this explanation is important. Seeing a serious vulnerability go unfixed for years, questioning is reasonable; but to truly improve response, you need to know whether it got stuck on technical tradeoffs, decisions, or resources.

Maintainers also face another reality. The patch modifies memory management and error-handling logic that many requests pass through; fixing it also must preserve compatibility, performance, and the extension ecosystem. After a reliable exploit is found, both upstream fixes and downstream preparation still have work to do.

Calif's research log places the audit start on July 30, with early findings recorded on August 1. The team continued searching for more variants afterward. Calif research log

This shows early progress was rapid, but it cannot be flattened into "discovered in two days, spent two months writing a patch." Confirming impact, hunting variants, validating the fix, and coordinating distribution are distinct stages.

Before the release, the coordination process was disrupted.

According to the PHP Foundation, on October 20 the CVE numbers leaked early, accompanied by an incorrect 10.0 severity score; the actual score is 9.2. PHP moved the release from the 22nd to the 21st. Distributors were still packaging, and an immediate public disclosure would leave many users without a convenient update path. A mistakenly released demo video later added to public information.

Moving up one day is a compromise between speed and update availability. The more people need advance notice to prepare defense, the harder confidential coordination becomes.

Early discovery and pre-disclosure exploitation can happen simultaneously

AWS's MadPot telemetry recorded a PHP2Shell exploitation attempt on October 17, four days before public disclosure. The source IP was associated with a commercial anonymizing network; AWS believes it may come from a threat actor, but it is not yet clear how the party obtained the exploit information. AWS telemetry statement

Chinese translation, not an official version. Made from the AWS official English text above, original verified on October 23, 2026.

OpenAI says that, to its knowledge, frontier AI discovered the vulnerability earlier than attackers. This does not necessarily conflict with AWS's record.

One compares the timing of researchers versus attackers; the other records activity that appeared before public disclosure. Researchers knowing in advance does not guarantee that no one else found it during the entire embargo period.

There is one timing relationship that cannot be reversed. The October 17 exploitation attempt precedes the October 20 leak recorded by the PHP Foundation. The later leak cannot directly explain the earlier request; whether other information leaked or an independent discovery occurred cannot be concluded from this alone.

So what those four days most change is the investigation starting point.

After the patch is installed, old logs still need to be examined. Relevant requests may have already reached the server; abnormal files, unfamiliar processes, and outbound connections that should not exist do not automatically vanish when the version number is updated.

Advance protection buys time, but cannot replace actually patching

Advance preparation has value. Cloudflare says its related WAF protection began preparation in early October and was enabled by default on October 21 at 03:02 UTC, which is 11:02 Beijing time, for customers using free or paid WAF. Cloudflare protection report

Chinese translation, not an official version. Made from the Cloudflare official English text above, original verified on October 23, 2026.

When the origin server has not been upgraded, the traffic entry gets a layer of protection first; this is where the time gained from early discovery can work.

But did the main domain go through WAF while the origin can still be reached directly? Are the backend domains and test environments also behind the same layer? A request log from one entry cannot guarantee the other entries.

The NSA's official advisory states the requirement more directly: inventory all services that depend on PHP and apply patches as soon as possible; if it cannot be updated immediately, take it offline until the risk can be sufficiently mitigated. NSA official advisory

Taking the service offline here is a measure to reduce exposure and cannot be treated as evidence that the service has already been compromised.

Cloudflare and AWS also still require updating PHP. WAF is additional protection; complete remediation lands on the runtime. AWS mitigation guide

Next time you get an update notice, how to confirm the system is actually fixed

As of October 23, 2026, the date I verified the materials, the patched versions listed in the PHP advisory are 8.2.35, 8.3.36, 8.4.27, and 8.5.12. Users on older branches need to confirm vendor backport patches or migrate to a supported version. When backport fixes exist, judging safety only by the upstream version number is not enough.

Typing php -v once shows only the binary that command calls. You still need to confirm whether the PHP-FPM or mod_php that actually receives requests has loaded the patched version. If a container image was updated, were all replicas replaced? If the package was installed, were workers restarted? That requires actual verification.

For me, this event translates into three actions.

Find all affected instances; those responsible, software packages, or image digests must be mapped.

Verify coverage of all reachable entry points, confirm that service processes have been updated, and ensure critical business still runs.

Start a retrospective from the earliest known exploitation time; check logs and host indicators, and if there are signs of an intrusion, continue following the incident response process.

OpenAI also provides a PHP version checker Codex skill. It can assist with inventory, but a version check cannot prove the system is not already compromised, nor does it replace verifying vendor backport patches and running process verification.

Specific configuration should still follow the complete PHP and vendor guides. Merely copying a single parameter to disable memory limits, while missing resource isolation and residual risk conditions, can create new problems.

After Black October, how should AI security capabilities be evaluated

404 Media discusses PHP2Shell in the context of a series of recent security incidents and uses the term Black October to describe unease in the security community. That is a generalization of a set of events and industry sentiment; it cannot be used to attribute every incident to AI, nor should it be treated as the name of a unified attack.

PHP2Shell provides evidence that is already specific enough. AI-assisted research can accelerate verification of complex problems, maintainers still have to handle fix tradeoffs, disclosure can still go off course, and the sites at the end still have to complete deployment.

Looking back at the initial update now, I prefer to understand it as a series of actions that need to be completed. Confirm the risk, prepare the update, find the instances, replace the processes, and verify the actual result.

I think evaluating AI security capabilities beyond counting how many vulnerabilities it finds should also ask: how many systems did these findings ultimately get protected in time?

When the next emergency advisory arrives, can a team say clearly which services need updating and how they have proven those services are fixed? That verifiable result is the protection early discovery can hand to users.

Materials and original reports

Access materials and full report images

Event threads reference the related topic collection; key facts are verified against original materials. Primary references include Wiz research report, PHP Foundation retrospective, Calif research log, NSA official advisory and 404 Media coverage.

Technical details and full context are preserved below for readers who need to verify further. PHP, AWS, and Cloudflare images are Chinese translations, not official versions; the OpenAI image is from the official Chinese version. All images are high-resolution lossless PNGs; the original verification date is October 23, 2026.

PHP security advisory original text, including vulnerability numbers, patched versions, affected deployments, and limitations of temporary measures.

OpenAI's official Chinese report, image 1 shown in the main text, images 2 through 6 retained below.

AWS telemetry report original text, explaining pre-disclosure activity, observation limitations, and investigation recommendations. Chinese translation image appears in the main text.

Cloudflare protection report original text, explaining WAF deployment time, rule coverage, and continued patching requirements. Chinese translation image appears in the main text.