From PHP2Shell to Node.js: How AI Is Changing Software Security

PHP2Shell: AI-assisted research finds flaws in a foundational runtime

On 21 October, the PHP project disclosed CVE-2026-109618 and CVE-2026-109619, two vulnerabilities in PHP request handling. Under affected conditions, an unauthenticated remote attacker could trigger memory corruption and potentially execute code in the context of a vulnerable PHP process. Because the weaknesses sit in PHP itself, applications may be exposed even when their own code is not defective.

Red Hat’s advisory describes CVE-2026-109618 as a failure-handling problem during request parsing. If memory allocation fails, PHP does not fully roll back incomplete state, and later cleanup can operate on uninitialized memory. Wiz Research describes several exploitable cases across the two CVEs, including a use-after-free issue and OPcache type confusion. Its researchers combined the weaknesses into an exploit and demonstrated it against current container images of WordPress, Drupal, and Joomla. Those demonstrations show why a flaw in a shared runtime can matter to applications whose own code is not responsible for the bug.

Wiz says its researchers used Wiz Atlas, Gemini 4 Argon, and GPT-5.6 Sol during the investigation. The team’s account credits AI with a substantial contribution to finding and helping remediate the vulnerability, while also describing human research, exploit validation, and coordination with the PHP security team. The report dates discovery to 19 August, reporting to PHP to 24 August, and public fixes to 21 October.

The PHP2Shell investigation is evidence of AI contributing to security research, not proof that a model independently completed the entire investigation. Researchers still had to establish that the bugs were real, test their impact, and work with maintainers on a coordinated release. AI helped with difficult code paths and repeated testing, but the result depended on a team that could interpret evidence and verify the proposed fix.

Node.js: a separate flaw with a documented AI reporting credit

The Node.js security release published on 21 October included CVE-2026-111497, a high-severity out-of-bounds write in the Brotli decoder bundled with Node.js. The flaw arose because an invalid block switch was treated as a temporary request for more input rather than a permanent format error. The streaming decoder could then continue appending data to an internal eight-byte buffer, corrupting process memory.

An application may be exposed when it decompresses attacker-controlled Brotli data through Node.js’s node:zlib APIs. Memory corruption can crash the process, disclose memory, or potentially enable remote code execution. The relevant fixes are Node.js 22.23.4, 24.22.1, and 26.12.1. The project’s advisory rates the issue High; Singapore’s Cyber Security Agency separately assigned a CVSS 3.1 score of 9.8 and described it as critical. Those labels come from different rating systems and should not be treated as contradictory measurements.

The official Node.js advisory credits OpenAI Codex Security, naming Khai Tran and Sylvie Mayer, with reporting the flaw. It credits Node.js maintainers with fixing it. This provides direct evidence that an AI security tool contributed a report accepted by a major open-source project. The advisory does not, however, say that AI autonomously performed every stage of discovery, reproduction, or remediation.

The cases should not be collapsed into one claim about AI discovery. In the PHP investigation, researchers described using several AI systems across a broader workflow, from discovery to patch validation. In the Node.js advisory, the project explicitly credited Codex Security with reporting one decoder vulnerability. The evidence supports a growing role for AI tools, while leaving the degree of autonomy and contribution different in each case.

What AI changes in vulnerability research

Security teams already use static analysis, fuzzing, dependency scanning, code review, and dynamic testing. These methods can identify suspicious patterns or trigger failures, but they do not always explain whether an attacker can reach the vulnerable code or what a failure means for the system. A crash is evidence worth investigating, for example, but it does not by itself prove that code execution is possible.

AI tools can help researchers understand unfamiliar code, trace data through multiple components, propose test cases, interpret failures, and revise hypotheses. When connected to controlled execution and analysis tools, they can support the repeated cycle of finding a candidate issue, reproducing it, and checking whether a patch removes the problem. The value depends on the model, its tools, available evidence, and the evaluator’s skill.

A model can also be wrong. It may misunderstand an execution path, invent a condition that the program does not satisfy, or produce a plausible explanation for a bug that cannot be reproduced. A useful finding needs evidence: affected versions, a repeatable test, a credible account of impact, and a fix that survives regression testing. AI can reduce some of the work required to reach that point, but it does not make verification optional.

