Malware-Slop on npm: The Package That Stole Claude Files and Leaked Its Own GitHub Token

Malware-Slop: When the Malicious Package Gives Itself Away

On May 27, 2026, researchers at the security firm OX Security published a technical breakdown of a malicious package found on the public npm registry. The package, named mouse5212-super-formatter, posed as a formatting utility but worked as an infostealer: it lifted files from the working directory of Anthropic’s AI assistant Claude and shipped them off to a GitHub account under the attacker’s control.

What makes this case stand out—and what gave the campaign its name, Malware-Slop—is that the attacker made a rookie operational mistake: they left their private GitHub token sitting right in the package’s source code, exposed to anyone who bothered to look. By the time the analysis went public, the package had racked up 676 downloads and was still live on npm. It has since been reported and pulled from the registry.


What Is npm, and Why Is It Such an Attractive Attack Vector?

Before getting into the incident, it helps to set the scene. npm (Node Package Manager) is the largest public software package registry in the world, with more than two million packages available and over 17 million downloads a day. It’s the backbone of the JavaScript and Node.js ecosystem: just about every modern web or backend project leans on dozens or hundreds of external packages pulled from this registry.

The appeal is obvious: reuse and speed. Rather than writing already-solved functionality from scratch—date parsing, text formatting, HTTP request handling—developers pull in a dependency in seconds. The catch is structural: that trust is, by default, blind. Anyone can publish a package to npm. There’s no mandatory security review before a package goes live. And once installed, a package runs with the same privileges as the process that calls it—including automatic scripts that fire the moment it’s installed.

That’s exactly the model mouse5212-super-formatter exploited.


What Is an Infostealer, and How Does This One Hide?

An infostealer is a type of malware whose main goal isn’t to damage a system or lock it up for ransom, but to quietly collect information and ship it off to whoever’s running it: credentials, access tokens, config files, documents. They’re hard to spot precisely because they don’t disrupt anything—they just watch and exfiltrate.

mouse5212-super-formatter wrapped itself in a carefully built cover story to avoid raising flags:

OX Security’s analysis flags a telling detail: the code deliberately steered clear of patterns that tend to give away AI-generated code—things like redundant comments or comments in unexpected languages—specifically to avoid looking automated. The attacker took that camouflage precaution and, at the same time, left their own private token embedded in the code. That contradiction—careful about the cosmetic, careless about the critical—is the signature of this kind of threat.

In reality, none of the advertised functionality existed. It was all a front.


The Incident: How the Attack Works, Step by Step

The malicious payload fired during npm’s postinstall lifecycle stage—the moment the package finishes installing, with no further action needed from the user. The chain of execution went like this:

Step 1 — Authenticating to GitHub

The script first looked for a GitHub access token in the system’s environment variables. If it didn’t find one, it fell back on a token hardcoded directly into the code. That fallback is what ultimately exposed the attacker: the token pointed to their own GitHub account and sat in plain text for anyone reviewing the package’s source.

Step 2 — Setting Up the Exfiltration Repository

With an active token, the malware checked whether a repository already existed in the attacker’s account to store the stolen data. If not, it created one automatically through the GitHub API.

Step 3 — Recursive File Collection

The script walked the /mnt/user-data directory recursively—the path Anthropic’s Claude uses to handle file uploads, downloads, and outputs behind the scenes. Every file in that path was fair game for exfiltration. Files were base64-encoded before being sent off, a basic obfuscation trick to disguise the outbound content from a casual look at the traffic.

Step 4 — Organized Exfiltration

The files were uploaded to the attacker’s repository under randomly named folders generated per run. That let the operator keep stolen data from different victims separate rather than jumbled together.

Attack Flow at a Glance

npm install mouse5212-super-formatter
         │
         ▼
postinstall script runs automatically
         │
         ▼
Authenticate to GitHub (env token or hardcoded token)
         │
         ▼
Create exfiltration repository if it doesn't exist
         │
         ▼
Recursively walk /mnt/user-data
         │
         ▼
base64-encode + upload files via the GitHub Contents API
         │
         ▼
Data stored in a random folder in the attacker's repository

The whole thing ran completely silently: no visible errors, no interruption to the developer’s workflow, and no obvious traces in the system logs.


Why Is Claude AI’s Directory Such a Valuable Target?

The /mnt/user-data directory wasn’t a random pick. It’s the path Anthropic’s Claude uses to handle files during operation: documents uploaded for analysis, generated outputs, intermediate working data. For a developer who uses Claude day to day, that directory can hold:

This kind of attack marks a shift in what malware goes after: instead of targeting operating systems or traditional databases, attackers are starting to zero in on the data surfaces created by the AI tools woven into developers’ workflows. The risk is especially acute in corporate settings, where a single Claude instance can concentrate the output of dozens of engineers or analysts in its working directory.


