A watch item on this blog since Thursday just resolved into something more interesting than the original tip suggested. The initial lead — a single CVE said to span Claude Code, Gemini CLI, and OpenAI’s Codex Workflow — turned out to be a garbled secondhand summary of a Black Hat USA talk. Checked directly against NVD, GitHub’s advisory database, and The Hacker News’ own August 7 writeup, the real picture is three separate vulnerabilities in three separate products, two of them already patched months ago, presented together at Black Hat on August 5 by Novee Security researcher Elad Meged because they share the exact same architectural mistake.
That mistake, in Meged’s framing: “the harness is the code between the model and the real world,” and in all three tools, some component marked a value safe — a quoted shell argument, a tool-allowlist entry, an instruction file — that a downstream component then trusted further than it should have. Here’s what each one actually was, and why the pattern matters more than any individual bug.
Claude Code: CVE-2026-54316, a Hugging Face Download Counter as a Side Channel#
The Claude Code flaw is real, was disclosed under CVE-2026-54316, and has been fixed since v2.1.163 — published back on June 23, well before the current v2.1.226. It’s not new. What made it Black-Hat material is the exfiltration technique.
Claude Code’s WebFetch tool pre-approves a handful of domains for auto-fetch without a permission prompt, and huggingface.co was one of them — approved as a bare hostname, meaning any path on that domain qualified. An attacker who got malicious content into a Claude Code session’s context (via a GitHub issue, for instance) could direct the agent to create 64 separate Hugging Face repos, one per possible character of a secret, and have the agent fetch each repo’s public download-counter page in sequence. The counter that incremented revealed which character was correct. Read a secret one byte at a time through a metric nobody thought to treat as a covert channel.
CVSS scored it 9.1 (v3.1) or 6.0 (v4), depending on which scoring revision you use — the gap itself is a small reminder that CVSS versions don’t always agree on how to weigh a confidentiality-only exfiltration path. Anthropic’s fix scoped the huggingface.co pre-approval down from the bare hostname to documentation paths only, closing the specific channel without banning the domain outright.
Gemini CLI: CVE-2026-12537, a Tool Allowlist That Was Decorative#
Google’s flaw carries a maximum CVSS score of 10.0 and, like Claude Code’s, was fixed months before this Black Hat talk — patched in Gemini CLI 0.39.1 and the run-gemini-cli GitHub Action 0.1.22, back in April.
The bug: Gemini CLI’s headless/CI configuration let you specify restricted tool access like run_shell_command(echo), with the parenthetical meant to scope the shell tool to just the echo command. That annotation was never actually parsed or enforced at runtime — prefix matching registered the full, unrestricted shell tool regardless, and the internal canExecute() check only verified the command string was non-empty and the path was valid. No allowlist check existed anywhere in the execution path. Combined with --yolo mode (which ignores permission prompts entirely) processing untrusted issue content, an attacker with zero repository privileges could get arbitrary shell execution on a CI runner. A second half of the same disclosure covered environment-variable leakage: secrets were stripped from spawned child processes but left readable in the parent’s /proc/$PPID/environ, so a compromised child could read the parent’s GITHUB_TOKEN anyway.
OpenAI Codex: No CVE, and Still Not Fixed the Way You’d Want#
This is the one piece of the talk that’s actually new. OpenAI’s coding-agent workflows commonly run in two passes — a first pass reads an untrusted GitHub issue and does initial triage, a second pass validates and finishes the job. OpenAI protects .git/, .agents/, and .codex/ from being written by agent output, but AGENTS.md — the file Codex reads on every invocation and loads directly into the model’s instructions — sits in the open workspace with no such protection. A malicious issue can steer the first pass into writing a poisoned AGENTS.md, and when a schema failure kicks the job to the second pass, that pass loads the attacker’s file as authoritative instructions while holding whatever elevated credentials (deploy keys, GITHUB_TOKEN-with-write) the second pass was granted.
OpenAI’s response was workflow-level, not product-level: split multi-pass jobs into separate jobs with independent checkouts, remove direct checkout access from the vulnerable workflow, and document AGENTS.md as an untrusted input surface going forward. No CVE was assigned — OpenAI’s stated position is that the sandbox behaved as documented. That’s technically defensible and also the least satisfying answer of the three, since it means any other repository running the same two-pass pattern with a writable AGENTS.md inherits the same exposure until they independently apply the same fix. There’s no patched version number to upgrade to.
The Pattern Is the Story, Not the Bugs#
Individually, two of these three findings are old news dressed up for a conference slide — already-CVE’d, already-patched, low practical urgency today. What’s worth actually sitting with is the structural through-line Meged drew across them: in each case, a security decision was made in one place (a quote-stripping validator, an allowlist parser, a workspace-isolation boundary) and consumed somewhere else that assumed the decision meant more than it did. A validator that strips quotes “because quoted text is inert.” An allowlist annotation that was never wired to an actual runtime check. A directory-level write protection that stopped one file short of the file that mattered most.
This is the same class of finding this blog has tracked across SymJack/TrustFall, GuardFall, and GhostApproval — coding agents keep shipping trust-boundary bugs not because any one vendor is careless, but because the harness architecture common to all of them (untrusted content in, model reasoning in the middle, real filesystem/shell/network access out) creates a lot of seams where “safe” gets asserted once and believed too many times downstream. Claude Code’s sandbox.credentials model — masking secrets at the resource level rather than trying to enumerate every unsafe command string — is the structurally sounder answer to exactly this class of bug, and it’s notable that Anthropic’s own fix here (narrowing a domain pre-approval rather than trying to blocklist exfiltration patterns) followed the same resource-level instinct. It’s also worth being honest that Claude Code wasn’t immune to the underlying pattern — it just happened to get patched first.
If you’re running any of these tools in unattended CI or automation contexts — GitHub issue triage, auto-triggered PR review, scheduled agentic workflows — the actionable takeaway isn’t “upgrade Claude Code and Gemini CLI” (you’re almost certainly already past both fixed versions by now). It’s to audit your own multi-pass or multi-stage agent workflows for the OpenAI pattern specifically: any file an earlier untrusted-input-handling stage can write that a later, more-privileged stage reads back as instructions. That gap doesn’t come with a CVE number to search for.
Sources: Novee Security, “Black Hat 2026: If You Run These Automations, You’re Exposed Too”, published August 6, 2026 (primary researcher writeup) — The Hacker News, “Claude Code and Gemini CLI Flaws Let a GitHub Issue Reach CI Workflow Secrets”, published August 7, 2026 — NVD, CVE-2026-54316 — GitHub Advisory GHSA-wpqr-6v78-jr5g (Gemini CLI) — Claude Code changelog (v2.1.163 fix confirmation), all fetched directly.
