A Delisted Extension Came Back, and the Payload Was the Least of It

On 11 August 2026, Netskope Threat Labs published an analysis of a Chrome extension called “AI Sidebar with DeepSeek AI”. Google had removed it from the Web Store in January 2026 for stealing the contents of people’s AI conversations. It is listed again, and it is shipping code.

The story is not what the new code does. It is how ordinary the route was.

What happened, in order

The extension was a real product. By the time it was removed it reported more than 300,000 installs and a 4.6-star rating, and the sidebar it advertised worked. Research published by OX Security in December 2025 showed the earlier builds scraping conversation content out of the page and posting it, base64-encoded, to two domains on a recurring interval.

Google removed it. Then it came back, and the sequence after that is the part worth reading twice.

Version 1.7.2.0 shipped from 20 to 31 July 2026 and did nothing wrong at all. It was, as Netskope puts it, distributed “to establish a clean update history”. Two weeks later version 1.7.3.0 arrived, identical apart from what the analysis calls “a surgical 21-line insertion” in one file.

What those lines do is comparatively petty: they open an affiliate link in a foreground tab every time the extension updates, and they claim the uninstall destination too, so somebody removing the extension generates a referral on their way out. Chrome allows one uninstall URL per extension and the last writer wins, so the code registers its own twice, five seconds apart, to land after the legitimate one.

Netskope’s own conclusion is the sentence to take away, and it is about delivery rather than payload:

The same mechanism that delivered an affiliate link would deliver anything else the operator chooses to compile next.

Why this matters to anybody who files bugs

Because the tools we use to do this job are exactly the tools this describes.

A browser extension that helps with bug reporting has to see the page to be useful. Ours does. The extensions people install for screenshots, for colour picking, for accessibility auditing, for grammar, for a dozen small daily conveniences: they all sit inside the same trust boundary as your session, your customer’s data, and whatever your team has open at 4pm.

And the update channel is silent by design. You approved the extension once, in a moment when you were thinking about it. Every version since arrived while you were thinking about something else.

What to actually check

Four questions, in the order that costs the least time.

Does the permission list match the job? An extension that reads the current tab needs the current tab. One that asks to read every site, every time, is asking for more than most jobs require. The store listing shows this before you install, and Chrome shows it again on the extension’s own page under chrome://extensions.

Who publishes it, and does that name appear anywhere else? In this case the package named its operator twice, while the store listing published it under a different developer display name entirely. That mismatch is visible from the listing page without any tooling.

What changed in the last update? For most people, most of the time, the honest answer is that there is no practical way to know, which is the actual finding here. A default-deny policy with an explicit allowlist is the enterprise answer, and it exists because the individual answer is so weak.

Would you notice if it went bad? This one is uncomfortable. Affiliate fraud opens a visible tab. Quiet exfiltration does not.

The same test, applied to us

It would be cheap to write this and not run the check on our own extension, so here is what ours declares and why.

It asks for <all_urls>, because a bug can be on any page and we cannot know in advance which one. It asks for tabs, scripting, sidePanel and storage to open the panel, collect the page and remember your settings. It asks for webRequest for the network log, tabCapture for the recording, and system.cpu and system.memory for the environment block on the report. It asks for debugger, which is the heaviest thing on the list: that is the deep capture that can include response bodies, it is off by default, it is chosen per recording, and Chrome shows a banner across the top of the tab for as long as it is attached.

That is a large list. It is large because the product is “capture everything about this page at once”, and we would rather write the list down than have you find it on the store page and wonder.

Running the check properly turned up something we did not know: the manifest also asks for desktopCapture, and nothing in the extension calls it. Screen capture goes through getDisplayMedia, which needs no permission at all. So we are declaring a capability we do not use, which is precisely the thing this article tells you to look for. It is filed, and it comes off in the next release.

The one structural thing we can point at: nothing is captured until somebody presses the button. There is no always-on recording to leave running, which means an update that went bad would have a much smaller window to work in. That is a smaller claim than “trust us”, and it is the only one that is actually checkable.

What we are not saying

We are not saying extensions are dangerous and you should use fewer of them, from a company whose product is an extension. That would be both self-serving and useless advice.

We are saying that marketplace review is a filter and not a guarantee, that this particular operator got through it twice, and that the interval between “installed this once” and “runs in every tab today” is where the risk actually lives. Netskope’s own recommendation is a fleet inventory and a default-deny allowlist, which is the enterprise-sized version of the same thought.

If your team installed a capture tool this year, the useful thing to do this week is open chrome://extensions, read the permission lists you have already granted, and remove the two or three you stopped using in March.

The full analysis, including the code and the timeline, is worth reading in the original: AI Sidebar Extension Monetizes Its Own Updates, Netskope Threat Labs, 11 August 2026.