Anatomy of the Context.ai → Vercel Compromise

TL;DR

On 2026-04-19, Vercel disclosed an internal breach whose initial foothold was a compromised Google Workspace OAuth app belonging to Context.ai — Joseph Semrai's AI-native office suite. The OAuth client ID Vercel published — 110671459871-30f1spbu0hptbs60cb4vsmv79i7bbvqj.apps.googleusercontent.com — was tied by independent researcher Jaime Blasco to a now-removed Chrome Web Store extension under the same Google account. The most probable root cause is therefore not a leaked OAuth client_secret but Chrome Web Store developer-account phishing of the same template that compromised Cyberhaven and 34 other extensions in December 2024.

This piece adds three things that have not been put together in one place publicly:

1. Three different companies have used the "Context" / context.ai brand. Conflation of them in early reporting muddied which entity was actually breached.
2. The current operator of context.ai, Explore Interfaces Inc., publishes no DMARC record at all (_dmarc.context.ai returns NXDOMAIN authoritative on Cloudflare's nameservers). That gap makes the prologue to a Cyberhaven-style phish — internal-impersonation email to a Context developer — practically uncontested.
3. This is the third SaaS-OAuth supply-chain incident fitting the same template in eight months (Salesloft / Drift, Aug 2025; Cyberhaven, Dec 2024; Context.ai, Apr 2026). Treat it as a category, not an isolated event.

We disclosed the DMARC gap publicly to Joseph Semrai (@josephsemrai) on 2026-04-20 with a follow-up signal to Vercel CEO Guillermo Rauch (@rauchg) the same day.

The brand-collision problem

Before reconstructing the breach, the entity needs to be pinned down. Two distinct "Context" organizations sit at the center of the story, and early reporting conflated them.

The OAuth client ID published in Vercel's incident IoC list — 110671459871-30f1spbu0hptbs60cb4vsmv79i7bbvqj — sits inside Google Cloud project number 110671459871. The project was active when Vercel disclosed; the OAuth app has since been deleted. Whichever entity controlled that GCP project at the moment of compromise is the entity whose security posture matters here. Based on the active product footprint, customer integrations, and Chrome Web Store extension surface, the controlling party is Explore Interfaces Inc. (Semrai's company), not the OpenAI-acquired entity.

For the rest of this piece, "Context" means Explore Interfaces.

What Vercel disclosed, and what it actually means

Public timeline

What ShinyHunters claim to be selling (unverified)

Multiple Vercel employee account accesses, source code, API keys, NPM tokens, GitHub tokens, and data from Vercel's internal Linear and user-management systems. Other actors associated with the broader ShinyHunters brand have told BleepingComputer they are not involved, suggesting the "ShinyHunters" handle may be reputational name-drop rather than confirmed attribution.

What Vercel confirmed

A limited subset of customers was impacted. Environment variables not flagged as sensitive were readable; values explicitly flagged sensitive were not. Next.js, Turbopack, and Vercel's open-source projects cleared a supply-chain audit. Recommendation: rotate any secret stored in a non-sensitive env var.

What Rauch said publicly

The initial access vector was a Vercel employee's Google Workspace account, which was compromised through Context.ai's broader OAuth compromise. The attacker escalated from the employee's Workspace into Vercel internal environments and enumerated readable env vars from there.

Reconstructing the most probable attack chain

The piece public reporting hasn't quite assembled is the type of attack on Context.ai. The Chrome-extension-listing artifact that Blasco found is what makes the picture come into focus.

Template: Cyberhaven, December 2024

Through late December 2024, attackers ran a phishing campaign targeting Chrome Web Store extension developers. The phishing emails impersonated Google's Chrome Web Store policy team, claiming an extension was at risk of removal for a policy violation. The link led to a real Google OAuth consent flow for a malicious app called "Privacy Policy Extension," which requested permission to "see, edit, update, or publish" Chrome Web Store content under the developer's identity.

A Cyberhaven employee with developer access granted the OAuth scopes — multi-factor authentication did not save them, because the consent flow is the abuse mechanism, not the auth mechanism. The attacker pushed a malicious update to Cyberhaven's extension. Auto-update did the rest. Thirty-five extensions and approximately 2.6 million users were ultimately compromised. This is not a hypothetical pattern. It is documented attacker tradecraft, repeated and refined since.

Applied to Context.ai

The following chain is the most probable explanation of what we observe:

