A Roblox cheat, an OAuth grant, and a $2M Vercel leak

On April 20, Vercel disclosed that a "highly sophisticated" attacker had breached its internal systems through a compromised third-party AI tool called Context.ai, and accessed non-sensitive environment variables belonging to a subset of customer projects. CEO Guillermo Rauch described the attackers as "significantly accelerated by AI" and asked customers to rotate any credential that had been marked non-sensitive. A group calling itself ShinyHunters is now trying to sell the stolen data for $2M on BreachForums.

The ransom number is the headline. The attack chain is the lesson. Hudson Rock traced the infection back to February 2026, when a Context.ai employee searched for Roblox "auto-farm" scripts and game-exploit executors, downloaded one, and picked up Lumma Stealer — a commodity infostealer that harvests browser cookies, saved credentials, and OAuth tokens. CyberScoop and SpecterOps later reconstructed the rest. What Lumma extracted wasn't just a Context.ai password; it was the full set of corporate credentials cached in the browser — Google Workspace sessions, Supabase keys, Datadog logins, Authkit tokens.

From there the attacker pivoted into Context.ai's AWS environment, read the OAuth tokens Context.ai held on behalf of its customers, and found a Vercel employee who had once signed up for Context.ai's "AI Office Suite" using their corporate Google account — and clicked the "Allow all" scope box. That single consent, months earlier, was the only primitive the attacker needed. They minted a session as that employee, walked into Vercel's Google Workspace, and from there into Vercel's internal product API, where they enumerated and decrypted every environment variable a customer had not explicitly marked as sensitive.

Four things about that chain deserve calling out, because each maps onto a specific control we shipped in Bromure Enterprise this week. We are not going to claim the release would have stopped the breach outright — it would not have. What it would have done is break the chain at four separate points, any one of which is enough.

The personal laptop was load-bearing

The single most under-reported detail in the public write-ups is that the infected machine was a personal device. The Context.ai employee was searching for Roblox exploits — not a typical corporate task — and the infection landed on a machine that was probably doing both work and personal browsing. Lumma Stealer doesn't care which profile a cookie belongs to; it reads every Chrome and Edge credential file it can find, and ships the lot.

This is the central pattern of the BYOD era. The host is unmanaged. The work cookies are in the same cookie jar as the Roblox cheat the user just downloaded. An EDR agent might or might not be installed; on a personal machine, it is very unlikely to be. And even when it is, Lumma is routinely observed bypassing off-the-shelf AV.

Bromure Enterprise's answer is a managed VM on an unmanaged host. IT issues a Bromure work profile. The employee installs Bromure on their personal laptop, signs in with the corporate IdP (Google Workspace, Okta, Entra, Authentik), and the work profile boots as its own Linux virtual machine. That VM has its own kernel, its own filesystem, its own Chromium profile directory. Corporate cookies, corporate saved passwords, and corporate OAuth refresh tokens live inside that VM. A stealer running on the host macOS or Windows — harvested via a Roblox download or anything else — cannot enumerate, read, or exfiltrate them. There is no shared Chrome profile on disk for it to steal. The cookie jar is inside a VM image the host OS treats as an opaque disk file.

That's not a theoretical separation. It is the entire point of the architecture. The host can get popped all day; the work browser is in a different computer.

The "Allow all" click was the real trophy

Look at the attacker's path closely. The stealer harvested credentials for Google Workspace, Supabase, Datadog, Authkit. Those were useful for pivoting inside Context.ai. But the thing that reached Vercel wasn't a stolen password — it was an OAuth token. Specifically, the token minted when a Vercel employee signed up for Context.ai's AI Office Suite, clicked through the Google consent screen, and approved the "Allow all" scope bundle. That consent was months in the past. It was never re-evaluated. It sat there, valid, waiting.

This is the OAuth visibility gap SpecterOps called out: trust edges created by individual employees clicking consent screens operate entirely outside IT's provisioning workflow. The path was open before anyone knew to look for it.

Bromure Enterprise narrows that surface in two directions at once.

The authorized SaaS tile list is the choke point on the way in. Admins publish the set of sanctioned work apps to every enrolled user's Work home page. Those tiles are what employees click to onboard onto a new tool. Context.ai wasn't on that list at Vercel — it couldn't have been; it was an individual employee's experiment. Without a tile, there is no one-click sign-up flow inside the managed work profile. The employee can, of course, still navigate to Context.ai manually; that is where the second control kicks in.

The work profile is SSO-gated and its consent surface is visible. OAuth consents initiated from a managed Bromure work profile happen through the corporate IdP, under admin policy. An admin who wants to gate which third-party apps can receive Google Workspace scopes at all — which every Google Workspace admin should be doing, and almost none actually are — has their enforcement endpoint inside the Bromure policy engine, not scattered across whatever each employee happened to click weeks ago. The "Allow all" checkbox stops being a surprise that surfaces eighteen months later during an incident response.

