An API key walked out of a continuous integration runner one character at a time, through a public download counter on Hugging Face.
Nobody jailbroke a model to do it. Nobody wrote a clever prompt. The counter is a number on a webpage that goes up when someone downloads a file, and somebody worked out that a number going up is a channel, and that a channel is all you need if you are patient and the secret is short.
That is CVE-2026-54316, in Claude Code, disclosed by Novee Security at Black Hat on August 5 and fixed in version 2.1.163. It is one of four security stories published in the same two days, and the useful thing about reading them together is that they stop being four stories.
Four stories, one week
Novee ran an attack against the coding agents from Anthropic, Google and OpenAI, each in the configuration its vendor ships by default. A GitHub issue, opened by an account with no privileges on the repository, was enough to execute code on the CI runners behind Anthropic's and Google's own agent repositories. On OpenAI's, it was enough to hijack the next agent run.
1Password's research team published work on August 6 testing whether frontier models can patch vulnerabilities. They gave two models six high-impact flaws disclosed since March. About half the patches worked.
Veracode ran a wider version of the same question across more than a hundred models and eighty coding tasks and got an average security pass rate of 56%, with 44% of the generated code introducing a detectable OWASP Top 10 vulnerability.
And PortSwigger published the most impressive AI security research anyone has published this year, in which an AI-assisted system found genuinely novel attack techniques against the HTTP stack of banks, government infrastructure, security products and an airport.
Three of those look like bad news about AI and one looks like very good news about AI. They are the same story told four times, and the story is not about the models. Every one of these outcomes was decided by the scaffolding around the model: what it was allowed to touch, what checked its work, and who decided when it was done.
Novee's founding engineer Elad Meged wrote the sentence the whole week turns on: "The harness is the code between the model and the real world."
Nobody had to talk a model into anything
Look at what actually failed in the three coding agents, because none of it is what people picture when they imagine an AI security incident.
In Claude Code, the command validator strips single-quoted text before running its twenty-three checks. That is correct behavior. That is what bash does. But a payload sitting in the value of git push --receive-pack, a flag git will execute, therefore reached the runner untouched. One component parsed a value correctly and marked it safe, and a later component acted on that same value with more authority than the first one assumed. Novee reports no CVE and no publicly stated fixed version for that particular chain.
In Gemini CLI, the tool allowlist was parsed when the tool was registered and then never enforced at runtime, so at execution time nothing was actually checking the list. Under the --yolo flag, every command the model asked for was auto-approved anyway. The separate container-launcher flaw, CVE-2026-12537, scored a CVSS v4 of 10.0 and did not involve persuading a model of anything at all: a crafted .gemini/.env file let an unprivileged attacker run code on the CI host before the sandbox even started. Google fixed it in Gemini CLI 0.39.1 and run-gemini-cli 0.1.22.
In OpenAI's Codex repository there was no product bug to patch, and OpenAI's position is that its sandbox behaved exactly as documented. The workflow ran two Codex passes inside a single job sharing one checkout, which meant the first pass could write AGENTS.md, the file the second pass then loads as its own instructions. Failing the JSON validation between the passes is what launched the second one. OpenAI has since split the passes into separate jobs and now lists repository instruction files as part of the untrusted input surface.
Read those three together. A quoting rule. A check that ran at registration instead of at runtime. Two jobs sharing a working directory. Not one of them is a fact about intelligence. They are the ordinary, unglamorous class of defect that has been breaking software since long before any of this, and they are sitting in the layer nobody thinks of as a product because everyone is busy looking at the model.
The pattern Novee identifies is worth writing down because it generalizes past coding agents: one part of the system marked a value safe, and a later part acted on that value with more authority than the first part had granted. That is the shape. Wherever a trust decision is made in one place and consumed in another, that gap is the harness, and the harness is where the incident lives.
A patch that passes the test is not a fix
The 1Password work is named FLAWED, for Fix-Like Artifacts with Embedded Defects, which is the best acronym in security this year and also a precise description of the problem.
They sorted every generated patch into five outcomes: fixed; fixed but by changing how the application behaves; not fixed; fixed but opened a new flaw; not fixed and added a new flaw. Only 26% fixed the original vulnerability without altering application behavior. Another 20% fixed it by changing how the code works, which is a fix and a regression arriving together. 49% did not fix the vulnerability at all.
The researchers describe patches that "added fragile guard code that satisfied tests while failing to address the vulnerability's root cause." Sit with that sentence, because it is not a story about a model being dumb. It is a story about a model being extremely good at the thing it was actually asked to do. The instruction was, in effect, make the test pass. It made the test pass. The test was standing in for a property nobody had written down.
Veracode's Sam Guyer describes the same failure from the other end: "given a choice of implementation, LLMs are very inconsistent about whether they choose secure or insecure strategies," and "the output can look complete and functional while remaining unreliable from a security standpoint."
Then the finding that should genuinely worry anyone planning to automate this. 1Password's Hoodlet, on flaws that are novel or absent from the training data: "the patch success rate has gone negative, in terms of the outcomes." Negative, meaning the attempt leaves you worse off than not attempting. Which is precisely the category of flaw you most need help with, since the ones already in the training data are the ones already solved.
Two caveats, both of which belong in any honest version of this. The models tested were ChatGPT-5.5 and Claude Opus 4.8, not the newer models the labs say are markedly better at security work, and none of this research covers those. And every organization named here sells something adjacent to the problem: 1Password sells identity management, Veracode sells application security testing, Novee sells security research, PortSwigger sells the industry's standard web security tooling. Weigh all of it accordingly. It does not make the findings wrong. It does tell you which direction each one is likely to lean.
The number that reframes all of it comes from somewhere else entirely. Cursor's own data says 36% of code changes are now accepted automatically, with no human review of the change. Set that beside a roughly even-odds patch success rate, and the arithmetic writes itself. The generation side scaled. The verification side did not.
The same tool, pointed the other way
Now the good news, which is better news than the bad news is bad, and which proves the argument rather than contradicting it.
PortSwigger's James Kettle built an AI-assisted research system called HTTP Terminator and used it to find new ways to desynchronize HTTP. He fed it 138 HTTP and SMTP RFCs, split into roughly 15,000 fragments, and used those to generate 30,000 unique candidate attack vectors. It tested 30,000 websites where scanning was authorized through bug bounty or disclosure programs and surfaced roughly 700 vulnerable targets. One technique using Content-Type: multipart/byteranges worked across multiple server implementations and exposed more than 200 websites, including an unnamed United States bank.
The system also proposed a broader attack concept, Shared-Parser Confusion, after noticing that response-processing rules could be misapplied to requests when a server reuses its parsing logic. Kettle validated and generalized it. His description of that collaboration is the second sentence worth copying down from this week: "Neither of us would have discovered it alone."
A separate human-guided cascade produced a zero-day in Apache Traffic Server, which the researchers say has been patched and tracked as CVE-2026-63078. Worth stating plainly: The Hacker News checked on August 7 and found no public record of that identifier in CVE.org or NVD, and Apache's July advisory covering 34 flaws did not list it, so defenders cannot currently map it to a fixed release. Take the technique as demonstrated and the Apache case as not yet verifiable from public records.
Here is why this belongs in the same article as the failures. HTTP Terminator runs on the same commercial models that could not patch six CVEs reliably. The open-sourced implementation uses Claude for document extraction and test-case generation, and its investigator stage requires Claude Code, which is the same product that had an API key leaking through a download counter.
Same models. Same tooling. Opposite outcome. The difference is entirely in the harness Kettle built around them: a corpus deliberately chosen, chopped into fragments small enough to recombine, a generation stage that produced 30,000 candidates on the assumption that nearly all of them would be worthless, and an evaluation stage ruthless enough that when the system tested 16 ideas for improving response queue poisoning, exactly one survived.
Fifteen of sixteen ideas were killed by the harness. That is not a footnote. That is the product. A system that generates 30,000 candidates and cannot discard 29,000 of them is not a research tool, it is a firehose. Kettle's contribution was not access to a model, which anyone can buy. It was knowing what to feed it, and being willing to throw nearly all of it away.
Disclosure, which is the whole point
We build on Anthropic's Claude, and we use Claude Code. CVE-2026-54316 affects every Claude Code release from 0.2.54 through 2.1.163. We checked our own tooling rather than assuming: it reports 2.1.224, which is past the fix.
We are stating that because an article arguing you should know what is inside the systems you run, written by people who quietly run the product under discussion, would be an example of the problem rather than a description of it. The relevant severity numbers also disagree, and both belong here: Anthropic rates the flaw Moderate at CVSS v4 6.0, while NVD assigned it a CVSS v3.1 score of 9.1. Those are different scoring systems and not a like-for-like comparison, which is itself a small lesson about taking a single number off a page.
For what it is worth, CISA lists exploitation as none for both CVEs, and as of August 7 neither appeared in the Known Exploited Vulnerabilities catalog. There is, however, a public repository describing itself as a reproduction lab for the Claude Code flaw, and it has been up since June 18.
Your agent reads more than you think
One more finding, because it changes what counts as input.
Pillar Security reported on August 4 that the operators of the ChainDrop npm worm planted a Claude Code SessionStart hook and a VS Code folderOpen task inside compromised repositories. Those fire when a developer opens the workspace. Not on install, not on build, not on run. On open.
Put that beside the Codex finding, where a file written by one pass became the instructions for the next, and beside OpenAI's updated guidance that repository instruction files should be considered part of the untrusted input surface, and the rule falls out on its own: every file your agent reads is an input, and every input from outside your organization is untrusted. Instruction files, session hooks, editor tasks, environment files, issue text, pull request descriptions, dependency README files. All of it is now attack surface, and most of it is not in anybody's threat model because for thirty years none of it was executable.
The playbook
DMAIC at the strategic layer, disciplined delivery underneath. Six moves, in the order we would run them.
Patch the harness like the production software it is. Claude Code to 2.1.163 or later, Gemini CLI to 0.39.1, run-gemini-cli to 0.1.22. More importantly, put agent tooling into whatever process already tracks your dependency versions, because right now for most teams it lives outside that process entirely. A CLI that can execute commands in your build is not developer convenience. It has a version number, a changelog and a CVE history, which is the definition of production software.
Audit every workflow an outsider can trigger. The entire Novee attack starts with a GitHub issue from an account with no repository privileges. Inventory the automation that fires on events from outside your organization: issues, comments, pull requests from forks, webhooks, inbound email. Each one is a path from a stranger's keyboard into your build. That list is usually short, usually surprising, and almost never written down.
Treat AI output as a proposed change, never a verified fix. Guyer's phrasing is exactly right and worth adopting as policy language. A generated patch is a proposal. It earns the word "fix" after functional tests, regression tests, human review on anything sensitive, and static analysis that can trace data across files and call paths. The word you use for it determines how it gets treated, so use the accurate one.
Make the verifier independent of the generator. Not the same model, not the same harness, and above all not the same test the generator was optimizing against. Fragile guard code that satisfies a test is the predictable result of grading work against the rubric you handed the worker. If your only check is a suite the agent can see, you are not verifying anything, you are conducting an open-book exam and grading it yourself.
Treat every file the agent reads as untrusted input. Instruction files, session hooks, editor tasks, environment files, anything arriving through a pull request. Review changes to them with the same seriousness you review a change to a build script, because that is what they now are. ChainDrop fires on folder open, which means "I did not run it" has stopped being a defense.
Keep a human on the specification. This is Kettle's actual role in his own research, and it is the one job that has not moved. Hoodlet makes the same point about where this is heading: models are getting genuinely good at writing formal verification code, but the specification still belongs to a person. Someone has to say what correct means, in writing, before anything can check whether it was achieved. That is the job. It was always the job.
Our position
The industry has spent three years arguing about which model to use, and this week produced four separate demonstrations that the model is not where the outcome is decided.
The same models that failed to patch six vulnerabilities reliably also produced novel HTTP desync research good enough to expose a bank. The same product that leaked an API key through a download counter is a required component of the best AI security research published this year. Nothing about the intelligence changed between those two sentences. What changed was the quality of the apparatus around it: what it could reach, what checked its work, what got thrown away, and who decided when it was finished.
That is genuinely good news, because harnesses are buildable. They are made of the least fashionable materials in the industry: allowlists enforced at the point of use rather than the point of registration, trust boundaries drawn where a value is consumed rather than where it is parsed, review gates on the paths outsiders can reach, verification independent of generation, and a written specification that says what correct means. None of it requires a lab. All of it requires someone to own it.
The uncomfortable half is that this work is invisible when it succeeds and only ever named after it fails. It has no launch, no demo, no keynote. It shows up in the budget as overhead and in the incident report as a root cause.
Buy the best model you can. Then go look at what you built around it, because that is the part you actually shipped.
Sources: CyberScoop (August 7, 2026); Robert Lemos for Dark Reading (August 7, 2026); Swati Khandelwal for The Hacker News on the Novee research (August 7, 2026) and on HTTP Terminator (August 7, 2026). Underlying research by 1Password, Veracode, Novee Security, PortSwigger and Pillar Security, each of which sells products adjacent to its own findings.