AI Code Security Review in 2026: AI Found the Bug, Humans Still Fix It

The short version: in the last fortnight AI security scanning stopped being a demo. A frontier-model-assisted audit surfaced a decade-old unauthenticated remote code execution bug in PHP's core — two CVEs at CVSS 9.2, in the language under roughly 70% of the web — and maintainers are already drowning in what the scanners send them: Postgres 19 slipped its release because AI reviewers filed more bugs than humans could fix, and 24 hours after the PHP patch, one vendor counted 99.3% of measurable PHP instances still unpatched. The finding half works. The fixing half is now the bottleneck — which changes what these tools are for and what they should never be trusted with.

Two weeks, in order

If you only read headlines, the story looks like one big event. It is actually a stack of dated decisions, and the order matters.

The finding half: not up for debate anymore

PHP2Shell is the strongest evidence yet that AI code review finds real things. The mechanics, per the php.net advisory, are two distinct bugs in the engine itself, not in any application: CVE-2026-109618, where out-of-memory handling can interrupt PHP while internal request data is only partly initialised, and CVE-2026-109619, where request-owned state can survive after its backing memory is freed and be reused by a later request on the same worker. Both allow unauthenticated remote code execution. The advisory's own risk ranking is unusually blunt: the risk is highest for mod_php, "with a demonstrated exploit where an unauthenticated request can trigger the attack before any application code runs."

Wiz's framing of how it got there is the sentence to keep:

"The underlying flaws had been present for decades, but demonstrating their exploitability required an exceptionally complex chain of steps, at the edge of what human researchers could practically achieve. Frontier AI models substantially reduced that barrier, turning a longstanding flaw into an exploit."

— Wiz Research, "PHP2Shell," Oct 21, 2026

Wiz names its tooling — Wiz Atlas, Gemini 4 Argon, GPT-5.6 Sol — and the post carries a quote from Google's head of Gemini Security praising Argon's role. OpenAI says separately that Sol assisted and invites more open-source projects to apply to its coordinated-disclosure programme. Anthropic's earlier numbers point the same way: over 500 vulnerabilities in production open-source code found with Opus 4.6, and 22 vulnerabilities in Firefox in a two-week collaboration with Mozilla. Whatever you think of the marketing, the patched bugs are verifiable, and this is the first time AI-assisted discovery produced a CVSS 9.2 in a language that most of the web runs on.

The fixing half: where the story actually breaks

Then read the maintainer side, and the tone changes completely.

1. The findings arrive faster than anyone can triage them

Postgres 19 is the precedent everyone will point at for the next year. Commenters there could not even agree on what changed:

"The debate was going on and they weren't sure if it was that there were more bugs or just that because of AI they suddenly knew about more bugs than usual."

— MBCook, HN

And the reason AI-found bugs are not a clean win for a project like Postgres:

"I imagine that the bugs being found are not the kind you can just press a button on the LLM to fix anyway, but are instead the sort of bugs which require the reviewer to deeply consider design tradeoffs."

— devin, HN

2. The reports are noisy, and the models won't help you triage

The sharpest first-party account comes from the maintainer of Pion, the Go WebRTC library that Anthropic's open-source scanner audited — 36 bugs and 6 CVEs, as the Tell HN thread put it, which OpenAI's scanner missed. Here is what arrived on the other end:

"Someone sent me a long markdown of issues GLM 5.3 found, and most of them are panics (we don't consider panics to be CVEs). It didn't find any of the CVEs oss-scanner found."

— JoTurk (Pion maintainer), HN

"Both Claude and Codex refused to help verify, triage, or develop proof-of-concept reproductions for any of the issues reported by oss-scanner. This was counterproductive, as we were trying to fix the vulnerabilities and coordinate CVE disclosures as quickly as possible."

— JoTurk, HN

That second one is the part no vendor blog mentions: the same safety classifiers that stop abuse also block fixing. A developer working on defensive security reports hitting that wall constantly — "I can't go more than about ~4 hours without Claude (Opus 5.5) getting the [cyber] shock collar, and most of the time it isn't even me asking Claude to perform a security analysis" (Bender, HN). Anthropic's answer to this is the Cyber Verification Program — but that is a gate you have to qualify for, not a setting.

