DEV Community

jamilxt
jamilxt

Posted on

A Fake Bug Report Can Make Your AI Coding Agent Run Attacker Code

#security #ai #devtools #cybersecurity

Someone submits a bug report to your error tracker. They do not need your password. They do not need repo access. They just need one credential that your frontend ships to every visitor by design. Days later, your AI coding agent reads that bug report, trusts it, and runs the attacker's code on your machine, with your permissions.

That is not a hypothetical anymore. On September 16, 2026, CERT/CC published vulnerability note VU#212479, tracking CVE-2026-90999 in Sentry's Seer feature. The advisory describes arbitrary code execution inside the coding-agent environment, with access to connected source repositories. There is no patch yet. The vendor's status is listed as "Unknown."

If you use Sentry and have an AI agent wired to it, this affects your setup today. Even if you do not use Sentry, the pattern behind this vulnerability applies to almost every AI agent integration being built right now. Let me walk through how the attack actually works, why no security tool catches it, and what you can do about it.

A quick disclosure: this article is based on the CERT/CC advisory, Tenet Security's June 2026 research, and the Cloud Security Alliance's analysis, all linked inline. I have not reproduced the attack myself, and no real-world intrusions are documented from it. The numbers below come from controlled research testing.

What happened this week

Sentry is an error-monitoring platform. Your application catches an exception, Sentry records it, and your team triages the issues. Seer is Sentry's AI layer: it performs root-cause analysis on incoming errors and can hand the problem to a coding agent like Claude Code, Cursor Cloud Agents, or GitHub Copilot to propose a fix.

The CERT advisory describes what happens when that handoff is enabled. The workflow, quoted from the advisory:

  • Sentry ingests attacker-generated exception events submitted through the public DSN.
  • Seer evaluates whether the event represents an issue eligible for automated remediation.
  • Seer generates a root-cause analysis using attacker-controlled event fields, including exception messages, stack traces, source context, and breadcrumbs.
  • The generated analysis is embedded directly into the initial prompt provided to the coding agent.
  • The coding agent interprets the fabricated analysis as a legitimate description of the victim's codebase.
  • During its investigation, the coding agent downloads and executes a package controlled by the attacker.
  • The package executes within the coding-agent environment before any human review of a pull request.

Read that last bullet again. The malicious code runs before a human ever sees a PR. The whole point of reviewing an agent's fix is that a person checks the output. This attack does not wait for that step.

The one credential that starts it all

The entry point is called a DSN, short for Data Source Name. It is the string in your Sentry configuration that tells your app where to send error reports. Sentry documents it as safe to embed in frontend JavaScript, because a DSN is write-only: it can submit events, but it cannot read anything.

That design made perfect sense before AI agents existed. Browsers need to report errors without a login. The DSN being public was a known, accepted trade-off.

The problem is that a public write endpoint plus an AI reader equals an injection channel. Anyone who finds your DSN, from view-source on your website, from a public GitHub repo, or from scanning services like Censys, can POST a fully crafted error event to your Sentry project. Error message, stack trace, breadcrumbs, context: every field is attacker-written. Sentry accepts it with an HTTP 200 and processes it exactly like a real crash from your app.

Tenet Security, the research team that documented this attack class in June 2026 and named it "agentjacking," found at least 2,388 organizations with publicly exposed, injectable DSNs. Among the Tranco top one million websites, they identified 71 injectable DSNs. Their testing confirmed agents at more than 100 organizations acting on injected errors, including a Fortune 100 company.

Why the agent cannot tell the difference

Here is the part that makes this genuinely hard, not just another XSS-style bug.

The injected event does not contain an obvious command like "run this." Instead, the attacker formats the event's markdown, headings, code blocks, and structured text, to look identical to Sentry's own system-generated diagnostic templates. Hidden inside is a fake "Resolution" section suggesting a diagnostic command, typically an npx invocation that fetches an attacker-controlled npm package.

When a developer later asks their agent something completely ordinary, "fix the top Sentry issue," the agent queries Sentry through its MCP server, receives the injected event next to real ones, and reads the fake resolution the same way it reads real guidance. Tenet's testing across Claude Code, Cursor, and OpenAI Codex CLI found an 85 percent exploitation success rate. The agents executed the attacker's package with the developer's full privileges.

Once running, the payload can read whatever your dev machine holds. In Tenet's controlled proof of concept, accessible targets included environment variables, AWS credentials, GitHub and GitLab OAuth tokens, npm registry tokens, Docker configuration, Kubernetes cluster tokens, and CI/CD secrets.

And here is why nothing catches it: your EDR sees a trusted process, your AI agent, running a legitimate package-manager command, as you. No malicious binary is dropped. No process injection happens. No policy is violated. Tenet reports the attack sailed past EDR, WAF, IAM controls, and VPN monitoring, because the agent only performed operations its developer was authorized to perform. The attacker never touched your infrastructure. There was no breach in the traditional sense at any point.

Sentry's position, and the new twist

