Stolen Vercel deploy token ships a skimmer: roll the alias back

A stolen deploy token can ship harm to live visitors in seconds. With Vercel, a token that can promote to production lets an attacker put a client-side skimmer in front of every user.

How the attack works

The deploy token creates a new deployment from an unfamiliar IP and CLI fingerprint, outside the CI pipeline. It aliases that build to the production domain, replacing the live one. The production bundle now contains injected script that posts visitor form and field data to an external endpoint, and CSP and RUM telemetry show sustained beacons from end-user browsers. In ATT&CK terms this is T1195, Supply Chain Compromise, with T1059, Command and Scripting Interpreter, executing in the visitor’s browser.

Why it works

A single long-lived deploy token could promote any build straight to production with no approval gate, and there was no Subresource Integrity or strict CSP to constrain an injected script once it was live.

How to fix it

Production is an alias over immutable deployments, so the fastest correct move is to re-alias production to the last known-good deployment, which removes the skimmer from live users in seconds. Then revoke the deploy token so the attacker cannot redeploy over your rollback. Do not race a slow CI build against the live skimmer, and do not rely on a CSP block of one destination that the attacker can simply change. Bound visitor impact from the audit-log alias-change pair, on and off, and treat this as a supply-chain incident affecting visitors. As a class fix, gate production promotion behind the protected CI pipeline, scope and shorten tokens, require alias approval, and add SRI and a strict CSP.

Practice it

We built this as a GraphLattice Range scenario so responders can rehearse the instant alias rollback, the token revoke, and bounding the exposure window.