Vercel breach traced back to one employee signing into Context.ai with an "Allow All" Google Workspace grant, data listed on BreachForums for $2 million

Posted by juliarmg@reddit | sysadmin | View on Reddit | 44 comments

Putting this here because it is a very Monday-morning story and the OAuth angle has not gotten enough attention yet.

Vercel disclosed a breach on April 19-20. ShinyHunters listed the data on BreachForums for $2 million. The headline finding. A Vercel employee signed up for Context.ai using their enterprise Google Workspace account, granted "Allow All" permissions during the OAuth consent dance, and moved on with their day. An attacker who had previously compromised Context.ai AWS environment pulled that OAuth token out of the vendor, reused it, and walked into Vercel systems to pull environment variables.

The timeline is worth tracing because every step is something a normal-sized team could miss.

In February 2026, a Context.ai employee downloaded a Roblox auto-farm script on a work device. The script carried Lumma Stealer. In March, the attacker pivoted from the resulting credentials into Context.ai AWS environment and found stockpiled OAuth tokens, including the one belonging to the Vercel employee. On March 27, Google removed Context.ai Chrome extension after discovering a second embedded grant for Drive files. In April, the attacker used the Vercel token to access Vercel infrastructure and exfiltrate environment variables. The data hit BreachForums a couple weeks later.

Vercel described the exposed env vars as "non-sensitive." If you have shipped anything in the last five years, you know how much weight that word is carrying. Non-sensitive generally means "not the obvious secret-store entries," and yet env vars routinely carry API keys, DB creds, signing keys, third-party tokens. Vercel sits upstream of a lot of production traffic. If the attacker had weaponized GitHub or npm tokens inside that haul, this goes from disclosure post to supply-chain event.

Guillermo Rauch blamed AI-assisted tooling for the attacker operational speed. Take that for what it is worth, CEOs have motive, but the broader pattern matches what I am seeing elsewhere. AI-mediated analytics tools sit at the center of a hub of OAuth grants with wide scopes, usually at companies that are two years old and do not have mature security. They are the richest pivot surface in the stack right now.

The operational lesson I am walking into this week.

Go look at your Google Workspace or Microsoft 365 third-party app list. Filter by grants with Drive, Gmail, or Admin scopes. Every one of those is a Vercel-shaped incident waiting for the vendor to get popped. Revoke anything nobody has used in 60 days. Downgrade "Allow All" to least-privilege where the vendor supports it. Turn on workspace-wide restrictions on which OAuth scopes end users can consent to without admin approval. Google lets you configure this, most orgs never turn it on.

Assume Context.ai is the first one we know about, not the last. If your own org runs an AI analytics or AI-assistant SaaS with a Workspace integration, treat its AWS posture as your AWS posture.

Curious what noise anyone else is finding inside their OAuth grant review this week, and what policy is being used to decide what gets revoked.

https://elephas.app/resources/vercel-got-hacked-context-ai-2026

[-]

tankerkiller125real@reddit

If you're using Entra ID just block all user app registrations and require admin approval for any permissions more than email and openid scopes.

[-]

jonblackgg@reddit

You can do the same with workspace too under security -> API access iirc. Workspace doesn't have a request flow, but what you can do is drop a link to a Google form in there for people to provide information :)

[-]

oxidizingremnant@reddit

The request flow is a bit limited on info for Google, but you can review pending app requests in the admin console.

https://knowledge.workspace.google.com/admin/apps/review-and-manage-third-party-app-access-requests

[-]

jonblackgg@reddit

Nice, I didn't realise they added something more for it now :)

[-]

thortgot@reddit

Not having a workflow to handle requests seems odd. Its a trivial implementation.

[-]

jonblackgg@reddit

Way I see it, your users are going to see that block screen, you don't have a lot of customisation other than text. Ah the info they need to supply will be there live anyway.

[-]

progenyofeniac@reddit

I’m APPALLED more places don’t do this. Yes, it’s a headache, but give people a ticket to request approval and let it be known all grants will be reviewed through that ticket prior to approval.

People get used to it.

[-]

Fratil@reddit

It's more appalling that M365's default security posture is to let user's delegate their access to any random 3rd party with a single click, who are then allowed to bypass any conditional access applied to the user's account.

[-]

Absolute_Bob@reddit

The defsults leave all kinds of holes open and secure score doesn't help as much as some people want to think it does. MS wants people to be able to enroll their own unknown devices without help, spin up their own entra tenants without assistance, right click and share anything they want with "anyone with the link" access....it's pretty insane and for awhile there weren't even options to restrict a lot of it.

jfoust2@reddit

Exactly what sort of environment variables, from where?

steveoderocker@reddit

I don’t understand how the oAuth token the vercel employee consented to, was used to pivot into vercel systems. Was the employee an admin of the workspace? Yes they allowed all permissions, ur wouldn’t the blast radius be their account?

