2026-08-10 · view entry permalink →
Coding-agent CI harnesses broke on the same trust boundary three different ways — and the two findings that matter most carry no CVE at all
Three AI coding-agent CI harnesses were broken in different ways by the same underlying question: what, inside an automated pipeline, is the agent allowed to treat as authoritative? Novee Security tested each against the vendor's own public repository in default configuration (Novee Security, 2026-08-05).
The Claude Code Action work is best read as three successive rounds of patch-and-bypass, and only the last of them carries an identifier. Round one turned on an ordering mistake in defensive code: the command-injection validation pipeline strips single-quoted content before inspecting a command — a sensible-looking measure to avoid false positives on shell metacharacters inside string literals — which means an injected payload placed inside single quotes is examined only after the interesting part has been removed. A validator that sanitises its input before deciding whether the input is dangerous is checking something other than what will execute. Round two was an asymmetry in the allowlist itself, where commands classed as read-only were exempted from path checking, so a read-only utility could be pointed at any file on the runner. Neither round carries a CVE. The identifier belongs to the third round, and Anthropic's own advisory states what it covers: "Because the hostname huggingface.co was pre-approved as a bare hostname for the WebFetch tool, any path on that domain—including attacker-controlled model repositories—was auto-approved without a permission prompt or being subject to --allowedTools restrictions." The advisory records the affected range as 0.2.54 up to 2.1.163 and the fix in 2.1.163 (Anthropic, 2026-06-13). The Google finding is tracked as CVE-2026-12537, fixed in gemini-cli 0.39.1 and run-gemini-cli 0.1.22 (OSV, 2026-04-24).
Both of those were patched weeks to months before the write-up appeared, so for those two vendors the action is a version check, not an incident. Their mechanics are still worth carrying, because the lesson generalises to anyone building command allowlists rather than merely consuming these products — and because the exfiltration target the researchers reached is one this store already knows from a different flaw in the same product family. The write-up's phrasing of that step is worth quoting for how narrow the distinction is: "cat /proc/$PPID/environ reads the parent, not self, and pulls from the process that still holds every single thing the isolation was built to keep away."
The third finding is the one that is genuinely current, and it has no CVE because, as the researchers observe, nobody files one for newly documented behaviour. In an OpenAI Codex workflow, two agent passes ran over a single shared checkout, and the agent's own default instruction file sat in that checkout outside the protected-metadata set. That file "is loaded from disk on every single invocation and injected as instructions the model treats as authoritative" — so a first pass induced to modify it dictates what the second pass believes it has been told to do. The fix was structural rather than a patch: "3 Days after our report they fixed it and the two passes on openai/codex were split into separate jobs, each with its own checkout." That change landed in the vendor's own repository. It does not propagate to anyone else's pipeline, because the flaw is not in a shipped component — it is in a workflow shape.
It is loaded from disk on every single invocation and injected as instructions the model treats as authoritative
3 Days after our report they fixed it and the two passes on openai/codex were split into separate jobs, each with its own checkout
Because the hostname huggingface.co was pre-approved as a bare hostname for the WebFetch tool, any path on that domain—including attacker-controlled model repositories—was auto-approved without a permission prompt or being subject to --allowedTools restrictions.