It Took One Stranger, Zero Passwords, and a GitHub Comment to Nearly Break Three of AI's Biggest Coding Tools

Introduction

Somewhere in a Black Hat USA conference room on August 5, 2026, a room full of engineers watched a stranger no login, no access, no password, nothing leave a comment on a GitHub issue. Nothing about it looked unusual. It read like a bug report. Polite, even.

A few clicks later, that comment had reached inside the CI pipeline of one of the most valuable AI companies on Earth.

No malware. No stolen credentials. No brute-force attack hammering away at a login screen in the dark. Just words, typed into a public box, aimed at an AI that had been trained to be helpful and trusting.

That's not a scene from a thriller. That's what security researchers at Novee Security actually demonstrated, live, against the production repositories of Anthropic, Google, and OpenAI the three companies behind the AI coding agents that a huge share of engineering teams now lean on every single day.

If your team has adopted Claude Code, Gemini CLI, Codex, or anything built on the same idea, this is worth ten minutes before your next sprint planning meeting. Not because you should panic. The flaws are patched. Nobody was hurt. But because this incident is a preview screening of a much longer film: AI coding agents have quietly become one of the most interesting attack surfaces in modern software and most teams are still securing them like it's 2023.

Let's walk through exactly what happened, why a comment box turned out to be more dangerous than a firewall, and what a genuinely useful defense looks like not theoretical, not enterprise-jargon, but the version you could actually implement this week.

Pull quote: "The most serious security failures happen before the safeguards even get a chance to work or inside the parts of the system everyone already trusts." — Ido Geffen, CEO, Novee Security

Why This Should Interrupt Your Day

If your AI agent can read a GitHub issue, comment on a pull request, or run anywhere near your CI/CD pipeline and honestly, whose doesn't in 2026 you're running the exact setup that got breached. This isn't a "someday, when we have time" risk. It's a "did anyone check this yesterday" risk.

What Actually Happened at Black Hat 2026

Security conferences produce a lot of noise every year clever demos, theoretical exploits, the occasional stunt hack designed more for headlines than for real risk. This wasn't that.

Novee Security's research team, led by founder Ido Geffen and researcher Elad Meged, spent months quietly probing the three biggest names in AI-assisted coding: Anthropic's Claude Code, Google's Gemini CLI, and OpenAI's Codex. Crucially, they didn't build a sandbox to test in. They went after the vendors' own production repositories, running each tool exactly the way it ships out of the box because that's how almost everyone actually uses them.

What they found should reshape how your team thinks about "safe by default."

In Anthropic's and Google's repositories, someone with zero repository privileges unable to push code, unable to merge anything, unable to do a single thing a normal contributor could do got code executed on the CI runners behind the scenes. On OpenAI's Codex, that same zero-privilege access was enough to hijack the next automated agent run entirely, planting instructions that would quietly execute later.

Two formal vulnerabilities earned CVE numbers. Both are patched now. But here's the detail that should stick with you: this wasn't one lucky exploit against one careless company. It was the same underlying weakness, independently discovered in three completely different products, built by three completely different engineering cultures.

That's not bad luck. That's a pattern.

The Office With the Open Door: Why This Attack Worked

Try this thought experiment. You hire the most capable assistant you've ever met brilliant, tireless, endlessly diligent. There's just one catch: they take every note left on your desk completely literally, and they act on it immediately, no matter who left it.

Now imagine you leave your office door open, with a sign that reads: "Read everything in the inbox. Act on it right away."

That's not a hiring mistake. That's a policy mistake. And it's essentially the exact configuration that let a stranger's GitHub comment reach production infrastructure at three major AI labs.

AI coding agents exist to read things issues, pull requests, comments, documentation and act on what they find. That's the entire value proposition. The problem is that the agent often can't reliably tell the difference between "an instruction from the person who's supposed to be directing me" and "text that merely looks like an instruction, planted by someone who was never supposed to have a say."

Security researchers call this prompt injection, and if you've spent any time near AI security news lately, you've probably seen the term everywhere for good reason. OWASP's freshly updated 2026 Top 10 for LLM Applications still ranks it as the single most critical vulnerability category in AI systems, and increasingly, researchers describe it as the enabling flaw the one that makes almost every other item on the list possible in the first place.

Here's roughly how the chain worked in the Black Hat research:

An attacker opens a GitHub issue containing carefully worded text no code, just language.
An automated agent reads the issue as part of its normal job (say, triaging a bug report).
Hidden inside that ordinary-looking text are instructions the agent interprets as legitimate commands.
Those commands escalate sometimes across multiple separate stages of the agent's workflow until it does something it was never meant to do: run a shell command, read a secret, or touch a file that should've been off-limits.

