A supply chain attack compromised 19 Chrome and Edge extensions between December 2024 and January 2025. Attackers acquired legitimate extensions, pushed malicious updates through official channels, and turned trusted tools into data-harvesting malware. One extension, "Enable Right Click & Copy, Smart Unlock + OCR", had 70,000 users when the malicious code was introduced.
This wasn't a vulnerability exploit. The extensions worked as designed: automatic updates delivered code that users had implicitly trusted.
Timeline
Pre-attack: Extensions operated legitimately with narrow permission scopes. Users installed them, granted permissions, and moved on.
Attack window (December 2024 - January 2025): Attackers acquired the extensions through unknown means (purchase, compromise, or social engineering of developers). They pushed updates that requested expanded permissions and injected malicious code.
Post-deployment: The malicious code targeted cryptocurrency wallets, social media credentials, and authentication tokens. Socket's research team identified the campaign and reported it. Google and Microsoft removed the extensions from their stores.
Current state: The extensions are offline, but the attack pattern remains viable. Thousands of extensions update daily with minimal oversight.
Which Controls Failed
Extension approval was one-time. Your team probably reviews extension requests before installation. You check the permissions, verify the business need, maybe run it past legal. But you don't re-review when the extension updates, even when those updates request new permissions.
No runtime monitoring. Once installed, extensions operate in a privileged context with access to page content, cookies, and network traffic. Most organizations have no visibility into what extensions actually do after installation. Your endpoint detection tools don't parse extension behavior. Your SIEM doesn't receive browser telemetry.
Permission creep went unnoticed. The malicious updates requested broader permissions than the original versions. Users saw the permission prompt and clicked through. Your security stack had no mechanism to flag this escalation.
No ownership tracking. When an extension changes hands (through sale, acquisition, or account compromise), there's no notification to users or administrators. The trust relationship persists even though the entity behind the extension has changed.
What Standards Require
The NIST CSF addresses third-party risk in the GOVERN function: "GV.SC-03: Cybersecurity and privacy risks associated with suppliers, customers, and partners are identified, recorded, prioritized, assessed, responded to, and monitored over the course of the relationship." Browser extensions are suppliers. They provide functionality to your users and operate within your security boundary. The "over the course of the relationship" clause is critical here.
ISO/IEC 27001:2022 requires ongoing supplier assessment in Annex A.5.19 (Information security in supplier relationships) and A.5.20 (Addressing information security within supplier agreements). If you're using extensions to process or access company data, they fall under supplier management. You need documented processes for monitoring supplier changes and reassessing risk.
PCI DSS v4.0.1 Requirement 6.4.3 states: "All scripts that are loaded and executed in the consumer browser are managed as follows: A method is implemented to confirm that each script is authorized." This applies directly to extension scripts. The requirement calls for inventory, authorization, and integrity validation. It doesn't say "authorize once at install time."
SOC 2 Type II evaluates controls over time. If your control description says "we approve browser extensions before installation," but you don't monitor them post-installation, you have a control gap. The auditor will ask: how do you know the extension you approved in Q1 is still the same extension in Q4?
Lessons and Action Items
Build an extension inventory. You can't manage what you don't track. Start with browser telemetry if your endpoint management platform supports it. If not, use Chrome's chrome://extensions and Edge's edge://extensions pages to export installed extensions across managed devices. Document: extension name, ID, version, permissions, install date, and business justification.
Implement permission baselines. Define maximum acceptable permissions for each extension category. A grammar checker doesn't need access to all websites. A password manager does. When an extension requests permissions beyond its baseline, your approval process should trigger again.
Monitor for ownership changes. This is harder than it should be. Chrome Web Store and Edge Add-ons don't publish developer change notifications. You'll need to track developer names and periodically compare them against your inventory. When a developer name changes, treat it as a new extension request.
Add browser telemetry to your SIEM. Modern endpoint agents can forward browser events, including extension installs, updates, and permission grants. Set up alerts for: extensions requesting new permissions, extensions from developers not in your approved list, and extensions communicating with unexpected domains.
Test your extensions in isolated environments first. Before deploying an extension update to all users, push it to a test group with instrumented browsers. Monitor network traffic, file system access, and clipboard activity for 48 hours. This catches obvious malicious behavior before it reaches production.
Establish update policies. Not all extensions need automatic updates. For high-risk extensions (those with broad permissions or access to sensitive data), configure manual update approval. Yes, this creates overhead. That's the point. The friction forces reassessment.
Document your lifecycle process. Your auditor will ask how you manage third-party software risk. "We approve extensions before install" isn't sufficient. Document: approval criteria, permission limits, update procedures, monitoring methods, and reassessment triggers (ownership change, permission escalation, security incident).
The attackers in this campaign didn't find a zero-day. They didn't exploit a browser vulnerability. They used the update mechanism exactly as designed and relied on the gap between your initial approval and your ongoing oversight. Close that gap.