1. Context shipped a Chrome extension that integrated their AI office suite with Gmail, Drive, and Docs. The extension was registered under the same Google account that controls GCP project 110671459871. This is the artifact Blasco identified — a now-removed extension listing under that account.
2. A Context developer received a Chrome-Web-Store-policy-violation phishing email, indistinguishable in pattern from the Cyberhaven campaign. The message likely included an internal-credibility second touch ("Joseph asked us to handle this — please verify by clicking through") to lower the developer's guard. Internal-credibility is the angle our independent posture finding (below) makes trivial against Context.
3. The developer granted OAuth scopes to the malicious app. Scope set typically includes Chrome Web Store publish rights and broader Google identity scopes that, depending on the developer's role at Context, may extend to GCP console access for the project that holds the OAuth client_secret.
4. From here the attacker had two compatible options. Push a malicious update to the Context Chrome extension that exfiltrated user OAuth tokens at install/use time. Or pull the OAuth client_secret directly from the GCP console and mint refresh tokens against every user grant already on file. Vercel's wording — "a broader compromise potentially affecting hundreds of users across many organizations" — is consistent with either, but particularly clean for the second.
5. A Vercel employee's refresh token, or freshly-minted access via the malicious extension update, gave the attacker Google Workspace API access to that employee's Gmail and Drive. From there, lateral movement into Vercel's internal systems — the mechanism is not publicly detailed by Vercel and is outside the scope we can responsibly speculate about.
6. Inside Vercel's internal systems, the attacker enumerated env vars not flagged sensitive. DB credentials, NPM tokens, GitHub tokens, Linear data.

The sequence depends on a single failure: a Context developer being phished into granting OAuth scopes to a malicious app via Chrome Web Store impersonation. Every other step downstream is mechanical and well-trodden.

Independent finding: Context.ai publishes no DMARC

The relevance of the Cyberhaven template to Context specifically depends on whether internal-impersonation phishing against a Context developer is plausible. We checked. It is.

What we found

$ dig @alexandra.ns.cloudflare.com _dmarc.context.ai TXT
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 5833

The query was repeated against Google (8.8.8.8), Cloudflare (1.1.1.1), Quad9 (9.9.9.9), and the authoritative Cloudflare nameserver directly. All four returned NXDOMAIN. The zone itself is healthy — the context.ai SOA record returns normally — so this is a deliberately absent record, not a resolver hiccup. For comparison, the same query against google.com returns v=DMARC1; p=reject; rua=mailto:mailauth-reports@google.com.

Context's email is on Google Workspace (v=spf1 include:_spf.google.com ~all, google._domainkey selector active with a valid 2048-bit DKIM key). Strong identity at the sender side. No published recipient policy.

What that means in practice

DMARC tells receiving mail servers what to do when an inbound message claims to be from a domain but fails alignment with that domain's SPF or DKIM. With no DMARC record, receivers fall back entirely to their own spam heuristics. The behavior is non-deterministic from the sender's perspective — Gmail's heuristics may catch a spoof, Outlook's may not, a small Workspace tenant's might not. Most enterprise mail gateways are looser than Gmail.

We empirically tested this against mail-tester.com, a SpamAssassin + OpenDMARC pipeline. A spoofed From: support@context.ai message scored 0.8/10 — flagged by SpamAssassin on SPF_SOFTFAIL and RDNS_NONE, but with the explicit OpenDMARC verdict dmarc=none (p=none dis=none) header.from=context.ai. The receiver penalized the message because we sent it from a residential IP without reverse DNS. A sender from any clean infrastructure — a $5/month VPS with proper rDNS — would clear those penalties and land closer to inbox.

Why this matters for the breach

The Cyberhaven phishing template, when applied to a target like Context, becomes meaningfully harder if attackers cannot impersonate internal Context senders. With DMARC p=quarantine or p=reject, an attacker spoofing joseph@context.ai to a Context developer would have the message quarantined or rejected by any DMARC-respecting receiver — which includes Google Workspace itself, Microsoft 365, and most enterprise gateways. With no DMARC, the message arrives, looks internal, and the developer reads it the way they read every other internal message.

We are not asserting that this was the actual prologue to the OAuth compromise. We do not have access to Context's internal mail logs, GCP audit logs, or the original phishing email. We are asserting that the prologue was viable and that the exact gap that made it viable is still open today.

Two additional posture observations

These are minor on their own, but they round out the public picture of Context's exterior.

demo.context.ai leaks the internal subnet via public DNS. A standard dig returns three RFC1918 addresses (10.43.96.237, 10.43.64.245, 10.43.87.221) and an internal AWS ELB hostname. This is harmless to an external attacker who can only reach the internet, but reveals the internal IP scheme (10.43.0.0/16) and the hosting region (us-east-2) — useful for any attacker with an SSRF position or post-foothold pivot.