One especially clever wrinkle deserves its own paragraph, because it's the kind of detail that makes security researchers sit up. On Claude Code, the team found a way to exfiltrate stolen information using the agent's own pre-approved access to Hugging Face encoding sensitive data into outbound API requests, then reconstructing it later simply by watching public download counts on repositories they controlled. No alarms triggered. No obvious red flag. Just numbers quietly ticking up on a public page, telling a story only the attacker could read.

It's the kind of technique you'd almost admire, if it weren't aimed at your infrastructure.

Three Companies, One Shared Mistake

Here's the breakdown, vendor by vendor, so you can check your own stack against it in under a minute.

Vendor / Product	What Went Wrong	CVE / Severity	Fixed In
Google — Gemini CLI	OS command injection in the container launcher, reachable through a crafted `.gemini/.env` file	CVE-2026-12537 — CVSS 10.0, the maximum possible score	Gemini CLI 0.39.1 / run-gemini-cli 0.1.22
Anthropic — Claude Code	Multi-stage escalation leading to credential theft via pre-approved Hugging Face access	CVE-2026-54316	Version 2.1.163 (affected versions: 0.2.54–2.1.162)
OpenAI — Codex	Writable `AGENTS.md` file letting planted instructions persist across automated workflow stages	No standalone CVE published	Patched by vendor

Three things about how each company responded are worth pulling out, because they tell you more than the bugs themselves do:

Google didn't just patch it rewrote the rulebook. The fix was a breaking change to Gemini CLI's entire trust model for headless, non-interactive execution. That's not a company quietly closing a hole. That's a company admitting the foundation needed rework.
Anthropic went three rounds before landing the real fix. Each attempt closed one door; researchers found another already open behind it. That's not a company fumbling that's what a genuinely adversarial disclosure process looks like when it's working the way it's supposed to.
All three companies cooperated fast. Novee credited each vendor for rapid, collaborative disclosure. Nobody wants a CVE with their name on it. But nobody stonewalled, either and in security research, that distinction matters enormously.

Tweetable quote: "Three companies. Three engineering cultures. One shared blind spot. If that doesn't tell you something about the whole category, nothing will."

Why This Isn't Really About Three Bugs

It would be tempting to stop here three vendors, two CVEs, all patched, nothing left to see. That would be the wrong lesson to take from this.

Here's why the timing matters more than the bugs themselves: in the exact same week as the Black Hat disclosures, OWASP quietly released its updated 2026 Top 10 for LLM Applications and for the first time, the rankings weren't just built on expert opinion. Researchers weighted 6,639 documented real-world incidents at 25% of the final scoring. The result was telling: Excessive Agency the risk of an AI system being handed more power to act than its task actually requires jumped to third place.

That's not a coincidence sitting next to the Black Hat news. That's confirmation, arriving from a completely independent direction, in the same week.

A few more numbers worth sitting with:

Of the 53 agentic AI projects currently tracked by OWASP's State of AI Surveyor, 28 are coding agents and the five fastest-growing tools in the entire agentic AI landscape (Claude Code, Gemini CLI, Codex, Cline, and Aider) all fall into that category.
Google separately reported a 32% jump in malicious, indirect prompt-injection payloads embedded in web content between November 2025 and February 2026.
IBM's breach-cost research found that incidents involving AI systems without proper access controls averaged $5.72 million while organizations with comprehensive AI security controls in place saved roughly $1.9 million per incident.
Gartner projects that by the end of 2026, 40% of enterprise applications will run task-specific AI agents, up from under 5% barely a year ago.

And then there's the one statistic that should genuinely unsettle you: a 2026 enterprise survey found 88% of organizations had confirmed or suspected an AI agent security incident in the past year. A separate survey of executives found 82% believed their existing policies already protected them.

Read those two numbers again. That's largely the same population of companies confident, and exposed, at the same time.

Put it all together and the picture is unambiguous: adoption is accelerating, incidents are already common, and confidence is dangerously outrunning actual protection. The Black Hat disclosures aren't a strange, isolated event. They're the visible tip of something much larger and much quieter happening across the entire industry.

The Honest Tradeoff: Pros and Cons

None of this is an argument for ripping AI coding agents out of your stack. Let's be fair about what you'd actually be giving up and what you'd actually be risking.

What you gain by keeping them:

Genuinely faster triage, code review, and routine maintenance work the productivity case is real, not hype
A vendor ecosystem that just proved it responds quickly and transparently under pressure
A well-understood, well-documented vulnerability pattern, which means defenses are catching up fast rather than fumbling in the dark
No evidence, anywhere, of in-the-wild exploitation before the patches shipped
A maturing tooling ecosystem permission scoping, audit logging, agent-specific penetration testing growing right alongside the risk