The Mistake That Gave It Away: The Hardcoded Token and the Malware-Slop Paradox

The most striking feature of this case—and the one that named the Malware-Slop campaign—is the attacker’s own operational blunder. Embedded in the package’s source code, visible to anyone who downloaded and examined it, was the attacker’s private GitHub token, sitting there as a fallback for authentication.

That token was enough for OX Security’s researchers to:

The term Malware-Slop captures the dynamic exactly: malicious code thrown together carelessly, most likely with help from generative AI tools, by someone who neither understands nor applies even the basics of anonymity and operational security (OPSEC). And this isn’t a one-off. The same pattern showed up earlier this year in VoidLink, a Linux malware strain that researchers concluded was largely built by an AI agent under the direction of a single person. AI lowered the bar for building the malware—but it also stripped away the friction that used to force attackers to learn basic OPSEC before going operational.

There’s an important caveat, though, against the temptation to wave these threats off as “sloppy”: even imperfect malware can do real damage if it reaches enough users before it’s caught. With 676 downloads before detection, this package wasn’t a failed experiment—it was a real incident with genuine potential for data exposure.

OX Security sums up the outlook plainly: now that the cost of producing malicious code has dropped sharply, expect a wave of inexperienced actors publishing sloppy malware—often imitating more sophisticated groups—until registries like npm roll out systematic, automated blocking for this kind of package.


The Bigger Picture: Software Supply Chain Attacks

This incident is a concrete example of what’s known as a software supply chain attack. The premise is simple, which is exactly why it works: rather than breaking into the victim’s system directly—which means getting past active security controls—the attacker plants malicious code in a software dependency the victim installs willingly.

Public package registries like npm are the infrastructure modern development is built on. That trust is precisely what attackers exploit. The developer didn’t install malware; they installed what looked like a formatting tool. For anyone who doesn’t read the code of every dependency—which is the vast majority of developers, for perfectly good practical reasons—there’s no visible warning sign anywhere in the normal workflow.

On top of that comes the emerging risk specific to this case: malware that targets AI tools. As assistants get baked into development workflows—Claude, GitHub Copilot, Cursor, Gemini Code—the working directories of these tools turn into concentrated stores of sensitive information. They’re a high-value target with a relatively new, and therefore less-watched, attack surface compared with traditional vectors.


Affected Systems and Assets

At Risk for Anyone Who Installed the Package

Scope of the Incident (per OX Security’s analysis)

⚠️ Note: If you installed mouse5212-super-formatter in any environment, treat the files in /mnt/user-data—and any GitHub token available in that environment—as potentially compromised.


Indicators of Compromise (IOCs)

Type Indicator Description
Package name mouse5212-super-formatter Malicious npm infostealer; all versions affected
Target path /mnt/user-data Local directory walked recursively for exfiltration
Exfiltration method GitHub Contents API Used to upload stolen files to the attacker’s repository
Obfuscation technique base64 encoding Applied to file contents during exfiltration
Attacker account unplowed3584 (GitHub) Created hours before publication; deleted after detection

Security Recommendations

Immediate Steps If You Installed the Package

Before Installing Any Package

For Security and DevSecOps Teams


Wrapping up…

mouse5212-super-formatter is a compact but revealing case of how two trends are converging to shape the threat landscape for years to come: the abuse of open-source distribution ecosystems as an attack vector, and malware built specifically to go after the data surfaces that AI tools generate.

The technical failure is simple: a postinstall script with network access that nobody reviewed before running it. The systemic problem runs deeper. The npm registry runs on a model of implicit trust that doesn’t scale well against malicious actors armed with tools that slash the cost of producing harmful code. When spinning up a working infostealer takes hours instead of weeks, the number of attempts climbs—and with it, the odds that one slips through unnoticed long enough to do real harm.

The case also lays bare the central paradox of Malware-Slop: the same AI that lowered the bar for writing the code also removed the friction that used to force attackers to learn basic OPSEC. The result is malware that’s more frequent but sloppier. Sometimes, as it did here, that means the attacker gives themselves away. But even clumsy malware can do real damage: the 676 users who installed this package got no benefit from the attacker’s mistake until researchers found it. Early detection was possible thanks to the exposed token—a lucky break for defenders, not a structural safeguard.

The same pattern is documented in VoidLink, the Linux malware built by a single person with AI, and in other recent npm supply chain incidents. The trend isn’t new, but the speed at which new actors can now get into the game is.

The lesson isn’t to stop using npm or to pull AI tools out of the workflow. It’s to recognize that the trust placed in any external dependency is always provisional, and that the working directories of AI assistants are now every bit as critical as any production database. They deserve the same level of scrutiny.

And in the case of mouse5212-super-formatter, all it took was one npm install.


Sources: