You would never install an application that can log into your Google docs, read your keystrokes in your browser, intercepts requests in transit, runs continuously, updates silently, AND could be powerful enough to steal your passwords, right? Well, this is more or less what browser extensions can do, and they create vulnerabilities that extend beyond one computer and or even one company.

A few months ago, a Vercel employee installed the relatively new and popular Context.ai browser extension, which provided an “AI Office Suite.” It required OAuth permission to connect to the apps, so when the permissions screen asked them to grant the tool access to their Google account, they clicked allow. It wasn’t an extension that Vercel approved internally, but it wasn’t a blocked one either.

At the end of February, a Context.ai employee later installed a Roblox cheat download that contained an infostealer. That malware found the Vercel OAuth token, which became the entry point for a large-scale attack on Vercel. The attacker did not need to hack Vercel. They needed to hack the AI startup whose software a Vercel employee had already given the keys to.

One malware stole data collected from a shadow browser extension. Does the pattern sound familiar? It looks like a supply chain attack, and that's what it is.

How the Vercel breach was a supply chain attack

Browser extensions have become one of the most underestimated attack vectors in enterprise security, and the Vercel breach is just the latest example. The attack followed a pattern the security industry knows well from open source dependencies, where some third-party code is implicitly trusted, then compromised upstream. We have a name for that pattern and a whole category of tooling built around it, but the industry as a whole hasn’t applied them to browser extensions.

A supply chain attack has a few main ingredients. You need third-party code running with real privileges, implicit trust, and victims without a direct relationship with the source of the initial compromise. The Vercel breach checks all three. Context.ai was a real product doing a real job, and the OAuth access it had been granted to Google Workspace was a reasonable ask for what it was trying to do (although arguably a bit too much trust and power). That meant a highly privileged OAuth token was sitting in Context.ai's AWS backend, just one compromised employee device away from becoming an attacker's property. 

When that Context.ai employee installed an infostealer on their own machine, the trust just one employee had extended to a previously legitimate extension became the path into their internal environments. The original breach happened somewhere else, but Vercel suffered. And that’s what we call a supply chain attack.

Vercel’s case isn’t the first malware attack to use browser extensions as part of a supply chain attack. For example, the Cyberhaven breach in late 2024 was a targeted version of a similar scenario, with developer-focused extensions specifically in the attackers' sights. Cyberhaven's own Chrome extension was compromised via a phishing attack on a developer account, and a malicious update was pushed to users before anyone caught it. The malicious version was live for roughly 24 hours.

The silent update model creates more danger

The update model for extensions is a bit wild when you look at it from a security perspective. Unlike OS software, browser extensions update silently and automatically. The code running on your browser today may not be the app you agreed to when you installed it. Unlike other software updates that prompt you to update (for months as you continue to click “Update later”), there's no prompt to get consent from the user to update. The only time you would get a notification is when the extension asks for additional permissions. An extension that was clean last month could receive a malicious update tonight, and every user with it installed would get it automatically. If it already had a lot of permissions, you’re in trouble. Imagine if software dependencies were silently autoupdating on your dev machine.

What hasn’t been working

Companies have often tried either creating lists of allowed extensions (blocking everything else) or the inverse of blocked ones. But in both cases, keeping the list curated and up-to-date has some obvious barriers. About half of extension authors are unknown, and most publishers have published only one extension, so managing extensions based on reputation only works for a small portion of extensions. Even major companies publish extensions that aren’t squeaky clean, anyway. Manually maintaining an accurate and up-to-date internal list is impossible.

SCA scanning was invented to solve this for packages. The mechanisms that work for open source dependencies operate on what the package does (not name or claimed functionality). Approving npm packages by package name alone, with no code scanning and no threat intelligence, wouldn't count as supply chain security for dependencies. But swap "npm package" for "Chrome extension," and that's the more or less the approach to browser security in recent years.

While the marketplaces don’t reflect it, trust at install time isn't enough. We have to apply the same philosophy here as we do to package security. Organizations need to know what's installed across all machines, and they need continuous monitoring so that a seemingly clean extension that turns malicious doesn’t slip through the cracks.

Most security teams can articulate a supply chain threat model for dependencies. They know maintainer accounts get compromised, and a package that was clean last quarter can be a vector today (and we’ve seen a lot of high-profile supply chain attacks lately). However, as an industry, we haven't applied that knowledge to browser extensions to the same degree.

What works for dependencies can work for browser extensions, too. Software dependency scanning works because the underlying threat intelligence stays current, checking against databases that update as new threats are discovered rather than a list someone compiled last quarter. Pre-install blocking for browser extensions needs to work the same way. Supply chain attacks move fast, and an allowlist that was accurate last month doesn't know that an extension changed hands or received a malicious update last week.

Organizations also need visibility into what's installed across every developer device. Package managers leave a paper trail like lock files and dependency lists that live in repos, but browser extensions don’t have that. The only way to know is to actively audit all devices across the organization. You can’t respond to threats you don’t know exist, and many companies don’t have the tools in place that do this. 

Finally, everyone in an organization, from engineers to HR, need to be aware of the risks of browser extensions. Dependency vulnerabilities have been getting a lot of press, but browser security less so. While people may generally know they’re not great, they often aren’t as aware of these major vulnerabilities like credential stealing. We have to educate our teams and organizations about risks and best practices (send them this article, for example).

Prevent the next Vercel-style supply chain attack

The Vercel breach will not be the last incident where a browser extension is part of the kill chain. The attack surface is too valuable, and the controls most organizations rely on are too limited for that to change on its own. Treat browser extension security as the supply chain problem it already is, hopefully before the next attack (not after).

Aikido Endpoint applies a supply-chain security model to protect developer devices. Malicious extensions are blocked before installed, known malicious, checked against Aikido Intel before they touch the device. The Aikido Intel feed that powers it identifies up to 100,000 malicious packages per day and is public and free to explore at intel.aikido.dev.

Learn more about Aikido Endpoint or explore the Aikido Intel feed to see what’s been detected across the open-source ecosystems in real time.

‍