900K Developers Had Their AI Conversations Stolen by Fake Chrome Extensions

As of March 19, 2026, two malicious Chrome extensions are actively harvesting AI conversations from more than 900,000 users. The extensions impersonate popular AI assistants. Both carry Google’s “Featured” badge. Most victims have no idea they’re compromised.

Here’s what happened, how it works, and how to tell whether the extensions you’re using can actually be trusted.

What Was Stolen

The two extensions at the center of this incident are:

“Chat GPT for Chrome with GPT-5, Claude Sonnet & DeepSeek AI” — 600,000+ users, still active at time of writing
“AI Sidebar with Deepseek, ChatGPT, Claude and more” — 300,000+ users, also still active

Both operate through passive conversation monitoring. The extension sits alongside your AI chat sessions and systematically stages your conversations for exfiltration to attacker-controlled infrastructure. From the user’s perspective, nothing looks wrong — the extension doesn’t behave unusually, doesn’t throw errors, and doesn’t request new permissions. It just quietly reads everything.

For developers, the exposure is severe. Think about what passes through a typical AI coding session: code snippets, architecture questions, system prompts, database schemas, and frequently, API keys and authentication tokens pasted in for context. That data is now in the hands of whoever controls these extensions.

Why Google’s Badge Meant Nothing

Both extensions were marked with Google’s Chrome “Featured” badge — the green checkmark that’s supposed to indicate legitimacy and quality. It didn’t help here.

The Featured badge is a signal about surface-level compliance: the extension passed basic policy checks and meets some quality criteria. It is not a security audit. It does not mean Google reviewed the source code for malicious behavior. It does not prevent an extension from using passive monitoring techniques that harvest data without obviously breaking any single rule.

This is the same pattern we saw with earlier incidents — the ShotBird ownership transfer attack, the QuickLens header-stripping malware in February 2026, and the VK Styles campaign that compromised 500,000 VKontakte accounts. In all of these cases, the extensions looked legitimate by every surface-level check. Total users affected by Chrome extension malware in Q1 2026 has now exceeded 40 million.

Featured doesn’t mean safe. It means reviewed by an automated system that malicious actors have had years to study and work around.

How the Attack Works

Fake AI extensions are a more sophisticated evolution of earlier malware tactics. Previous attacks relied on modification — injecting malicious code into web pages, stealing cookies, or stripping security headers. Those approaches are visible in network traffic and easier to catch.

This generation is different. The extensions operate passively. They do not modify your AI conversations. They do not change page behavior. They simply observe, buffer, and send.

The attack pattern:

Impersonation as a trust layer. The extension presents itself as a useful AI productivity tool. The name explicitly invokes the AI services your team already uses — ChatGPT, Claude, DeepSeek — creating an association with trusted brands.
Google Featured badge as legitimacy signal. Users encountering an unfamiliar extension apply the same mental shorthand they use everywhere: badges from authoritative sources mean safety. The badge does the social engineering work.
Passive operation to avoid detection. The extension doesn’t behave unusually in any way a user would notice. No slow-down, no errors, no unusual permission prompts. It’s active from installation, reading silently.
Staged exfiltration. Conversation data is buffered and sent to attacker infrastructure in batches, avoiding the kind of unusual outbound traffic spike that security tools sometimes flag.

Permission architecture is a verifiable defense against this kind of attack — and it’s something any user can check before installing. Source code visibility, where available, provides an additional layer.

What Developers Are Actually Risking

Developers who use AI coding assistants professionally — and most do at this point — tend to be more exposed than average users because of what they put into those conversations.

A typical developer AI session might include:

Partial or complete source code
Database schema and query logic
Infrastructure configuration
API endpoints, authentication patterns
Actual API keys, database connection strings, or tokens pasted for context

That last category is the highest-severity risk. API keys and tokens exfiltrated through a Chrome extension are functionally identical to a credential leak from a breach — they can be used immediately, and the victim often has no idea they’re compromised until something breaks or a security audit surfaces the activity.

