The security community has spent considerable energy discussing what sophisticated AI-generated malware might look like when deployed by nation-state actors with mature operational security practices. A more immediate problem is becoming visible in the npm registry right now: low-quality, AI-assisted malware written by threat actors with poor tradecraft, targeting developer environments at volume, and succeeding often enough to matter. The discovery of “mouse5212-super-formatter” by OX Security researchers — a package that stole files from Anthropic’s Claude AI user directory and uploaded them to a threat actor-controlled GitHub account — is a case study in what happens when the barrier to writing functional malware drops to near zero while the barrier to detecting and removing it from package registries remains stubbornly high.
The campaign, codenamed Malware-Slop by OX Security, leaked the attacker’s own GitHub token in the malicious package code. The operational security failure is almost comically basic. It also doesn’t matter. The package was downloaded 676 times before the GitHub account was taken down.
What the Package Did and Why the Target Was Specific
“mouse5212-super-formatter” operated through the standard npm postinstall hook execution pattern — malicious code running automatically during package installation, before any developer has had an opportunity to review what just executed on their system. The package presented itself as an internal archive deployment sync utility, generating fake network connection logs designed to give the impression of legitimate diagnostic activity while the actual operation proceeded in parallel.
The actual operation was precise in its targeting. The package authenticated to GitHub using either a token found in the victim’s environment or a hardcoded fallback token, verified or created a target repository on a threat actor-controlled GitHub account, then recursively uploaded every file from /mnt/user-data — the directory that Anthropic’s Claude AI tool uses for uploads and outputs — to that repository. Stolen files were organized into randomly named folders to distinguish between theft sessions from different victims.
The specific targeting of /mnt/user-data is not accidental. This directory in Claude’s operational context contains the files that users upload for AI processing and the outputs that Claude generates — documents, data files, code, research materials, and whatever else users are feeding into their AI workflows. For enterprise users running Claude in professional contexts, that directory likely contains sensitive business documents, proprietary code, confidential communications, and internal data that users uploaded expecting it to remain within their control. The attacker who designed this package understood exactly what that directory contains and built the exfiltration logic around accessing it specifically.
The OPSEC Failure That Reveals the Broader Trend
The leaked GitHub token embedded in the package code is the detail that OX Security highlights as evidence of AI-assisted malware generation without adequate review. A developer — human or AI-generated — who hardcodes a live authentication token into code that will be distributed publicly is committing a basic operational security error that any experienced threat actor would catch in review. The implication is that this package was written, or substantially generated, without the human review layer that would have caught the error before publication.
That inference, if accurate, has significant implications for the volume trajectory of npm-hosted malware. OX Security’s assessment is direct: now that the barrier to creating malicious code has been significantly reduced, more threat actors will enter the space — uploading increasingly numerous low-quality malware packages, largely mimicking APT tradecraft to extract value until automated blocking catches up. The Malware-Slop campaign name reflects that assessment of the quality tier being created: functional enough to steal data, sloppy enough to leak its own credentials.
The 676 download count before takedown, combined with the GitHub account having been created just hours before the first malicious version was uploaded, illustrates the timeline compression that makes this volume threat difficult to manage. The package existed for a short window, was functional within that window, and accumulated hundreds of potential victim installs before the infrastructure was disrupted. A threat actor running dozens of similar packages simultaneously — each with slightly different naming, slightly different targeting, slightly different evasion — creates a detection and response challenge that manual registry monitoring cannot address at pace.
What Enterprise Security Teams Running AI Developer Tooling Need to Assess
The specific targeting of Claude’s user data directory introduces a security consideration that most enterprise AI deployment programs have not explicitly addressed: the files that users upload to AI tools represent a data exposure surface that is distinct from, and frequently more sensitive than, the AI tool’s output or configuration. Employees uploading contracts, financial models, source code, customer data, and internal communications to AI productivity tools are creating a concentrated data pool in a specific filesystem location that is now a documented malware target.
Enterprise security teams should audit what data categories employees are uploading to AI tools, whether those tools’ operating directories are within scope of existing DLP monitoring, and whether filesystem access to AI tool data directories is appropriately restricted to the AI application itself rather than accessible to any process running under the user’s account. The postinstall hook execution pattern — which is how this package delivered its payload — runs under the permissions of the user executing npm install, meaning it inherits access to everything that user can reach, including AI tool data directories.
For organizations that have deployed Claude or other AI tools with local filesystem integration in developer environments, the /mnt/user-data targeting in Malware-Slop is a direct indicator that the intersection of npm package installation and AI tool data directories is a known attack surface that requires explicit security architecture attention.
The npm Registry’s Structural Challenge Isn’t Getting Easier
The package remained available for download at the time of OX Security’s publication. The GitHub account linked to the campaign was created the same day as the malicious upload and disabled after the campaign was identified — a lifecycle that provided a functional operational window despite minimal infrastructure investment from the attacker. This pattern, repeated across the supply chain attack campaigns documented throughout 2026 — TrapDoor’s 34 packages across three ecosystems, the TanStack compromise affecting Grafana and OpenAI, the Mini Shai-Hulud worm hitting multiple AI packages — reflects a sustained pressure on package registry security that incremental moderation improvements are not keeping pace with.
The registry detection problem is structurally difficult. Legitimate package names are indistinguishable from typosquatting attempts without behavioral analysis. Postinstall hooks serve legitimate purposes and cannot be blanket-blocked without breaking a significant portion of the npm ecosystem. Malicious packages that mimic plausible utility names — “super-formatter” is a credible-sounding development tool — do not trigger name-based heuristics. The detection burden falls on behavioral analysis of package code, which requires either automated static analysis at submission time or rapid response to researcher disclosure after publication.
Neither approach currently operates at the speed that AI-assisted malware generation enables on the attacker side. The gap between how fast low-quality malware can be published and how fast registries can identify and remove it is the operational window that Malware-Slop exploited. Until that gap closes, enterprise developer security programs need to treat the npm registry as an untrusted distribution channel requiring independent verification — not as a curated resource with adequate security controls already in place.
Research and Intelligence Sources: OX Security
To participate in our interviews, please write to our CyberTech Media Room at info@intentamplify.com