Customer enumeration via Certificate Transparency. A crt.sh query for %.context.ai returns subdomains named after specific customers. Qualcomm in particular shows up across multiple environments (qti.context.ai, qti.api.context.ai, qti.inference.context.ai, qualcomm.staging.context.ai, qualcomm.inference.context.ai), consistent with their dual role as both an investor and a customer. Additional customers are visible by name across the semiconductor, cloud-security, finance, banking, and private-equity verticals. CT is public by design and Context is far from the only enterprise vendor with this pattern, but the leakage is sharper for a vendor that markets "air-gapped public sector" deployments. Nine separate per-developer dev environments are also visible in CT, which gives an attacker a ready spear-phishing list.

This is the third one in eight months

Three OAuth-supply-chain incidents at SaaS vendors with broad data scopes, all within eight months. The pattern is simple to state and harder to defend against than it looks:

When a SaaS tool requires read access to your team's Gmail, Drive, Salesforce, or Workspace, the tool itself becomes part of your security boundary. Compromising the tool gets the attacker every grant the tool ever held. The attacker doesn't need to compromise you — they only need to compromise one of your integrations.

Gergely Orosz framed it cleanly in public reaction to the Vercel incident: "every SaaS tool your team uses IS a security risk of its own — especially if they need broad data access to e.g. email, internet docs (many AI tools do just this)."

Recommendations

For Context (Explore Interfaces Inc.)

1. Publish a DMARC policy. Start at p=quarantine with a rua= reporting address; review aggregate reports to confirm no legitimate senders are being filtered; move to p=reject once clean. One TXT record, deterministic improvement, closes the internal-impersonation-phishing path.
2. Enroll Chrome Web Store developer accounts in hardware-key MFA, and configure them to refuse OAuth grants to apps not on a vetted allowlist. The Cyberhaven template assumes developers can grant arbitrary OAuth scopes interactively. Removing that capability removes the template.
3. Audit the OAuth grant database. Every refresh token issued to the breached client should be considered exposed. Customer notifications and forced re-grants are appropriate.
4. Trim CT-log exposure. Per-customer subdomain naming leaks the customer list to anyone with a CT query. Consider opaque subdomain naming for new tenants.
5. Resolve demo.context.ai to public IPs only. Public DNS records to RFC1918 addresses serve no external purpose and reveal internal topology.
6. Publish a public statement. Customer trust survives transparency. It does not survive silence followed by being-named-by-someone-else.

For Vercel customers and other downstream parties

1. Rotate every secret in any non-sensitive Vercel env var. Vercel's recommendation, repeated here for emphasis. Treat NPM and GitHub tokens specifically as compromised given the attacker's claimed exfil.
2. Audit OAuth grants to AI tools across your Workspace. Any tool with Gmail or Drive read scopes is in the same trust boundary as the tool's vendor. Revoke grants for tools you no longer use.
3. Default-deny third-party OAuth apps at the Workspace admin level. Add allowlist entries only for tools you've actually approved.

For other AI SaaS vendors

The pattern that just hit Context will hit you next if you don't already have:

• DMARC p=reject with strict alignment
• Hardware-key MFA on every Workspace and Chrome Web Store developer account
• Allowlisted-only OAuth grants for those accounts
• An OAuth grant audit log you actively review
• Customer-side ability to enforce token rotation when you ask them to

Coordination

The DMARC finding was disclosed publicly to Joseph Semrai (@josephsemrai) on X on 2026-04-20. A signal pointer was sent to Guillermo Rauch (@rauchg) the same day.

We did not perform any active or authenticated probing of Context's infrastructure. All findings derive from passive sources: public DNS, Certificate Transparency logs, Wayback Machine archives, and public press reporting. The empirical mail-tester run sent a single message to a one-shot test address from a residential IP; no other party's mailbox was touched.

Methodology and sources

Methodology. AI-assisted adversarial analysis. Passive OSINT only — no scanning, no fuzzing, no authenticated requests against Context infrastructure.

Primary reporting

• Vercel security bulletin (vercel.com/kb)
• Guillermo Rauch's reconstruction (X)
• Hacker News thread
• BleepingComputer
• Cyber Insider
• ccleaks
• TechCrunch on the Old Context.ai → OpenAI acqui-hire
• TechCrunch on the new Context $11M seed
• Context launch press release

Pattern and precedent

• Salesloft Drift OAuth supply-chain compromise (Aug 2025)
• Red Canary on malicious Workspace OAuth apps
• Cyberhaven Chrome Web Store dev compromise (Dec 2024)

Independent corroboration

Jaime Blasco (Nudge Security) matched the OAuth client ID to the now-removed Chrome Web Store extension listing under the same Google account.

Tooling

• crt.sh for Certificate Transparency enumeration
• Wayback Machine CDX API for historical snapshots
• mail-tester.com for empirical deliverability + OpenDMARC verdict
• Standard DNS resolution (dig against multiple resolvers and the authoritative Cloudflare nameservers)

Published under coordinated disclosure norms. Any party named here who would like to provide a response, correction, or supplemental detail should contact security@redeux.ai. Updates will be added in line.