GhostCommit Exposes the Blind Spot in AI Code Review

By Paul Reid, VP of Adversary Research [ Join Cybersecurity Insiders ]

In June 2026, researchers at the University of Missouri-Kansas City’s ASSET Research Group disclosed an attack called GhostCommit. This style of attack hides indirect prompt-injection instructions as visible text inside a PNG committed to a code repository. The payload itself is inert, and only when a vision-capable coding agent reads the image, follows the instructions, and writes the contents of a seeded .env file into source code as an integer tuple. Two deployed AI code reviewers tested by the researchers, Cursor Bugbot and CodeRabbit, cleared the malicious pull request without a single flag. Neither tool produced a finding from the image; CodeRabbit’s default configuration explicitly excluded PNG files, while Bugbot returned no findings. The research was conducted in controlled repositories using seeded, non-production credentials; no real secrets were exposed.

GhostCommit joins a broader set of 2026 incidents showing how attackers can exploit the trust placed in agentic systems. Unlike JADEPUFFER’s use of an AI agent to conduct an intrusion or ClawHavoc’s poisoning of an agent skill marketplace, GhostCommit specifically targets the gap between AI code review and the coding agent that later consumes repository content.

Inside the attack

The mechanics are simple once you see them. A common file named AGENTS.md, the kind coding agents read automatically and treat as project policy, points to an image,  docs/images/build-spec.png. The file itself names no secret and describes ordinary build hygiene. 

The real instructions are embedded inside the PNG, rendered as plain, readable text that instructs the agent to read the repository’s .env file byte by byte, encode each byte as an integer, and write the result into the codebase as a Python tuple.  To make the instruction appear coherent with the rest of the repository, the researchers supplemented the image and conventional file with a fake provenance validator, CI logic, and a fabricated incident report. This cover story helped the pull request survive higher-level coherence checks. Both Bugbot and CodeRabbit flagged the instructions when they were written as plain text. Once the researchers moved those same instructions into the image, both reviewers returned no findings. CodeRabbit’s default configuration explicitly excluded PNG files, while Bugbot produced no findings from the image. In one controlled run, Cursor driving Claude Sonnet produced a 311-integer length tuple on its first attempt, encoding an entire seeded .env containing realistic but non-production API and database credentials.

What’s notable is where the attack succeeded and where it didn’t. The clearest example involved Sonnet 4.6: it leaked the seeded .env under Cursor and Antigravity but refused the same instruction under Claude Code. Claude Code also refused across every Claude model tested, while Opus under Antigravity wrote the secret and then removed it. The results indicate that the coding harness and its safety scaffolding materially shaped the outcome, rather than the model alone determining it.

The gap you inherit, not the one you build

I’ve spent many years investigating incidents and GhostCommit’s real lesson isn’t about images or PNGs. It’s a gap I’ve seen repeat across EDR, email gateways, and SIEM. The difference between having a control for this and testing what that control actually covers. I’ve seen teams discover after an incident that their email gateway never inspected encrypted attachments, or that a detection rule had gone quiet due to a schema change. Vendors often ship a set of default configurations. The default set excludes a category of file, a class of traffic, a type of behavior. Often no one modifies the default leaving a potential exposure gap. I call that threat debt. It accumulates every time a control’s actual coverage goes unverified, and it compounds quietly until that debt is exploited!

ASSET Research Group’s own review-gap survey found  6,480 pull requests in the 300 most active public repositories over a 90-day period, ASSET found that 73% of merged pull requests reached the default branch without substantive human review or bot review.  AI coding agents are increasingly being trusted with production code, but many security teams have not fully mapped or validated the controls surrounding them.

What continuous validation looks like here

This is the discipline that Continuous Threat Exposure Management (CTEM) was built to enforce. Don’t assume coverage, prove it, continuously, as the environment and the threat landscape both change. A one-time pen test or a vendor’s default configuration tells you nothing about what may happen next month, especially with tools that update weekly and agents that behave differently depending on the harness running them. Adversarial Exposure Validation is how you prove it, running the actual technique against the actual control and measuring what happens, rather than trusting a data sheet. An AI code reviewer is a security control now, whether procurement labeled it that way or not. It deserves the same validation discipline as anything else standing between an attacker and production.

Four things are worth doing this quarter: 

  • Test the reviewer, not just the code. Feed a known-bad instruction to your AI code review tool through a file type it doesn’t normally parse, an image, a binary asset, a config format outside its default scope, and watch what happens. Most teams have never run this test, because it never occurred to them that the reviewer itself needed reviewing.  Perform this testing only in an isolated repository with seeded canary credentials, restricted permissions, and no production secrets.
  • Map what “review” actually covers, in writing. AI code review tools have defined inspection boundaries, exclusions, and configuration defaults that teams should document and validate. It’s better to find out what before an attacker does.
  • Inspect semantically transformed outputs. Secret scanning should not be limited to credential-shaped strings. Development-pipeline controls should identify generated arrays, tuples, encoded blobs, or other data structures that reconstruct sensitive files when decoded.  In GhostCommit, the secret leaves the local development environment when the developer commits and pushes the generated module to a repository the attacker can read. The attacker can then retrieve the commit and decode the integer tuple.
  • Extend exposure validation to the development pipeline itself. Convention files, review tools, and the permissions an agent operates under are attack surface now, testable the same way you’d test a firewall rule or an email gateway.

The fix is not simply a smarter model. It is an architecture that examines every input the agent can consume, limits what the agent can access and continuously proves that the surrounding controls work. Otherwise, AI development pipelines will become the next major source of threat debt, accumulating quietly until an attacker decides to collect.

 

Join our LinkedIn group Information Security Community!

No posts to display