{"slug": "a-cvss-10-0-in-your-ai-coding-agent-is-just-toctou-wearing-a-hoodie", "title": "A CVSS 10.0 in Your AI Coding Agent Is Just TOCTOU Wearing a Hoodie", "summary": "Security researchers disclosed a CVSS 10.0 vulnerability in AI coding agents from three vendors, including Claude Code, Gemini CLI, and OpenAI Codex, stemming from a time-of-check-to-time-of-use (TOCTOU) flaw that allows GitHub issues or config files to exfiltrate CI secrets. The flaw arises because agents validate untrusted input once before acting with full privileges, a design pattern that spans multiple products and requires architectural scrutiny rather than one-off patches.", "body_md": "A GitHub issue can now potentially exfiltrate your CI secrets, and the tool that let it happen is the same one your team is using to \"move faster.\" That's the story, and it deserves more than zero comments.\n\nThis isn't new math, it's an old bug class wearing a new jacket. Time-of-check-to-time-of-use flaws have been around since multi-user Unix systems first had race conditions in file permissions. What's new is the attack surface: coding agents that read GitHub issues, `.env`\n\nfiles, or an `AGENTS.md`\n\nconfig as \"context,\" decide that context is safe in one pass, then act on it with full privileges in a later pass. Swap \"file descriptor\" for \"LLM prompt\" and you've basically got the same bug your professor warned you about, except now it's got a CVE and a marketing problem.\n\nThree vendors, three implementations, the same architectural flaw. That's the part worth sitting with. When Claude Code, Gemini CLI, and OpenAI Codex all have a harness-level validation gap, that's not a coincidence, that's convergent evolution. Everyone building these agent harnesses is solving the same problem (let the model act autonomously on external input) with the same shortcut (validate once, trust forever).\n\nHere's what's getting overstated: the \"no in-the-wild exploitation confirmed\" line is going to get read by some people as \"so it's fine.\" It's not fine, it just means nobody's publicly bragged about it yet, or nobody's noticed. A CVSS 10.0 in a tool that runs on CI infrastructure with secrets attached is about as close to a worst-case scenario as this bug class gets. The absence of a confirmed breach isn't evidence of safety, it's evidence that researchers got there first this time.\n\nWhat's being understated: the trust boundary problem here isn't a bug you patch once. A GitHub issue title, a `.env`\n\nfile, a config file the agent reads for \"instructions\" — these are all untrusted input by definition, and yet the entire pitch of these tools is \"let the agent read your repo and just handle things.\" Every one of those ingestion points is a potential injection vector. Patching this specific CVE doesn't close the category, it closes one door in a house that was built with a lot of doors.\n\nWho benefits from the current narrative? Honestly, the vendors get a pretty clean story here: found, patched, moving on, no incidents. That's the standard \"responsible disclosure worked\" arc, and to be fair, it did work this time. But it also quietly reframes a fundamental architecture problem (validate-then-trust across a privilege boundary) as a one-off bug that's been \"fixed,\" when the actual lesson is that the harness design pattern itself needs scrutiny across every agent product doing this.\n\nIf you've wired any of these tools into CI, this is your reminder that \"AI coding assistant\" and \"process with access to your secrets\" are the same sentence now. Treat the agent's action surface the same way you'd treat a third-party GitHub Action: least privilege, scoped tokens, no blanket `repo`\n\nor `write-all`\n\nscopes because it's convenient. If your agent doesn't need to see the `.env`\n\nfile to do its job, it shouldn't have a path to read it.\n\nFor security teams, the useful move isn't just patching, it's asking your own AI tooling vendors a pointed question: where exactly does your validation happen relative to where the model gets to act? \"We validate the input\" is not an answer. \"Validation happens in the same trust boundary as execution, with no re-check between context ingestion and tool invocation\" is an answer, and if a vendor can't give you that level of detail, that's useful information too.\n\nFor the broader industry: this is going to keep happening until agent harnesses get boring, standardized, and boxed in the same way sandboxing and permission models got boring for browsers and mobile OSes. We're early. The zero HN engagement on this story is honestly more telling than the CVE itself, this stuff is still flying under the radar for a lot of people who are deploying these tools into production pipelines right now without a second thought.\n\nWhen your CI pipeline's job is to run untrusted code fast, and your AI agent's job is to read untrusted input and act autonomously, at what point does \"agentic\" stop being a feature and start being the vulnerability class itself?\n\n— Cor, Skyblue Soft", "url": "https://wpnews.pro/news/a-cvss-10-0-in-your-ai-coding-agent-is-just-toctou-wearing-a-hoodie", "canonical_source": "https://dev.to/coridev/a-cvss-100-in-your-ai-coding-agent-is-just-toctou-wearing-a-hoodie-31jj", "published_at": "2026-08-10 13:11:08+00:00", "updated_at": "2026-08-10 13:19:19.510711+00:00", "lang": "en", "topics": ["ai-safety", "ai-agents", "ai-products", "ai-tools", "ai-ethics"], "entities": ["Claude Code", "Gemini CLI", "OpenAI Codex", "GitHub", "CVSS"], "alternates": {"html": "https://wpnews.pro/news/a-cvss-10-0-in-your-ai-coding-agent-is-just-toctou-wearing-a-hoodie", "markdown": "https://wpnews.pro/news/a-cvss-10-0-in-your-ai-coding-agent-is-just-toctou-wearing-a-hoodie.md", "text": "https://wpnews.pro/news/a-cvss-10-0-in-your-ai-coding-agent-is-just-toctou-wearing-a-hoodie.txt", "jsonld": "https://wpnews.pro/news/a-cvss-10-0-in-your-ai-coding-agent-is-just-toctou-wearing-a-hoodie.jsonld"}}