GlassWorm: from poisoned packages to a fake Chrome extension that watches everything

Security reporting on GlassWorm outlines a multi-stage campaign that often starts on developers’ machines—then escalates to data theft, remote access, and a fake browser extension used for session surveillance. The write-up below summarizes public findings so you can reason about risk and extension permissions on your own systems; treat indicators and versions as signals to verify, not universal truths for every environment.

Primary source: Malwarebytes Labs (March 2026), citing analysis including Aikido on the extension behavior.

How the infection tends to start

Coverage describes GlassWorm spreading through developer channels: malicious or compromised packages on registries such as npm or PyPI, or tampered VS Code extensions. The story is familiar from other extension supply chain cases: a maintainer account is hijacked or a package is typosquatted, and a preinstall script or obfuscated loader runs when dependencies are pulled.

Reporting notes a locale check (for example stopping when a Russian locale is detected—treated as a geofence by the malware, not a guarantee of who is targeted). Later stages reportedly wait, then use a Solana blockchain transaction memo to recover a payload URL instead of hardcoding a single download link—making takedowns noisier for defenders.

Stage two: theft from browsers, wallets, and dev tooling

The second stage is characterized as an infostealer aimed at browser extension profiles, standalone wallet apps, files that might hold seeds or keys, and developer secrets (npm tokens, git credentials, VS Code secrets, cloud credentials). Stolen data is exfiltrated with ordinary network requests (for example HTTP POST), which is why monitoring outbound traffic and credential hygiene matter even when the entry point looks “just” like a bad package install.

If you are mapping this to extension permissions in Chrome, the lesson is indirect but important: compromised developer machines feed wider supply chain risk—stolen tokens and signing paths can affect many downstream users.

Stage three: RAT, persistence, and the fake extension

Later stages reportedly fetch additional modules—including Ledger/Trezor–oriented phishing when hardware wallets are present—and a Node.js RAT with browser credential features and a Chrome extension installer. Persistence is described via scheduled tasks and Run registry keys so the RAT survives reboots.

The RAT’s command and control is said to avoid a fixed address: it may resolve configuration via a distributed hash table (DHT) lookup tied to a pinned public key, with Solana as a fallback channel—again pushing defenders toward behavioral detection rather than static blocklists alone.

What the fake extension is accused of doing

In the example discussed by Aikido and summarized by Malwarebytes, the malware force-installs an extension that masquerades as “Google Docs Offline.” From a browser-capabilities perspective, that is a blunt illustration of why extension management and unexpected new extensions deserve immediate review.

Reported surveillance features include theft or access to third-party cookies, localStorage, the DOM of the active tab, bookmarks, screenshots, keystrokes, clipboard content, a large slice of browsing history (thousands of entries in reporting), and the installed extensions list—capabilities that overlap what broad host permissions, tabs permission, history permission, and clipboard permission discussions try to make legible for users.

None of that requires the victim to “click something obviously wrong” after the initial compromise; the whole point is quiet persistence inside a profile the user already trusts.

What victims might notice

From the user’s chair, reporting suggests subtle signs: unfamiliar outbound connections, new startup entries, or an extension they do not remember installing—especially anything that resembles Google Docs Offline but does not match the legitimate component’s publisher and version story. IOC lists in the original article include defanged IPs, registry keys, scheduled task names, and extension directory names—useful for enterprise hunting, not casual guesswork.

How this connects to safer extension habits

• Audit what each extension can access regularly: if an add-on’s reach does not match its job, treat that as a review trigger. Our extension permissions hub breaks down what common warnings mean.
• Prefer pinned versions and watch for maintainer churn or large rewrites in patch releases—patterns that show up across malicious extension update stories and npm incidents alike.
• Remove anything you do not recognize; fake Chrome extension campaigns often rely on lookalike names and social proof.
• For a structured walkthrough of static vs runtime risk, see analyze browser extension on eSafe.

Reporting trail

This article is a condensed overview of third-party reporting. For full IOC tables, author attribution, and original diagrams, read the Malwarebytes piece in full: GlassWorm attack installs fake browser extension for surveillance.