Vercel Update: The Ripple Effect of the Context.ai Breach
Just saw the update from Vercel regarding the Context.ai-linked breach. It turns out the blast radius was larger than initially thought. They found more compromised accounts after expanding the investigation to include new compromise indicators and a deeper look at network/environment requests.
This is a classic case of a second-order supply chain attack. It's not just that Context.ai was breached; it’s that the attacker leveraged that trust to pivot into Vercel's internal systems, and then potentially out to customer environments.
For those auditing their Vercel environments right now, you're likely looking for unusual access patterns. We're running queries to flag any deployments or environment variable reads originating from IPs that don't match our developers' standard geolocations or known VPNs.
If you're using Azure Sentinel or a similar SIEM, you might find a hunt query like this useful to cross-reference with Vercel's audit logs:
let KnownIPs = datatable(IP:string) ["10.0.0.1", "192.168.1.1"]; // Add your known ranges
VercelAuditLogs
| where TimeGenerated > ago(7d)
| where EventType == "deployment.success" or EventType == "env.read"
| where SourceIP !in (KnownIPs)
| project TeamName, ProjectName, UserEmail, SourceIP, UserAgent
| distinct SourceIP, UserEmail
The scary part here isn't necessarily the code execution, but the data exfiltration risk from environment variables. Has anyone else started forcing a token rotation for all their third-party integrations just to be safe?
Good call on the environment variables. In this specific breach context, the attackers were reportedly looking for secrets. I'd add a filter to that KQL to look for UserAgent anomalies as well. If you see a deployment from a legit IP but the UA string is missing or looks like a standard library (e.g., python-requests rather than the Vercel CLI), flag it immediately.
We started rotating all OAuth tokens connected to our Vercel org yesterday. It's tedious, but safer than waiting for a 'you were pwned' email.
This is exactly why we treat SaaS integration tokens as having the same shelf-life as session cookies now. The moment Vercel hinted at internal system access, we assumed the worst.
For those scripting their audit, here is a quick Python snippet using the Vercel API to pull recent deployment events if you aren't feeding them to a SIEM yet:
import requests
headers = {"Authorization": "Bearer YOUR_TOKEN"}
response = requests.get("https://api.vercel.com/v6/deployments", headers=headers)
deployments = response.()['deployments']
for d in deployments:
print(f"{d['created']} - {d['creator']['username']} - {d['url']}")
Just remember to mask your tokens before running that in any shared environment.
It feels like we're seeing one of these a month now. The 'Context.ai' vector is interesting because it targets the trust relationship rather than a direct vulnerability in the platform code.
We're an MSP, so this is a nightmare. We're advising all clients to enable IP whitelisting on their Vercel projects if they are on the Pro plan. It breaks some workflows for remote devs, but it stops the account takeover stuff dead in its tracks if the attacker's IP isn't on the list.
To catch the usage drift Viktor mentioned, try monitoring for unexpected IP ranges associated with your SaaS integrations. If your vendor states they operate in us-east, but you see traffic from elsewhere, it's a red flag.
AuditLogs
| where Category == "ApplicationManagement"
| where Result == "success"
| distinct AppDisplayName, CallerIpAddress
| evaluate geoip_lookup(CallerIpAddress)
Verified Access Required
To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.
Request Access