None of this retroactively revokes an OAuth grant that was issued before the employee moved to Bromure. But going forward, the category of "an employee granted broad Google scopes to a random SaaS app I've never heard of" is visible, and gateable.

Afterwards, the audit log is the only way to scope the damage

Vercel's public bulletin is honest about what their investigation found: the attacker enumerated and decrypted environment variables from a subset of customer projects. The scope is still being refined. The reason it's still being refined is that reconstructing "what did the employee account actually read between late March and mid-April?" from Google Workspace audit logs plus Vercel's internal product logs is a forensic reconstruction project, not a query.

This is the gap Bromure Enterprise's per-request audit log is designed to close. Every HTTP request made from every work session, across every enrolled device, is logged centrally: user, URL, verb, timestamp. "Who sent credentials to evil.com between 8 am and 8:15 am yesterday" is the example we used at launch. A better example this week: "For each environment variable endpoint on our Vercel product API, who hit it, from where, and when, across the last ninety days." A query, not a project.

This is the EDR-meets-web-audit-log piece. EDR answers the same question for native processes: what did this process touch? Bromure answers it for browsing: what did this user's browser touch? In an incident like Vercel's, where the attacker's footprint is entirely inside a compromised browser session, the EDR answer is empty and the Bromure answer is the incident timeline.

Data-exfil controls are narrow here — and that's honest

We want to be careful about where Bromure Enterprise helps and where it doesn't. The copy-paste, file-download, screenshot, and local-network controls are real, and they are real wins for data exfiltration in general — a compromised tab in a managed profile can't drag customer env vars into scp on the host, or screen-grab them, or upload them to an LAN peer. For the Vercel chain specifically, though, the exfiltration step happened entirely over the wire from Vercel's own backend to an attacker-controlled endpoint. The attacker was making authenticated API calls, not dragging files out of a browser window. The paste/download/LAN controls wouldn't have caught that.

What would have helped, and is listed in the per-request audit log above, is the record of the API calls themselves. Data-exfil controls are the second line; the first line is making sure the attack never gets to mint a session in a managed browser in the first place.

What Bromure Enterprise doesn't do

Three honest limits, because the story deserves them.

It doesn't stop malware on an unmanaged personal host. A Roblox cheat downloaded outside the Bromure VM is still a Roblox cheat installing infostealer malware on the user's personal OS. Bromure doesn't clean that up. What it does is make sure the malware's yield, for the attacker, is only the user's personal cookies — not their corporate ones.

It doesn't retroactively un-grant OAuth scopes. Consents issued months before the company rolled out Bromure Enterprise are in Google Workspace's grant list, not ours. The right operational move after deploying Bromure is still an audit of existing third- party app grants — we help you prevent the next one, we don't rewrite the last one.

It doesn't replace the discipline of scoping. The Vercel employee clicked "Allow all." If a future employee clicks "Allow all" on a sanctioned tile, the grant is still broad. Bromure makes the surface visible and the enrollment path narrower; it does not substitute for an admin deciding which Google scopes are and are not allowed for a given category of app.

The browser-first argument isn't "no attacks can happen." It is that the highest-leverage control point, for the entire category of attacks that route through a user's browser session, is the browser itself — and the browser happens to be the one piece of enterprise software that has never had a proper management story on unmanaged devices.

The shape of the fix

Supply-chain breaches through SaaS OAuth grants are the modern equivalent of VPN-credential stuffing attacks from ten years ago. Both are consequences of a trust edge that was cheap to create, hard to inventory, and impossible to revoke in a timely way when the counterparty got popped. Vercel's bulletin is careful and honest; the chain it describes is not Vercel's fault. It is what happens when the same browser on the same personal laptop holds the employee's corporate session, their Roblox download history, and their accumulated "Allow all" consents for every AI tool they experimented with last quarter.

The structural answer is to give the work session its own computer. Not a second laptop — a second machine, materialized on the same laptop, with its own kernel, its own filesystem, its own cookie jar, its own policy engine, its own audit tap into central logging. That is what Bromure Enterprise is. If you run IT at a company whose employees routinely grant OAuth scopes to third-party SaaS apps — which is to say, every company — this week's Vercel bulletin is the reason to put it on the shortlist.

---

Primary sources

• Vercel security bulletin — April 2026 incident
• Hudson Rock / InfoStealers — tracing the Lumma infection at Context.ai
• SpecterOps — Vercel breach as an identity attack path
• CyberScoop — Roblox cheats as the initial vector
• TechCrunch — Vercel confirms the incident