What you're actually risking if you do nothing:

The same attack pattern worked against three independent vendors this is systemic, not a rookie mistake by one team
The default configuration the one most teams actually run was the one that got exploited
Leadership confidence is outpacing real protection industry-wide (that 88%-vs-82% gap again, and it's worth remembering it once, clearly)
New CVEs in this exact category are almost certain to keep surfacing as agent capabilities expand
Smaller teams and agencies without dedicated security headcount are the least likely to catch a misconfiguration before it becomes a headline

The honest read: AI coding agents are a genuine productivity win. But they need to be treated as production infrastructure not a clever plugin you install once and quietly forget exists.

The Checklist Worth Bookmarking

This is the section to screenshot. If your team runs AI coding agents anywhere near a CI/CD pipeline, work through this list this week not next quarter, not "when things calm down."

Scope every agent to a limited service account. Never let an agent inherit your personal credentials or a broad, shared machine identity.
Separate "readers" from "doers." An agent that summarizes an issue or reviews a diff shouldn't carry the same tool access as one that can execute changes or run shell commands.
Require human approval before anything touches production. Automation is wonderful for drafts and suggestions. It's genuinely dangerous, unsupervised, at the exact moment of shipping.
Log every agent action, without exception. When something goes wrong and eventually, something will you need a real trail, not a shrug.
Audit permissions every time an agent's task scope expands, not only at initial setup. Permission drift happens fast, and it looks exactly like a routine configuration tweak until the day it isn't.
Treat public repositories as hostile input surfaces. Anyone, anywhere, can open an issue. Assume anything your agent reads from a public source could be adversarial, because eventually it will be.
Keep agents updated. Every vulnerability above is already patched but only for the teams that actually pull the update.
Run AI-specific penetration testing on a regular cadence, not just standard application security scans. Traditional tooling was never built to catch prompt injection, because prompt injection didn't exist as a category when most of that tooling was designed.

What the People Closest to This Are Saying

The AI-governance and security community has landed on something close to consensus, which is rare enough to be worth noting on its own.

As Steve Wilson and Rock Lambros, the leads of OWASP's GenAI Security Project, put it when unveiling the 2026 Top 10: the goal was never to build a model that "cannot be fooled" because realistically, given enough time and creativity, it always can be. The real goal is to build the system around the model so that when it's fooled, nothing important actually breaks.

Pull quote: "Stop trying to build a model that cannot be fooled. Build the system around it, so that when the model is fooled and it will be nothing important breaks." OWASP GenAI Security Project

That single reframe from prevent every failure to control the blast radius when failure happens might be the single most useful mental model available to any team thinking seriously about AI agent security right now. It's not about achieving perfect trust in the model. It's about designing so that one bad instruction can never cascade into a full compromise.

Teams running these agents in real production settings echo the same lesson, just from a more scarred, hands-on angle. Permission creep, more than any single dramatic exploit, is described again and again as the quiet killer. Groups that run AI agent "swarms" multiple specialized agents collaborating across a codebase say the discipline that actually catches problems is a scheduled permission audit, performed every single time an agent's task scope expands, not just at initial setup.

And there's one more honest confession worth repeating here, because it explains why so many teams skip the safeguard that would have saved them: the human review gate is always tempting to skip when the diff looks clean and the tests pass. It feels like overhead in exactly the moments it isn't. The teams who've actually caught real problems are, almost without exception, the ones who kept the gate anyway especially on the day it felt unnecessary.

Where This Goes Next

If 2025 was the year AI coding agents went from novelty to normal, 2026 looks like the year the security world finally caught up to that shift and 2027 is shaping up to be the year proper agent security stops being a differentiator and simply becomes table stakes, the way HTTPS did.

A few threads worth watching as this unfolds:

Vendor trust models are getting rebuilt, not just patched. Google's decision to force a breaking change into Gemini CLI's trust model, rather than ship a quiet fix, suggests more foundational redesigns are coming across the industry, not just incremental patches.
AI-specific penetration testing is becoming its own discipline. Distinct from traditional application security, and growing fast, as more incidents surface and more companies realize their existing tooling simply wasn't built for this threat model.
Regulatory frameworks are catching up. NIST's AI Risk Management Framework and ISO/IEC 42001 are increasingly cited as reference points for enterprise governance, and expect that to accelerate.
The confidence gap will probably close the hard way before it closes the easy way through more incidents making headlines, rather than through proactive investment arriving ahead of the pain.
Smaller teams need accessible tooling, not just enterprise platforms. Agentic AI adoption is spreading well past the Fortune 500, and the security tooling ecosystem hasn't fully caught up to that shift yet.

Here's the uncomfortable part, stated plainly: this category of vulnerability isn't going away soon. As agents gain longer memory, broader tool access, and more autonomy, the attack surface expands right alongside the productivity gains. That's not a reason to avoid the technology. It's the reason to treat it with exactly the seriousness you'd give any other system capable of executing code on your behalf because that's precisely what it is.

Frequently Asked Questions

Is Claude Code safe to use in production CI/CD?

Yes as long as you're running a patched version (2.1.163 or later) and following least-privilege configuration practices. The disclosed vulnerability is fixed, but the underlying lesson scope your agents carefully doesn't expire with the patch.

What is CVE-2026-12537?

An OS command injection vulnerability in Google's Gemini CLI container launcher, rated CVSS 10.0 the maximum severity score reachable through a crafted .gemini/.env file. Fixed in Gemini CLI 0.39.1 and run-gemini-cli 0.1.22.

Can a GitHub issue really compromise an AI coding agent?

Yes. That's precisely what Novee Security demonstrated at Black Hat USA 2026. An account with zero repository privileges influenced agent behavior through carefully worded issue text, reaching CI runner secrets in some cases.

What is "excessive agency" in AI security?

It's the risk category describing what happens when an AI system is granted more autonomy, permissions, or functionality than its actual task requires. It's now ranked third in OWASP's 2026 Top 10 for LLM Applications, having climbed sharply as agentic architectures have spread.

Should I disable AI coding agents on public repositories?

Not necessarily but treat any public-facing input (issues, PRs, comments) as potentially adversarial, and scope your agent's permissions tightly enough that even a successful injection can't do serious damage.

How is prompt injection different from a traditional software exploit?

Traditional exploits usually involve malformed code or stolen credentials. Prompt injection involves ordinary-looking text that manipulates an AI system's interpretation of its own instructions no malware, no credential theft required just to get started.

How often are new AI coding agent CVEs likely to appear?

Given the pace of growth in agent capabilities and adoption, expect this category to keep generating disclosures for the foreseeable future. Following vendor security advisories and OWASP updates is the most reliable way to stay ahead of it.

Key Takeaways

At Black Hat USA 2026, researchers showed that Claude Code, Gemini CLI, and Codex could all be manipulated through a single GitHub issue posted by a zero-privilege account.
Two vulnerabilities earned formal CVE tracking CVE-2026-12537 (maximum severity) and CVE-2026-54316 and all three vendors have shipped fixes.
This wasn't a one-off bug. It was a structural pattern that surfaced independently in three unrelated companies' products.
OWASP's 2026 Top 10, released the same week, confirmed the trend from a completely different angle: Excessive Agency is now the industry's third-ranked AI security risk, backed by real incident data for the first time.
A striking confidence gap exists across the industry: most organizations report incidents, while most executives still believe they're protected.
The fix isn't complicated in principle least-privilege scoping, human review gates, regular permission audits but it takes real, ongoing discipline to maintain as agent capabilities keep expanding.

Conclusion & What to Do Monday Morning

There's a version of this story you could tell as pure alarm: three of the biggest names in AI, all vulnerable to the same trick, all at once. But the more useful version is quieter, and more actionable. Every vendor patched fast. Nobody was hurt in the wild. And the real lesson treat your AI agents like the powerful, code-executing systems they genuinely are, not like a clever autocomplete with good manners is something any team can act on this week, not eventually.

The teams that come out ahead here won't be the ones who abandoned AI coding agents out of fear. They'll be the ones who kept using them, and simply stopped assuming that "default" meant "safe."

Tweetable quote: "Default doesn't mean safe. It just means untested by someone who wanted to get in."

Call-to-Action

Pick one, right now, before you move to the next tab:

If you manage the pipeline: Open your AI agent's permission settings today. Not this sprint today. Compare them against the eight-item checklist above. If you find even one "reader" agent with "doer" access, that's your first fix.
If you lead the team: Forward this article to whoever owns your CI/CD configuration, with one line: "Are we sure we're not #7 on this checklist?"
If you want a second set of eyes: An AI-specific security review is a small, bounded cost against a very unbounded mistake. Worth the conversation before your next major agent rollout, not after an incident forces it.

However you engage with it bookmark this page, share it with your engineering team, and subscribe so you catch the next disclosure before it catches you. In this space, there will be a next one. The only question is whether you read about it here, calmly, on a Tuesday morning or in an incident report, at 2 a.m., with your own name on it.

Search This Blog

Geopolitics with KP