Code snippets and architectural context are a secondary concern: they represent proprietary logic and internal system knowledge that competitors or attackers can use.

The Pattern Is Not Going Away

This is not an isolated event. It’s the current quarter alone:

January 2026: Cookie harvesting campaign, 37.4 million users affected
February 2026: QuickLens malware — header stripping, designed to intercept API traffic
February 2026: VK Styles campaign — 500,000 VKontakte account hijackings
March 2026: ShotBird ownership transfer → active malware via C&C server
March 2026: CVE-2026-0628 — Gemini AI panel hijacking vulnerability in Chrome
March 2026: Two fake AI extensions, 900,000 users actively compromised

The frequency and sophistication of these attacks reflect a simple economic reality: Chrome extensions with broad permissions have access to valuable data, and that access is worth pursuing. As AI assistants become a more central part of developer workflows, AI-adjacent extensions become a higher-priority target.

How to Evaluate Whether a Chrome Extension Can Be Trusted

There is no badge, no rating, and no review process that provides meaningful safety guarantees for a Chrome extension. Every surface-level trust signal can be faked or gamed.

Two signals are harder to fake:

Permission architecture. Every Chrome extension declares exactly which permissions it requires. <all_urls> or host_permissions covering broad domains means the extension can read and modify your traffic on those sites. tabs permission gives access to your browsing activity. storage is typically benign — it saves settings locally. declarativeNetRequest lets an extension apply header-modification rules without direct page content access — a structurally different and more limited model. Before installing any extension with network access, check what it’s actually asking for. Chrome shows this in the Web Store before you install, no technical knowledge required.

Source code visibility — where available — provides an additional layer. Extensions with publicly viewable source code allow anyone to read what the extension does with your network requests and page data, see behavioral changes between versions in commit history, and spot unusual new dependencies before they affect users. An extension with public source can still be written badly. But a malicious update to a publicly visible codebase cannot hide.

The two fake AI extensions at the center of this incident had permissions consistent with what they claimed to do — they were designed to look legitimate. But the combination of broad page-content access with passive data staging to external servers is the behavioral profile of an extension you should not trust.

Practical Steps If You’re Exposed

If you’ve had either extension installed, treat your AI-adjacent credentials as compromised:

Rotate any API keys you’ve pasted into ChatGPT, Claude, DeepSeek, or similar services while the extension was active
Review recent authentication in services you use heavily — look for sessions or access patterns you don’t recognize
Remove both extensions immediately and check your Chrome extension list for anything you don’t specifically remember installing
Audit your remaining extensions — especially any with permissions to <all_urls> or access to all sites

Going forward: before installing any extension with broad network access, start with its permissions. What is the extension actually asking for? <all_urls> or broad host access means the extension can read and modify your traffic on any site. declarativeNetRequest is a structurally more limited model — it applies rules without direct content access. Permissions are checkable before you install, by anyone, directly from the Chrome Web Store. Source code, where publicly available, provides additional verification.

HeaderSnap’s Approach

HeaderSnap is a header editor — and header editors legitimately require broad network access to do their job. We think the appropriate response to that level of access is a transparent permission model.

If you want to know what an extension can do with your traffic — start with its permissions. HeaderSnap declares three permissions: declarativeNetRequest (to modify HTTP headers via rules), declarativeNetRequestWithHostAccess (required to apply those rules to sites), and storage (to save your rules). It also declares <all_urls> as a host permission — necessary for a header editor to work across any site. What it does not have: tabs, scripting, webRequest, or any permission that gives access to page content or conversation data. No access to your AI conversations. No cloud backend. No analytics. Completely free. You can verify all of this from the Chrome Web Store permissions dialog before you ever install it.

Details on both malicious extensions emerged from security reporting on March 19, 2026. The broader Chrome extension malware statistics referenced here reflect Q1 2026 incidents covered by security research sources.