Fake Sentry issues used to trick coding agents into running malicious npm packages
A newly described attack injects fake Sentry error issues written as runbooks to manipulate coding agents like Claude Code and Cursor into installing typosquatted npm packages that exfiltrate environment variables.
Score breakdown
The attack demonstrates that the unauthenticated nature of Sentry DSNs creates an exploitable input channel for prompt-injection-style attacks against coding agents, and that the only control that worked in the reported case was the model's own judgment — a defense the post explicitly flags as unreliable.
- 01Attackers inject fake error logs via unauthenticated Sentry DSNs to create fake Sentry issues targeting coding agents like Claude Code and Cursor.
- 02Sentry DSNs are unauthenticated by design; anyone with the DSN can fire events into a project.
- 03Fake issues are written as runbooks instructing the agent to run a 'diagnostic' that is actually a typosquatted npm package.
A post on r/cursor by u/Any_Side_4037 describes a newly documented attack vector targeting AI coding agents. The attack works by exploiting the unauthenticated nature of Sentry DSNs: because most sites embed the DSN in the front-end for client-side error reporting, anyone who obtains it can inject arbitrary events into a project's Sentry instance. Attackers use this to spray fake error logs, generating fake Sentry issues written in runbook style. When a coding agent like Claude Code or Cursor picks up the issue to "fix" it, the suggested remediation is to run a typosquatted npm package that quietly exfiltrates the developer's environment variables. The fake issue is also dressed up with spoofed event metadata designed to look like agent permission flags, making the model believe it has been cleared to execute the command.
In the specific incident described, the agent caught the typosquat and refused to install the package, preventing the attack.
In the specific incident described, the agent caught the typosquat and refused to install the package, preventing the attack. However, the post argues this outcome was lucky rather than reliable, and raises the deeper question of where the correct defensive control belongs. The post draws a parallel to SQL injection — "don't trust external inputs" — but notes the problem is harder here because the DSN cannot be locked down without breaking client-side telemetry. The two mitigations discussed are restricting agent run permissions (which pushes everything to manual approval) and maintaining a package allowlist (which breaks when legitimate packages aren't listed), with neither presented as a clean solution.
Key facts
- 01Attackers inject fake error logs via unauthenticated Sentry DSNs to create fake Sentry issues targeting coding agents like Claude Code and Cursor.
- 02Sentry DSNs are unauthenticated by design; anyone with the DSN can fire events into a project.
- 03Fake issues are written as runbooks instructing the agent to run a 'diagnostic' that is actually a typosquatted npm package.
- 04The malicious package is designed to quietly exfiltrate the developer's environment variables.
- 05Fake event metadata is crafted to resemble agent permission flags, making the model think it has been cleared to run the command.
- 06In the reported case, the agent caught the typosquat and refused to install the package.
- 07The post identifies two imperfect mitigations: locking down agent run permissions or maintaining a package allowlist.
Topics
Summary and scoring are generated automatically from the original article. We always link back to the publisher and never republish images or paywalled content. Last processed Jun 9, 2026 · 17:05 UTC. How this works →