Why revoking a Sentry token does not contain the breach

Sentry holds two sensitive things: source maps that let an attacker reverse-engineer your app, and error events that too often capture secrets in request bodies, headers, and local variables. A stolen auth token can reach both.

How the attack works

The token starts calling the Sentry API from an IP and user-agent never seen for it. It downloads the project’s uploaded source-map release artifacts, enabling de-minification of the production bundle, then pages through error events whose payloads contain unscrubbed tokens and connection strings. With the de-minified code revealing internal endpoints, targeted probing follows using a token lifted from those events. In ATT&CK terms this is T1552, Unsecured Credentials, alongside T1213, Data from Information Repositories.

Why it works

Event data was never scrubbed, so secrets reached Sentry in the first place, source maps were broadly accessible, and the auth token was broadly scoped and long-lived. Once those secrets land in stored events, they sit there independently of the token that wrote them, ready for anyone who can read events.

How to fix it

Revoke the token to stop further reads, but understand why that alone is not containment: the attacker already pulled source maps and read secrets from events, and those secrets are independently valid. You must rotate every secret that appeared in events, then restrict source-map and event access. Deleting the project is the wrong reflex, it destroys the audit trail you need. Scope what was actually accessed from the Sentry audit and event-access logs, not from token scopes. As a class fix, enable server-side data scrubbing so secrets never reach events, restrict source-map artifact access, scope and shorten tokens, and review what the SDK transmits.

Practice it

We built this as a GraphLattice Range scenario so developers can rehearse revoking the token, rotating the secrets already captured in events, and scoping the access from the right log.