Can a fake Sentry issue trick your coding agent into running a malicious npm package?

Saw a writeup this week about a new attack aimed at coding agents (Claude Code, Cursor, etc) and it's annoying in how simple it is. Attackers spray fake error logs to generate fake Sentry issues. The issue is written like a runbook, so when your agent goes to "fix" it, the suggested fix is to run a malicious package that quietly exfiltrates your env. The reason it works: the Sentry DSN is unauthenticated by design. Most sites embed the DSN in the front-end for client-side error reporting, and there isn't really a way around that if you want client-side telemetry. So anyone who has the DSN can fire events into your project. The attacker writes the fake issue to read like: "Runtime issue, no code change needed, just run this diagnostic." The "diagnostic" is a typosquatted npm package. They even dress up the event metadata to look like agent permission flags so the model thinks it's been cleared to run the command. What saved the engineer in this case was the agent itself catching the typosquat and refusing to install it. The net held this time, but I wouldn't want my whole defense to be "the model probably notices." The part I keep chewing on is where the control even belongs. "Don't trust external inputs" was the lesson with SQL injection and it still holds, but here the input is a Sentry issue and the executor is your agent, so I'm not sure which layer you fix it at. The DSN can't really be locked down, so that leaves the agent's run permissions or a package allowlist. Lock down permissions and you're approving everything by hand; lean on the allowlist and it breaks the moment something legit isn't on it. What would have caught this in your setup? Because "the model noticed the typosquat" feels like a control I don't want to depend on. submitted by /u/Any_Side_4037 [link] [留言]