They evade review because attackers hide malicious behaviour until after the extension is already trusted, often by using obfuscated code or delayed activation. Store approval checks the submitted package, but it cannot guarantee that later updates or runtime behaviour will remain safe.
How malicious extensions slip past review
Store review is usually strongest against what is visible in the submitted package, not against behaviour that only appears later. Attackers exploit that gap by shipping a benign version first, then activating payloads after install, after a delay, or after some trust-building event such as an update or remote configuration fetch. That lets the extension look normal during review while behaving differently in the wild.
Obfuscation makes the same problem harder to catch. Reviewers and static scanners may see compressed, encoded, or highly indirect code paths, but those techniques are useful only if they hide the real logic well enough to avoid manual inspection or signature-based detection. In practice, the review problem is less about a single missed line of code and more about how much behaviour can be deferred, unpacked, or assembled at runtime.
Why static analysis is easy to outmaneuver
static analysis is valuable for finding known bad patterns, but it has blind spots whenever the malicious action depends on conditions that are not present in the source snapshot. A browser extension can keep dangerous logic behind feature flags, remote scripts, environment checks, or delayed execution paths that static tooling cannot confidently simulate. That means the scanner may correctly validate the package while still missing the future state the extension will enter after approval.
This is especially effective when the initial code is only a loader, updater, or trigger. The extension can request benign-looking permissions, then use those permissions later to read pages, rewrite content, harvest session data, or contact attacker infrastructure. The static view may not show the full blast radius because the risky behaviour is distributed across multiple stages rather than concentrated in one obvious function.
For a practical treatment of the update-path abuse pattern, see Cyberhaven Chrome extension breach 2024, which shows how trusted publishing rights can turn a normal update channel into an attack path. The broader supply-chain lesson is also visible in GlassWorm campaign 2025, where hidden code and token theft helped the operator persist and spread through the extension ecosystem.
What reviewers need to verify before trusting an extension
A store listing, clean binary, or passing scan is not the same as trustworthy runtime behaviour. Reviewers need to verify whether an extension can change meaningfully after approval, whether it depends on remote code or remote configuration, and whether the requested permissions are broader than the visible feature set really requires. The key question is not only “does this package look safe now?” but also “what can this package become once it is installed?”
That is why Secrets in VS Code extensions 2025 is a useful analogue: hidden credentials and publishing tokens show how an extension ecosystem can be abused through what is embedded, not only what is displayed. If an extension can reach external services, load dynamic content, or inherit powerful permissions, review must treat those pathways as part of the security surface, not as implementation detail.
At the platform level, browser ecosystems benefit from stronger update scrutiny, runtime reputation signals, and permission review that is tied to actual behaviour over time. The more the approval process relies on a one-time snapshot, the easier it is for attackers to stay one step ahead by waiting until trust has already been granted.
Risk and Threat Considerations
Malicious browser extensions are attractive because they sit inside a trusted execution context and can observe or manipulate user activity after installation. That makes delayed activation, obfuscated loaders, and malicious updates especially effective, because the extension can look harmless during review and then pivot to credential theft, page manipulation, session abuse, or data exfiltration once it has a foothold.
Failure mechanism: The submitted package passes review, then the extension changes behaviour later through runtime triggers, remote payloads, or a trusted update channel that was not fully validated at approval time.
Impact: Users and organisations can end up trusting code that was never fully assessed in its malicious state, which increases the chance of account compromise, sensitive-data exposure, and ecosystem-wide abuse.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while CIS Controls v8, NIST SP 800-53 Rev 5 and OWASP ASVS set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1195 — Supply Chain Compromise | Malicious extensions abuse trusted distribution and update paths to reach users. |
| Recommendation — Monitor extension distribution and update channels for compromise indicators. | ||
| CIS Controls v8 | CIS-10 — Malware Defenses | Static review gaps and delayed payloads require layered malware detection and analysis. |
| Recommendation — Add layered malware analysis for extensions and update payloads. | ||
| NIST SP 800-53 Rev 5 | CM-5 — Access Restrictions for Change | Runtime changes and post-approval updates need controlled change authority. |
| Recommendation — Restrict who can publish and update extensions after approval. | ||
| OWASP ASVS | V15 — Secure Coding and Architecture | Obfuscation and deferred execution are software design issues that affect reviewability. |
| Recommendation — Design extensions to minimize hidden or deferred execution paths. | ||
Practitioner Guidance
What to verify: Treat remote configuration, self-updating logic, and permission scope as first-class review items. If the extension can alter behaviour after publication, require a separate control to prove what governs that change and who can push it.
Common mistake: Teams often over-trust “clean scan” results and underweight runtime paths. A package that is harmless at submission time can still become dangerous after installation if its code is designed to wait, fetch, or unpack later.
Practitioner takeaway: The security question is not whether the extension looked safe when it was uploaded, it is whether the ecosystem can continuously detect and constrain what it is allowed to do after trust is granted.
Related resources from NHI Mgmt Group
- How can security teams detect malicious browser extensions in practice?
- How should security teams organise JavaScript static analysis across browser code, Node.js services, and Express applications?
- Why do malicious extensions and browser-based malware create outsized risk for developers working with cloud and CI/CD systems?
- Why do malicious browser extensions create so much risk in modern enterprises?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 10, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org