Vercel: stolen session cookies fail off-device
Vercel is binding vercel.com logins to the device so a session cookie stolen by infostealer malware cannot be reused on another computer. Turn the control on when it reaches your team, and review CLI tokens and OAuth apps in the same pass.
By ZeroDay Times Desk2 min read
Vercel is switching on a control that makes a copied dashboard cookie fail on a second computer. The control is Device Bound Session Credentials, applied in stages to sign-ins at vercel.com, the console where teams deploy sites, applications, and AI agents. Chief technology officer Malte Ubl said the session is tied to a private key kept in the device TPM, the same hardware store a fingerprint reader uses. That key signs the cookie. The key is not something Vercel, the account owner, or malware on the laptop can export later.
The practical effect is narrow and useful. Information-stealing malware has turned browser cookies into a standard grab. A cookie that still works from any machine is a password that skipped the login page. Binding it to the device means the steal is no longer a portable login. Chrome already wraps cookies with App-Bound Encryption, which makes them harder to lift. The Vercel change is the next lock: a cookie that does leave the laptop should be rejected somewhere else.
Where the control is live
BleepingComputer reports that the binding currently works in Chrome on macOS and Windows. The rollout is slow on purpose, so OAuth applications do not break on odd cases. Teams that sign in through a connected app may see the protection later than teams that use a plain browser login.
A matching control, DPoP, is rolling out for the Vercel command-line tool. The CLI is the other place a developer session sits, often on a laptop that also holds cloud keys. A browser fix that leaves the terminal token unbounded is half a program.
Why a dashboard cookie is a production secret
Session theft on this platform is not a hypothetical. In April, Vercel said an intrusion that began with an employee’s Google Workspace account at Context.ai reached internal systems and environment variables that had not been marked sensitive. The company said a subset of customers was affected. Someone posing as ShinyHunters then tried to sell source code, access keys, and database material. Device binding does not rewind that incident. It cuts the resale value of the next cookie taken from a developer laptop.
What a team should do this week
When the binding is offered on an account that can deploy, accept it. Confirm it on the machines that actually publish, including contractor laptops. Until Chrome on macOS or Windows shows the control, treat a vercel.com session cookie as replayable.
Inventory OAuth apps that act on the Vercel account, and turn on the CLI binding when it arrives. Remove CLI credentials from shared build machines and from laptops that have had an infostealer alert. After a steal, revoke the session at Vercel. A copied cookie is an incident even when the new control is about to make the copy useless.
Mark environment variables that hold keys as sensitive, and rotate any value that lived in an unmarked variable around the April intrusion. Revoke the old value at the provider that honors it. A string changed only in the Vercel UI can still spend money at the model or cloud vendor.
Session binding is a platform change. The cookie on a compromised laptop is still the team’s problem until that laptop is clean and the old session is dead.
This briefing relies on public reporting by BleepingComputer and on Vercel’s public remarks about the session-binding rollout.
Corrections and tips:[email protected]

