Fake Sentry errors tricked Claude Code, Cursor and Codex agents into running attacker commands

Fake errors, real commands

Security researchers have demonstrated a prompt-injection attack in which a forged Sentry error event, planted through a credential Sentry documents as safe to expose, instructs AI coding agents to run attacker-chosen shell commands. The technique, which Tenet Security calls agentjacking, was published in June 2026 and covered by The Hacker News on June 12, according to a technical write-up on dev.to. In a controlled test against more than 100 organizations, Tenet reports an 85% success rate, with Claude Code, Cursor and Codex all acting on the planted errors. Tenet also identified 2,388 organizations whose Sentry DSNs were open to injection.

The attack chain

Sentry applications report crashes using a DSN, a URL-embedded key that browser SDKs must ship inside frontend JavaScript to work at all. Sentry's own documentation calls DSNs safe to keep public because they permit only submitting new events, not reading data. That write-only property was harmless while only humans read the error feed.

The attacker locates a DSN through site JavaScript, Censys scans of Sentry's ingest host, or GitHub code search, then posts a single crafted event to the ingest endpoint, which accepts it with no authentication beyond the DSN. The payload sits in the event's message field and context key names, formatted as markdown with a fake Resolution heading and an npx command, laid out to resemble the template Sentry's MCP output already uses.

Later, a developer asks the agent to fix unresolved Sentry issues. The Sentry MCP server, signed into the account over OAuth, returns real issue data that now contains the attacker's markdown. Per Tenet, the agent cannot distinguish a planted event from a genuine crash, and it executes npx against an npm package the attacker controls, running with the developer's privileges.

In Tenet's test the package was a validation probe: it inspected environment variables, checked the sizes of credential files such as ~/.aws/config and ~/.npmrc, looked for a VPN and sent two outbound POSTs to a beacon. Tenet says it retained none of the probe data. Each hop in the chain was individually permitted — Tenet's summary is that every step was authorized — and the company claims the approach sidesteps EDR, WAF, IAM, VPN, Cloudflare and firewalls, because there is no malware signature to catch: just an HTTPS request, a tool call and an unremarkable npx invocation.

Why prompt rules do not help

Tenet tested the obvious mitigation: instructing agents to disregard untrusted tool output. The payloads ran anyway, and Tenet's conclusion is that this cannot be fixed with a better prompt. The dev.to write-up notes that Tenet did not say which permission modes the agents used or whether developers clicked through approval prompts, but sandboxed, CI-based and internal-network agents were reached as well, so a sandbox helps only as far as what it denies.

Sentry's response

Tenet disclosed the issue on June 3, 2026, and Sentry replied the same day, acknowledging it while declining to fix the root cause, which Sentry called "technically not defensible" according to Tenet. A Cloud Security Alliance research note names the two root fixes Sentry turned down: authenticated ingestion, and sanitizing event content before the MCP server returns it. What shipped instead was a global content filter that blocks one specific payload string.

Authenticated ingestion is genuinely difficult for browser SDKs, which cannot keep secrets. Sanitizing is harder to dismiss: a draft pull request in Sentry's MCP repository wraps the attacker-writable parts of its issue-details tool in an untrusted-content tag, and it remained open as of November 7. Even if merged, the model still reads everything inside the tag.

Defenses at the last hop

The first five hops of the chain happen on systems the victim does not control; the final hop runs on the developer's machine, which is where the dev.to piece places the controls. Keep approvals on for shell commands, with ask rules for package runners such as npx and its equivalents. Avoid permission bypass modes outside isolated containers. Enable the agent sandbox with credential-file denies and a network allowlist that stops and asks on first contact with an unknown host rather than connecting silently.

Why it matters

Nothing here is specific to Sentry. Any MCP tool that returns text an outsider can write — issue trackers, support inboxes, log search — offers the same pathway, and the Cloud Security Alliance frames the injection route as architectural. Content that was inert when only humans read it becomes executable instruction once an agent holding a shell reads it, and Tenet's tests indicate prompting alone will not close that gap. The enforcement point has to move to the execution boundary: what the agent is allowed to run, not what it is told to trust.