When Tenet disclosed this in June 2026, Sentry's leadership responded the same day, acknowledged the issue, and declined to fix it at the root, describing a platform-level fix as "technically not defensible." Sentry did deploy a content filter blocking the specific payload string from the research, which Tenet and the CSA both note addresses one known string, not the pathway. Any attacker who rewrites the markdown can get around a string match.

The September development is what changes the calculus. The new advisory from agyn researchers Nikita Benkovich and Vitalii Valkov covers a different, more automated path: it does not need a developer to ask their agent to look at Sentry issues. When Seer's automatic remediation is on, Sentry itself analyzes the attacker's event and feeds the resulting analysis straight into the coding agent's initial prompt. The human is not even in the loop anymore. CERT's suggested mitigations, with no patch available yet: disable automated remediation flows, restrict coding-agent package installation, or disable Seer handoff entirely, plus defensive filtering of telemetry before Seer analysis.

At publishing time, EPSS estimates a 0.2 percent exploitation probability for CVE-2026-90999. No real-world intrusions are documented. But EPSS measures probability, not impact, and the impact here is developer-workstation compromise and repository access.

The pattern behind Sentry: your tools have input channels you forgot about

Step back from Sentry specifically, because the CSA's analysis makes the key point: this is not a flaw in Sentry's code. It is three individually reasonable design decisions that become dangerous combined:

  • An ingest endpoint that accepts payloads from anyone holding a public credential.
  • An MCP-style server that forwards that data to AI agents as tool output, with no integrity check on the content.
  • Agents that treat tool output with the same authority as operator instructions.

Now audit your own stack against that pattern. Almost every AI agent integration follows it. A Slack bot that lets an agent read messages? Messages can come from outsiders. A GitHub integration where agents act on new issues? Anyone can open an issue. Monitoring dashboards, customer support tickets, form submissions, webhook payloads: any external input that flows into an agent's context is now a potential instruction channel. Sentry is the demonstrated case, not the exception.

What to actually do: a hardening checklist

Here is the save-worthy part. If you run AI coding agents connected to any external data source, work through this list. The first three items matter most.

1. Cut the automatic handoff. In Sentry's settings, Seer's automation is configurable. Disable automatic remediation and Seer-to-agent handoff until vendor guidance lands, so no attacker event can reach an agent without a human choosing to investigate. Organizations that want all generative AI features off can use the "Show Generative AI Features" toggle in organization settings.

2. Require human approval for package installs and shell commands. Configure your agent to never run an npm/npx install or arbitrary shell command without an explicit confirmation. In Claude Code, for example, permission rules can deny commands by pattern, so package execution always needs a human. The following is an illustrative example of deny rules in a project settings file:

{
  "permissions": {
    "deny": [
      "Bash(npx:*)",
      "Bash(npm install:*)",
      "Bash(curl:*)"
    ]
  }
}
Enter fullscreen mode Exit fullscreen mode

The fake resolution in this attack class works precisely because the agent runs an install command unprompted. A deny rule turns that step into a human decision.

3. Sandbox the agent and control network egress. Run coding agents in containers with restricted filesystem access, minimal environment variables, and limited network access. Deny egress except package registries you trust, and explicitly block cloud metadata endpoints, the EC2 instance metadata service being the classic one. Even if an agent is manipulated, least privilege slashes what the payload can steal. Rotate and scope credentials: short-lived cloud tokens, registry credentials provisioned per-session, nothing long-lived sitting in the agent's environment.

4. Audit and rotate your DSNs. Search your public repos and bundles for Sentry DSNs. Tenet found them via browser source, GitHub code search, and Censys indexing of ingest.sentry.io. Rotate any that are exposed, and consider proxying client-side error reporting through your own server so the DSN never ships to browsers. That removes the primary discovery mechanism the attack depends on.

5. Treat tool output as untrusted data, not instructions. If you build agents rather than just use them, this is your takeaway. Your system prompts should tell the agent explicitly that content from MCP servers, issues, and telemetry is data to analyze, never instructions to follow. It is mitigation, not a guarantee, prompt-level defenses are bypassable, but combined with approval gates it raises the cost substantially.

6. Watch the chain, not just the events. Alert on the sequence: an agent tool-call touching external content, followed shortly by a shell command or filesystem write. Each step alone looks legitimate. The sequence is the signal.

None of these is perfect alone. Together they break the chain at multiple points, and this attack needs the whole chain intact.

The uncomfortable takeaway

For a decade, we taught developers that error telemetry is boring, internal, trusted data. Whole toolchains were built on that assumption, and AI agents inherited it. CVE-2026-90999 is the industry's formal notice that the assumption is dead: anything an outsider can write into, your agent can be made to read, and what your agent reads, it tends to do.

The fix is not one patch, because there is no patch. It is a posture change. External data entering an agent's context should get the same suspicion you give a form field on a public website. Treat every integration that surfaces outsider content to an agent as an attack surface, because as of this month, it demonstrably is one.

I write about AI infrastructure, developer tools, and the security problems nobody planned for, every week. Subscribe, it's free.

Do you have an AI coding agent connected to Sentry or any error tracker? Check your Seer settings tonight, then come back and tell me what you found in the comments.

Sources:

Top comments (0)