ShotBird Malware Proves It Again: How to Evaluate Whether a Chrome Extension Is Safe — HeaderSnap ModHeader was removed from Chrome & Edge over a hidden data collector — what happened and what to do
HeaderSnap
← All posts
March 16, 2026

ShotBird Malware Proves It Again: How to Evaluate Whether a Chrome Extension Is Safe

In March 2026, a Chrome extension called ShotBird changed hands. Within days of the transfer, the extension was pulling instructions from a command-and-control server.

It wasn’t a hack. No one broke into anything. The developer sold the extension, the new owner pushed an update, and the malware was live — instantly distributed to every user who had it installed. Chrome’s extension update mechanism worked exactly as designed.

This is the second major Chrome extension ownership transfer attack in as many months. The QuickLens incident covered similar ground in February. If you thought that was a fluke, ShotBird is the pattern confirmation.

What Happened with ShotBird

The ShotBird attack followed the same playbook that security researchers have been documenting for years: acquire a trusted extension with an established user base, then use that trust as a delivery mechanism for malicious code.

Once the ownership transferred, the updated extension began reaching out to external servers for instructions. That’s the C&C (command-and-control) model that malware authors use specifically because it’s flexible — the extension payload can be changed or updated remotely without pushing another Chrome store update. Your browser installed a trusted tool; what that tool does can shift at any time, controlled by whoever now owns the server it calls home.

For developers and QA engineers who use browser extensions with broad network permissions, that’s a significant problem. A header editor legitimately has access to every HTTP request your browser makes. So does ShotBird’s new code — except now it’s using that access for something else.

CVE-2026-0628: When Extensions Attack AI

The ShotBird incident is bad. The vulnerability disclosed as CVE-2026-0628 is a different kind of concerning.

CVE-2026-0628 affects Chrome versions up to 143.0.7499.192 (now patched). The vulnerability allows malicious browser extensions to hijack Chrome’s Gemini AI panel — the integrated AI assistant that’s increasingly baked into Chrome’s UI. An attacker-controlled extension can use the Gemini panel as a vector for privilege escalation and data exfiltration.

This matters for a few reasons beyond the specific CVE:

The attack surface is growing. Chrome extensions used to be mostly about manipulating web page content. Now they operate in an environment where the browser has integrated AI features, payment flows, password management, and enterprise SSO integrations. An extension with broad permissions doesn’t just see your HTTP traffic anymore — it potentially touches all of that.

Trust escalates with the attack surface. The more capable Chrome becomes as a platform, the more important it is to know exactly what your extensions are doing. A closed-source extension with broad permissions in 2026 is a much bigger trust surface than it was in 2020.

Update Chrome if you haven’t already. CVE-2026-0628 is patched in Chrome 143.0.7499.192 and later — but the underlying problem it exposes (extensions as a privilege escalation path in an increasingly capable browser) isn’t going away.

ShadyPanda: This Has Been Going On for Seven Years

ShotBird and CVE-2026-0628 feel like new problems, but the ShadyPanda campaign puts them in context.

ShadyPanda is an ongoing threat campaign targeting Chrome and Edge users. It has been running for approximately seven years and has infected an estimated 4.3 million users across both browsers. The campaign uses a mix of techniques — malicious extensions, ownership transfers, and update hijacking — to maintain persistence on infected machines and harvest data.

Seven years. 4.3 million users. Those aren’t numbers that suggest a niche or emerging threat. They describe a mature, industrial-scale operation that has been running continuously while Chrome users installed and trusted extensions.

The ShadyPanda campaign is why “this extension has good reviews and has been around for a while” isn’t sufficient reassurance. Reviews reflect a historical trust snapshot. A good track record is evidence of the past, not a guarantee of the present.

The Common Thread

QuickLens, ShotBird, CVE-2026-0628, ShadyPanda — these aren’t separate problems. They’re different exploits against the same fundamental issue: most Chrome extensions are opaque.

When an extension is closed-source:

  • You cannot verify what the code does with your network traffic
  • You cannot detect when behavior changes between updates
  • You have no way to know if the extension has changed ownership
  • You have no mechanism to audit what servers it communicates with

Every trust assumption you make about a closed-source extension is based on reputation earned at a point in time. Reputation doesn’t transfer when ownership changes. Reputation doesn’t prevent a silent update from adding malicious logic. Reputation doesn’t help you when a third-party C&C server starts issuing new instructions to code already running in your browser.

Open-source extensions solve this directly. When the code is public:

  • The extension’s behavior is verifiable by anyone
  • Ownership changes show up in commit history and contributor activity
  • Every update is auditable — not just “what the changelog says” but what the code actually does
  • The community can spot anomalies: unusual new dependencies, new outbound connections, behavioral changes that don’t match the stated purpose

An open-source extension can still be written badly. But a malicious update to an open-source extension cannot hide.

What to Look for Before Installing Any Extension

Given the current threat environment, here’s a practical evaluation checklist for any Chrome extension with network access:

Check the repository. Public source code is a strong trust signal — it lets you verify behavior independently and detect ownership changes through commit history. Search for the extension name plus GitHub. If no public repository exists, look for architectural transparency instead: which APIs does the extension use? What permissions does it declare? Can the trust signal be verified another way (for example, from the Chrome Web Store permissions manifest)?

Review the commit history. Look for recent activity, who’s contributing, and whether the commit messages make sense for the stated feature set. Unusual commits shortly before a malicious report is a common pattern.

Check for ownership changes. The Chrome Web Store doesn’t surface this prominently. Search Reddit, developer forums, and Twitter/X for the extension name — existing users often flag ownership changes in reviews or community posts.

Audit the permissions. Broad permissions (<all_urls>, webRequest, tabs) are legitimate requirements for developer tools. They’re yellow flags for extensions that don’t have an obvious reason to need them.

Look for outbound network calls. This is harder without reading the code, but the presence of external API endpoints or analytics calls in an extension that doesn’t need them is a clear warning sign.

HeaderSnap’s Position on This

HeaderSnap is a header editor — which means it has exactly the kind of broad network access that makes supply chain attacks dangerous. We think the appropriate response to that is a verifiable technical architecture.

HeaderSnap is not open-source. The source code is not publicly available for review. Trust in HeaderSnap comes from architectural constraints, not source code availability — and those constraints are verifiable from the extension itself.

HeaderSnap modifies the headers you explicitly configure — request or response — nothing else. It doesn’t inject scripts, phone home, or collect data about your traffic.

The key difference is architectural. HeaderSnap uses Chrome’s native declarativeNetRequest API — a declarative rule system where Chrome itself applies the header modifications, rather than JavaScript code intercepting live requests. The extension declares rules; the browser enforces them. There is no persistent service worker monitoring your traffic.

There are no outbound connections to external servers. No analytics endpoints. No telemetry. The manifest requests only declarativeNetRequest, declarativeNetRequestWithHostAccess, and storage permissions — nothing that would enable calling home. You can verify these permissions yourself after installing: open chrome://extensions, click Details on HeaderSnap, and review the permissions listed. Header rules are stored in Chrome’s sync storage, on your device and in your Google account.

Architectural trust and source-code trust are different things. Open-source is a stronger guarantee. But an extension whose permission manifest explicitly limits what it can do — and whose API choice (declarativeNetRequest vs webRequest) structurally prevents it from intercepting or forwarding request data — is meaningfully more verifiable than a closed-source extension with broad webRequest permissions and no architectural constraints.

For more context on the extension supply chain threat landscape, the ShadyPanda campaign has been covered extensively by security research outlets. The ShotBird and CVE-2026-0628 details emerged in March 2026 from multiple security reporting sources.