3. A "found" bug is not a finding until someone proves it's exploitable

The most useful piece of design advice in either thread:

"If you have a model scan for errors and fix them in a loop, it can go 100 rounds without stopping. Maybe it needs a strict stopping criterion, e.g. the model has to prove a vulnerability is actually exploitable before it counts."

— a3nz3g, HN

4. Some of the "decades-old" bugs were already reported

This is the one detail that changes how you read every "AI found a bug nobody noticed for 20 years" headline. In the PHP2Shell thread, commenters traced part of the story back:

"Apparently both bugs had been reported previously, pre-AI, if so some important questions need to be asked about how those reports slipped through without a fix."

— dspillett, HN

"In fact as far as I can tell those specific bugs were fixed. bugs.php.net id=78876 marks the OOM bug as closed and fixed in 2020."

— dwohnitmok, HN

Others argued the 2020 fix only covered a specific reproduction rather than the underlying path. We are not going to pretend to adjudicate PHP's bug tracker from here — the honest summary is: at least one of these bugs has a prior report on record, and the "undetected for decades" framing is doing more work than the evidence supports. The discovery is still real. The narrative is cleaner than the facts.

The incentive problem, stated plainly

Almost every source in this story sells something adjacent to the finding. Wiz's post is a product showcase that names Wiz's own AI and a Google model, and quotes a Google executive; Anthropic's is a product announcement for Claude Security; OpenAI's is a programme that wants open-source projects in its pipeline. Readers noticed:

"First the product they sell, then the product they got early access to... I know they waited two months with this but wouldn't it be wiser to wait just a little bit more than a few minutes after the fix released?"

— krelian, HN

"The flaw was in at least 20 year old code... No compute costs for finding the issue or for writing the exploit are disclosed. But it is marketed as if it were the first RCE found in human history."

— asbv-1qq, HN

The disclosure itself was ragged: a distributor that had patches early went live before the plan, forcing a rushed announcement (eagleal, HN), and the press described a botched coordinated disclosure. None of that changes the CVEs. It does change whether you should buy the vendor whose blog you just read.

What you can actually buy right now, and what it costs

The detail worth pausing on: the flagship product has no public price. That is not a scandal, but it does mean the "AI security" you can evaluate as an individual is the Claude Code plugin running on your own tokens — not the Mythos-powered app.

If you already pay for AI code review, do these five things

1. Patch PHP first, argue later. 8.5.12, 8.4.27, 8.3.36 or 8.2.35. PHP 8.1 and older get no upstream fixes; if you're on the volunteer-maintained remi repo, the project explicitly says to move to distro packages or build from source. Until you can update, the advisory's mitigations — memory_limit=-1 set where applications can't override it, a low post_max_size, container-level limits — reduce specific attack paths and "do not make an installation safe."
2. Use a different model family to review the model that wrote the code. A reviewer from the same family shares the author's blind spots: "we use GLM 5.3 flash in pr review and it catches all sorts of bugs Claudes write... you need to use different model families to check each other's work" (verdverm, HN).
3. Require an exploitability proof before a finding becomes a ticket. Otherwise the output is a panic list, and panic lists get ignored — which is exactly how a real bug hides in the noise.
4. Budget triage time equal to the scan time, or don't switch it on. Postgres 19 is what happens when you don't. Scanning is the cheap part now; deciding is the expensive part.
5. Keep the human sign-off. Every vendor's own FAQ says it — Anthropic's states that Claude can make mistakes and patches should be reviewed before applying "especially for critical systems." Treat any tool that removes that step as a liability.

Are AI coding assistants worth it? → Shipping AI code to prod →

Method: primary sources read on 2026-10-23 — php.net's advisory, Wiz Research's PHP2Shell post, Anthropic's Claude Code Security (Feb 2026) and Cyber Mission (Oct 2026) posts plus the live Claude Security product page, and the Cyber Verification Program announcement. Aggregated: four Hacker News threads (2,232 points, 944 comments) — the php.net advisory thread, the PHP2Shell thread, the Postgres 19 delay thread, and the Pion scanner thread. Quotes are verbatim with permalinks; the dispute over whether the PHP bugs had prior reports in 2020 is presented as a dispute, not a verdict. We don't take payments from vendors.