Nobody clicks anything to get an extension update. Chrome checks the listing, pulls the new version, and installs it in the background, and by dev.to's account no prompt comes back to ask whether the user still agrees to what is now running [1]. That makes the delivery path the interesting part, because it was the store's own distribution infrastructure [6]. Egress filtering and domain reputation do not help against a fetch you already have to allow.
The trigger is the update event itself. Netskope's description has a service worker firing when Chrome reports that the extension has updated, opening an affiliate link in a foreground tab, routed through a URL shortener to an AI video platform [7]. All of it runs through code already installed and permissions already granted, with no remote code and no attacker-controlled host required. dev.to reads Manifest V3 as having reworked how extensions run background code and made some classes of remote code harder, while a service worker opening a tab on update, and exfiltration of data the extension is already permitted to read, both remain unremarkable MV3 [11]. The overwritten uninstall URL is the one part of the build with real craft in it [8].
The permission grant is the durable artefact. It was made once, to code the user never read, and every later build inherits it [10]. dev.to notes that "read and change all your data on all websites" is a permission a great many legitimate extensions genuinely need, so its presence at install time is not a signal [10]. Install-time review does fix one thing that survives updates, which is that ceiling. It cannot bind behaviour, because the consent attached to the permission, and an update is a new use of it [10].
Two intervals stand out here. The January removal and the observed update sit about six months apart [15], and the update window itself spans 12 days [16]. Against that, the account is thin exactly where it would need to be strong to convict the store's re-review: dev.to does not say how the listing was reinstated, whether the owner changed, or how many users the returned version reached [17]. What the evidence supports is narrower than a verdict on vetting. Removal proved reversible, and the channel came back with the listing.
Ownership changes without notice to users, and that is the other variable at work. Socket documented a 2026 wave of extensions bought from their original creators and then, through ordinary automatic updates, fitted with code to steal credentials and cryptocurrency [9]. dev.to's conclusion is that no browser setting fixes a supply-chain problem, so the work is reducing exposure rather than catching the bad update, which you cannot reliably do [12]. In practice that means fewer listings, dormant ones uninstalled because a dormant extension still updates, and the extension-heavy profile kept out of the browser holding bank and work sessions [13]. The tells dev.to lists for a sold listing are a sudden update after a long quiet period, a changed developer name or support domain, new permissions requested on update, and a once-focused tool growing features nobody asked for, and none of them is proof [14]. The extensions installed in a browser also form a fingerprint that a page can read [18].