travelingcpuman@reddit

I also don’t. There’s no such thing as an “approve all” grant. At least I’ve never seen it, and if it does exist, that employee would have had to accept an unsafe app warning because there’s no way Google would approve an app with all permissions without a whole bunch of checks, unless it was marked internal only and you were on the testing email list. I know because I’ve gone through the approval process.

cfmdobbie@reddit

Putting this here because it is a very Monday-morning story

Okay, who else checked their calendar in a panic?

HotTakes4HotCakes@reddit

every step is something a normal-sized team could miss.

Ok, fair enough, let's hear it. Maybe someone on my team is doing this exact kind of work.

Context.ai employee downloaded a Roblox auto-farm script on a work device.

I'm going to stop you right there.

itishowitisanditbad@reddit

I always love the "It can happen to anyone" and then they describe a series of events that happened because of terrible security setup.

Then in turn people will use the "everyone learns somehow!" thing as if destroying businesses is the ONLY method to learn the right way to do something and completely spits in the face of anyone actually capable, suggesting they obviously did all the same massively stupid mistakes when they didn't.

Hoooooooar@reddit

Our stock has plummeted and we might possibly be going out of business....... because of our shitty leadership and poor security?

No because of roblox, roblox did this.

AndyceeIT@reddit

a Context.ai employee downloaded a Roblox auto-farm script on a work device

Good lord, what a start to the story

Smith6612@reddit

When I see Roblox mentioned anywhere in a security incident report, the first thing I say is "Ooof!"

NovaCalendar@reddit

I appreciate the joke here. (Ooof is a sound from Roblox)

lulbob@reddit

so very curious what position this employee held

m00ph@reddit

Probably a dev of some sort. I really want to hate on people, but you have to be aware of security to realize how bad things are, and most people aren't.

OMGItsCheezWTF@reddit

A Dev has a responsibility to be a security leader, you can't develop effectively without a detailed grounding in application security and that should naturally lead to wider learning about the security ecosystem of computing in general.

A good developer should be able to hold a good conversation about application security, the should be able to at least take part in a conversation about network security

A good developer should know they don't install fucking Roblox farmers on their fucking laptop lol

Archer007@reddit

A Dev has a responsibility to be a security leader, you can't develop effectively without a detailed grounding in application security

lol

FluidGate9972@reddit

Just watched a Youtube video about Claude setting up automated trading workflows and when Claude generated a cron script to run stuff at specific times and showed him the cron output, he literally said "I don't know what any of this means but I'm sure it will schedule things somehow" and continued on with his day.

We are all doomed.

DegaussedMixtape@reddit

I recently responded to a breach that started from password scraping related to a Roblox installer on a corporate device. His title was IT director and he claimed that sometimes he "has to play to help his kid in-game". They’re out there.

Yeah, 15 years ago I did plenty of personal stuff on work devices (you expect me to not check my personal Gmail for the 12h I'm out of the house?), now I prefer to not use the work guest WiFi for my personal devices (I don't really trust them), and I don't do anything beyond emailing to a personal email address from a work computer.

This is why I have unlimited data on my phone. I trust my employer's guest WiFi as far as I can throw it but I trust my wireguard connection through my mobile phone provider to my home network (and out over the internet) a lot more.

Fun_Structure3965@reddit

you can always wireguard through your guest WiFi

Justin_Passing_7465@reddit

Unless the guest WiFi is configured to block Wireguard packets.

general_blightmaw@reddit

Is this satire?

That you're sure your boss isn't monitoring what websites you hit on your personal device on WiFi they control? Probably not, but some certainly are.

fulafisken@reddit

I always assume an employer can see the screen of my work work laptop at all times. It is their computer, not mine. Same with any if their networks. My own device with a VPN or 5g connection is used for private matters.

TylerDurdenFan@reddit

I do the same, so I doubt it.

_mnz@reddit

That‘s why iam insisting nit to use the company accounts for administration

tarkinlarson@reddit

For transparency, OP is the founder of the app in the link he's provided.

MeetJoan@reddit

The OAuth grant review pattern is the right move. A couple of things worth adding:

Forgotten grants are the dangerous ones - apps connected 3+ years ago by people who've left, abandoned trials, interns. Anything unused for 12+ months with broad scopes should be revoked by default, not reviewed.

Google Workspace's "Manage Third-Party App Access" controls are genuinely useful but most environments default to permissive. Setting "Trusted" status explicitly and blocking unverified apps from restricted scopes catches a huge chunk of the risk.

Same pattern exists in Microsoft 365 Enterprise Apps. Worth running an Azure AD audit log review for consent grants in the last 6 months while you're at it.

a detailed breakdown of everybody’s bill 😬