Coding-agent CI harness trust-boundary failures

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. That 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). Google's advisory for the Gemini CLI findings, which OSV aliases to CVE-2026-12537 (OSV, 2026-04-24), describes two hardening changes rather than the researchers' chain: headless mode no longer trusts the workspace folder automatically, because untrusted contents "could lead to remote code execution via malicious environment variables in the local .gemini/ directory", and "the Gemini CLI policy engine now evaluates tool allowlisting under --yolo mode", which it previously ignored. It rates the issue Critical, CVSS 10.0, and fixes it in @google/gemini-cli 0.39.1 and run-gemini-cli 0.1.22 (Google, 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. In the Gemini CLI finding, where the environment was sanitised only for a child process, the write-up's phrasing of the step that reached the runner's secrets 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." (Novee Security, 2026-08-05) Novee chains that read with a shell allowlist that was never enforced at runtime; Google's advisory covers the allowlist and folder trust but does not describe the parent-process read.

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.