Google Threat Intelligence Group’s September 2026 analysis provides broader context. It reported that monthly vulnerability disclosures increased from 5,045 in January to 10,740 in August 2026. The same analysis cautioned that raw counts can be misleading because changes in automated CVE assignment practices can inflate the totals. It also reported an increase in observed exploitation, while noting that disclosure volume alone does not explain which flaws attackers are using.

A larger stream of vulnerability reports does not mean every report represents an exploitable emergency. Organisations need to identify whether their own systems are affected, how exposed the vulnerable component is, and which remediation will reduce risk. That requires accurate asset records and a clear prioritisation process. More findings help only when teams can distinguish credible risk from noise and deploy the right fixes.

Faster discovery can also mean faster exploitation

The same analytical capabilities can help attackers study unfamiliar code, compare software versions, and adapt public technical details. AI may reduce the specialist effort needed to investigate a vulnerability, though the effect varies by model and task. Defenders therefore need to plan for shorter response windows after important technical information becomes available.

Disclosure dates do not necessarily mark the start of exploitation. Amazon Threat Intelligence reported an attempt against its MadPot honeypot on 17 October, four days before public disclosure. AWS said it could not determine how the actor obtained the exploit information, so the event does not prove that AI or any particular disclosure path was involved. After the advisory became public, AWS observed additional attempts and proof-of-concept exploits appearing quickly. Security teams should therefore investigate from the earliest credible activity, rather than treating publication day as the beginning of the risk window.

AWS argues that AI-assisted analysis can make it cheaper to turn a patch or advisory into a working exploit. Google’s threat analysis similarly suggests that AI may be helping actors weaponise already-disclosed vulnerabilities more efficiently. These are informed assessments from security organisations, not proof that every recent attack was AI-driven. The defensible conclusion is that the time between public technical details and attempted exploitation can be short, so response plans should not assume attackers will wait for a widely circulated proof of concept.

What software organisations should do

Start with an accurate inventory of runtimes, libraries, applications, and third-party products. Teams cannot prioritise a vulnerability reliably if they do not know which services use the affected component, which versions are deployed, or whether a vendor bundles its own runtime. Inventory should include internet-facing workloads and less visible internal services, as both can matter in a compromise.

For PHP2Shell, the upstream fixes include PHP 8.2.35, 8.3.36, 8.4.27, and 8.5.12. Organisations should follow the advisory for their operating system or application vendor, because package versions and backported fixes can differ from upstream version numbers. For Node.js, affected deployments should be moved to the appropriate fixed release line, including 22.23.4, 24.22.1, or 26.12.1. Teams should check whether externally reachable application paths decompress untrusted Brotli data. AWS also noted a separate PHP issue, CVE-2026-115560, on 23 October involving an uncommon session upload-progress configuration; teams should consult current vendor guidance rather than assume the PHP2Shell fixes cover every subsequent PHP advisory.

Patching does not replace investigation. For a vulnerability with evidence of exploitation before public disclosure, teams should review relevant logs and process activity from the earliest known activity, not only from the advisory date. For PHP2Shell, AWS’s observation makes 17 October a useful starting point for investigation. Look for suspicious requests, unexpected child processes, changes to application files, and unusual outbound connections, then preserve evidence and follow the organisation’s incident-response process.

AI tools can assist with code review, test generation, triage, and remediation planning, but introduce their own governance requirements. Evaluate tools in controlled trials, define what repositories and data they may access, and require human review before changes are merged or deployed. Vulnerability reports and source code can be sensitive, so organisations should understand where data is processed and retained before connecting a tool to production repositories.

The bottleneck may move from discovery to response

As AI-assisted research becomes more capable, security teams may spend less time on some forms of initial investigation and more time validating findings, prioritising risk, reviewing patches, and deploying changes safely. That shift is not guaranteed for every team or product, but the PHP and Node.js cases show why it deserves attention. Faster discovery only improves security when an organisation can turn the finding into a verified fix.

Neither incident supports treating AI as a magic security solution or as a technology that makes human expertise irrelevant. AI contributed to documented security work, while researchers and maintainers still had to establish the facts and deliver fixes. The same capabilities may help attackers analyse vulnerabilities, which makes timely patching and evidence-based incident response more important. The operational question is whether a company can act on a credible finding before an attacker succeeds.

For company leaders, the useful measure is not how many AI security tools are purchased or how many findings they produce. It is whether the organisation can identify affected assets, validate the findings that matter, and reduce exposure before exploitation succeeds. That is where better vulnerability discovery becomes a measurable improvement in software security.