The Extension You Approved Last Month Is Not the Extension Running Today
tl;dr
- Chrome checks installed extensions for updates on startup and every few hours, and installs any newer version automatically, with no re-approval step and no change to the extension’s name or ID.
- That update channel has already been used for real attacks: a December 2024 campaign compromised at least 16 Chrome extensions with over a million estimated infections by hijacking a developer’s own publishing permissions through phishing.
- Store signals (ratings, install counts) don’t help: peer-reviewed research found 346 million users installed at least one security-noteworthy extension in three years, and users don’t rate them any lower.
- A manual approval queue also only sees the requests people bother to submit; it says nothing about what’s already installed without admin rights. The fix is a standing enterprise policy plus continuous reassessment, not a faster queue.
An IT leader at a mid-sized nonprofit joined a call with four browser extension requests open on his desk. Users had been waiting most of the week for an answer. His method for producing one was to copy the extension’s store URL, paste it into a lookup site, run a search, and form a judgment. He had spent part of the weekend working through free extension-checking tools. The third-party risk platform his team already owned, the one he uses to review vendor certifications before contracts get signed, did not cover this kind of artifact.
He then named the two capabilities he needed, in order. First, vetting he could stand behind, so he could approve or deny a request and give reasons. Second, monitoring after install, because an extension could change at different points in time.
The second requirement quietly sets an expiration date on the first.
An approval expires without telling you
Every few hours, and again at every browser startup, Chrome checks whether an installed extension has an update available. If the update manifest lists a version newer than what is installed, the browser downloads and installs it. There is no re-approval step, no ticket, and no change to the extension’s name or ID. The thing you evaluated on Tuesday can be replaced on Thursday while your allow list keeps saying yes.
Google’s own store rules treat that drift as normal. Chrome Web Store policy requires that developers must proactively disclose to users if their data handling practices change at any point after the initial installation. A disclosure rule shaped that way exists because post-approval behavior change is an ordinary event, not an anomaly.
The same channel carries attacks. In December 2024, an attacker published a malicious build of an already-approved extension by using the developer’s own upload permissions, previously gained through a targeted phishing attack. The tampered build started from a clean, already-reviewed version and added command-and-control traffic plus cookie and credential harvesting. Threat intelligence from RH-ISAC placed that compromise inside a campaign affecting at least 16 Chrome extensions, with over a million estimated infections, propagated through trusted updates. MITRE ATT&CK catalogs the general form of this as a persistence technique: adversaries may manipulate an extension’s update url to install updates from an adversary-controlled server.
An approval queue answers a question about a moment. The update channel operates on a schedule that ignores the answer.
Store signals are not doing the vetting for you
The manual workflow described on that call, paste the URL and look, leans on what the marketplace shows: developer name, install count, rating, review text. Research from Stanford and CISPA on the Chrome Web Store puts a ceiling on how much that can carry. Their analysis found over 346 million users installed at least one SNE in the last three years, of whom 280M users installed malware-containing extensions, and that security-noteworthy extensions remain in the store for an average of 380 days (malware containing) to 1,248 days (vulnerable). The finding that matters most for a person doing manual review is smaller and blunter: users do not give SNE lower ratings. The crowd signal a reviewer would naturally reach for does not separate the bad ones.
The queue is a sample, not the population
The same IT leader described something worth sitting with. His users do not have admin rights for installing applications. He also said there are certain things a person can install without admin rights, that he knows some users never came to him at all, and that he plans to run an audit to find plugins already in place beyond what has been approved.
Follow that logic to its end. The control the organization relies on for software, withheld local admin, governs application installs. The tickets he is triaging came from the people who chose to ask. Whatever else is loaded into a Chrome, Edge, Safari, or Firefox profile on a managed endpoint never enters the queue at all. That gap is not a policy failure; it is a category error about what the queue measures.
His browser footprint was moving underneath him at the same time. Requests reaching his desk were overwhelmingly Chrome, but his Mac population had grown several times over as staff picked their own hardware, and Safari and Firefox were entering the mix.
What replaces a per-request decision
The enforcement primitive already exists. Chrome Enterprise’s ExtensionSettings policy controls if and how extensions that you specify are added to Chrome browser and prevents users from installing and running extensions that request certain API permissions that your organization doesn’t allow. That turns a per-request verdict into a standing rule. What policy cannot do is tell you which extensions belong on which side of the rule, or revisit that judgment after the next auto-update lands.
NIST SP 800-53 names the missing half directly. Under CA-7, continuous monitoring programs allow organizations to maintain the authorizations of systems and common controls in highly dynamic environments of operation with changing mission and business needs, threats, vulnerabilities, and technologies. Maintain is the operative verb. An authorization nobody re-checks is not a control; it is a memory of one.
There is a second thing the person in that seat asked for. He wanted a defensible threshold, the way he already interprets vendor risk scores, so that a denial comes with a reason the requester can read. A verdict without evidence behind it does not survive the follow-up email.
That combination, a standing rule at the endpoint layer, a risk assessment deep enough to explain itself, and reassessment that keeps running after install, is the job. SpinCRX is built to assess and control browser-extension risk across Chrome, Edge, Safari, and Firefox, so the decision is a policy your endpoints carry rather than one more inbox to work through.
The four tickets are not the backlog. The extensions you already approved are.
(This piece is about the update mechanism that erodes an approval after the fact. For how that same drift creates regulatory exposure under frameworks like GDPR and HIPAA, see The Silent Compliance Risk in Browser Extensions.)
FAQ
On startup and every few hours after that. If the extension’s update manifest lists a newer version, Chrome downloads and installs it automatically, with no re-approval step and no visible change to the extension’s name or ID.
Yes. The same auto-update channel that pushes routine version bumps has been used to push malicious code into already-approved extensions, including a December 2024 campaign that compromised at least 16 Chrome extensions with over a million estimated infections, by taking over a legitimate developer’s own publishing permissions.
Not reliably. Research from Stanford and CISPA found that security-noteworthy extensions receive essentially the same ratings as benign ones, even though hundreds of millions of users installed them.
It lets admins set a standing rule for whether specific extensions can be added to Chrome, and it can block extensions that request specific API permissions outright. It enforces a decision; it doesn’t make the risk judgment behind that decision or revisit it after an update.
Not on its own. NIST SP 800-53’s CA-7 control is built around continuous monitoring specifically because authorizations have to be maintained as threats and technologies keep changing, not granted once and left alone.
