On December 24, 2024, an employee at data-security vendor Cyberhaven clicked a phishing link disguised as a Chrome Web Store policy warning. The credentials it harvested gave attackers publishing rights to Cyberhaven's official extension. Within hours, a trojanized version 24.10.4 was live in the Chrome Web Store, silently exfiltrating session cookies and access tokens for Facebook Ads accounts from every machine that auto-updated. Security researchers later tied the same campaign to at least 35 other browser extensions. Ten months later, a different attack — a self-replicating worm called GlassWorm — used invisible Unicode characters to hide malicious code inside Open VSX extensions, spreading itself using stolen developer credentials. Neither attack touched a single line of application source code. Both are textbook malicious chrome extension supply chain attacks, and both landed on infrastructure that most software supply chain security programs don't monitor at all: the browser and the IDE.
Why are browser extensions and IDE plugins now a top supply chain attack surface?
Because they run with broad, often unreviewed permissions, update silently in the background, and are installed directly by employees outside any CI/CD pipeline or code review process. A single Chrome extension with "read and change all your data on websites" access can capture every cookie, form field, and authentication token that passes through a browser session. The Chrome Web Store hosts roughly 250,000 extensions; the VS Code Marketplace lists more than 80,000; Open VSX — the marketplace used by Cursor, Windsurf, VSCodium, Google Cloud Workstations, and Gitpod — has tens of thousands more. Each one auto-updates by default, and each update is effectively a new, unreviewed software deployment straight onto an engineer's or an entire company's endpoint. Unlike an npm package pulled into a build, a malicious extension update doesn't need to survive a pull request — it just needs control of the publisher's account.
How did the Cyberhaven Chrome extension breach actually happen?
It happened through a targeted spear-phishing email sent to a Cyberhaven administrator, not a code vulnerability. The email impersonated Google's Chrome Web Store developer support team and linked to a fake OAuth consent screen requesting "Extensions" management permissions. Once granted, attackers pushed a malicious update that exfiltrated Facebook Business/Ads cookies and access tokens to an external command-and-control domain, targeting marketers specifically because compromised ad accounts can be resold or used to run further malvertising. Researchers who traced the campaign's infrastructure found it wasn't limited to Cyberhaven: publishers of roughly three dozen other Chrome extensions — spanning AI writing tools, VPNs, and productivity utilities — had been hit with the same phishing template in the same holiday week, when security teams are thinnest. The common thread was never a code flaw; it was that anyone with publish rights to a widely trusted extension is a single point of failure for every organization that installed it.
What made the GlassWorm campaign on Open VSX different from a typical malicious extension?
It was self-propagating, meaning infected machines were used to automatically re-infect the next extension in the chain, rather than requiring a fresh attacker action each time. Discovered in October 2025 by researchers at Koi Security, GlassWorm hid its payload using invisible Unicode characters that rendered as blank space in a code diff, so a human reviewer scrolling through the extension source would see nothing unusual even while malicious logic executed. Once installed, it harvested npm, GitHub, and cryptocurrency-wallet credentials, then used those stolen credentials to publish new infected packages and extensions, spreading the worm further without additional attacker infrastructure. Affected extensions had a combined install base in the tens of thousands. Because Open VSX backs marketplaces inside AI-assisted IDEs like Cursor and Windsurf, the campaign reached developer machines that many security teams don't even know are running a plugin marketplace, let alone one they're inventorying for risk.
Why do malicious extensions keep slipping past Chrome Web Store and VS Code Marketplace review?
They slip through because both marketplaces rely primarily on automated static scanning at submission time, not ongoing behavioral analysis of what an extension does after users install it and it auto-updates. In November 2024, ReversingLabs identified two VS Code extensions, published under the names ahban.shiba and ahban.cychelloworld, that impersonated legitimate tools and deployed ransomware after installation; they had accumulated real download counts before Microsoft pulled them. A separate pattern researchers have documented repeatedly: attackers buy or take over abandoned extensions that already carry tens of thousands of legitimate installs and years of trust, then ship a single "maintenance update" that adds credential-stealing code — no new extension, no new review, just a hijacked identity with an existing user base. Marketplace review catches obvious malware signatures at upload; it does not catch a trusted publisher account going bad six months later.
Why don't traditional SCA and dependency-scanning tools catch these attacks?
Because tools built for software composition analysis — including Socket.dev, whose core strength is scanning npm, PyPI, and other package-registry dependencies pulled into a build — are scoped to what enters a codebase through package managers, not what an employee installs directly into their browser or IDE. Socket.dev's behavioral diffing and provenance checks are genuinely useful for catching typosquatted or compromised packages in a package.json, but a browser extension or IDE plugin never touches a manifest file or a CI pipeline; it's installed with two clicks from a store, and it runs with its own permission model entirely outside the dependency graph any SCA tool inspects. That blind spot is exactly where Cyberhaven and GlassWorm operated. A security program that only scans registries is watching the front door while these attacks come in through a window nobody assigned anyone to watch.
How Safeguard Helps
Safeguard extends software supply chain visibility past the package registry and into the two places engineers spend most of their day: the browser and the IDE. Safeguard continuously inventories every Chrome, Firefox, VS Code, and Open VSX extension installed across an organization's fleet, mapping each one to its publisher, permission scope, and update history rather than treating "installed once, trusted forever" as an acceptable posture. When a previously benign extension ships an update that suddenly requests new host permissions, adds obfuscated or Unicode-hidden code, or starts communicating with a domain that doesn't match its stated purpose, Safeguard flags the change before it becomes an incident instead of after a researcher publishes a writeup. Safeguard also correlates fleet-wide extension inventories against known-bad indicators from campaigns like Cyberhaven and GlassWorm as they're disclosed, so security teams get an immediate answer to "are we exposed" instead of a manual spreadsheet exercise. Combined with Safeguard's existing package and build-pipeline coverage, that gives teams a single view of supply chain risk that spans dependencies, CI/CD, and the endpoint software their own engineers chose to install — closing the exact gap that malicious chrome extension supply chain attacks are built to exploit.