Malicious npm package went after Claude workspace files

Source: The Hacker News — https://thehackernews.com/2026/05/malicious-npm-package-stole-files-from.html

An npm package targeted Claude’s local working files#

Researchers at OX Security found a malicious npm package that attempted to steal files from a directory used by Anthropic’s Claude AI tool. The package, named mouse5212-super-formatter, was published to npm and, according to the report, was still available for download at the time of publication.

The target path matters: /mnt/user-data. OX describes it as a dedicated directory Claude uses to handle uploads and outputs in the background. In practice, that can include the kind of material users hand to an AI assistant precisely because they want help with it: documents, code, generated files, workspace artifacts, and other local context.

This was not a browser phishing page or a fake login screen. It was a package-install attack. The malicious behavior ran during the npm postinstall stage, the point where many packages legitimately execute setup scripts. That makes this class of attack familiar but still effective: a developer or automation system installs what looks like a utility package, and the install process becomes the execution point.

OX said the package presented itself as an internal “archive deployment sync” utility. The cover story was mundane: validate or initialize a GitHub repository, take a lightweight network-status snapshot, and synchronize workspace files into a remote tracking tree. That description is close enough to normal developer tooling to avoid looking absurd at first glance.

The real behavior was simpler and more damaging. The package authenticated to GitHub, checked for a target repository, created it if needed, and recursively uploaded local files to attacker-controlled storage.

GitHub was used as the exfiltration path#

The malware tried to authenticate with a GitHub access token found in the victim’s environment. If that was not available, OX said it used a hard-coded token as a fallback. It then used GitHub as the transport and storage layer for stolen files.

That choice is not exotic. GitHub traffic is common on developer machines, CI runners, and build environments. A tool that touches GitHub during installation may not stand out, especially if the package already claims to be doing repository sync work.

OX reported that stolen files were placed in randomly named folders. That likely helped the operator separate theft sessions from different victims or installs. The package also wrote a fake “network connections” log, giving the impression that it was collecting diagnostic data while hiding the more important action: unauthorized recursive upload of local workspace data.

The reported download count was 676. That number should be treated carefully. npm download counts do not equal successful compromise. They can include automated mirrors, scanners, repeated fetches, failed installs, or security research activity. The source does not establish how many real systems executed the package or how many had sensitive Claude files available under the target path.

The GitHub account linked to the campaign was no longer available when reported. OX said the account had been created on May 26, 2026, only a few hours before the first malicious package version was uploaded to npm. That short timeline points to a throwaway operation, not a long-lived developer persona.

The sloppy OPSEC is part of the story#

One detail stands out: the package allegedly leaked information about the GitHub account, including its private token. That is bad tradecraft. It also fits a wider pattern security teams are starting to see: lower-skill actors can now assemble functional malware faster, but speed does not make them careful.

OX suggested the actor may have used AI to generate the malware while failing basic operational security. That is plausible, but it should not be overstated from the public facts alone. The evidence supports “sloppy malware with signs consistent with AI-assisted development” more strongly than it supports a firm attribution to AI-generated code.

The more useful point is structural. npm already gives attackers a distribution channel, dependency trust, install-time execution, and access to developer environments. AI-assisted coding may lower the effort required to build a malicious package, but the attack path did not need a novel exploit. It used the old supply-chain shape: publish package, trigger script, collect files, move them through a trusted platform.

The Claude-specific targeting makes the incident sharper. AI tools are becoming workspace concentrators. Users upload source code, contracts, logs, data exports, research notes, screenshots, and internal drafts. If a local assistant directory is predictable and readable, malware does not need to understand the AI product deeply. It only needs to know where useful files land.

What defenders should check#

Teams that use npm and AI coding or document tools should treat this as a workstation and build-environment exposure, not only as an npm registry issue.

Practical checks:

• Search package manifests, lockfiles, install logs, shell history, and CI logs for mouse5212-super-formatter.
• Review npm install activity around the package publication window if logs are available.
• Check for unexpected GitHub repository creation, especially from developer tokens or automation tokens.
• Review GitHub token usage, scopes, and recent API activity.
• Rotate any GitHub tokens that may have been exposed in environments where the package was installed.
• Inspect systems for unexpected access to /mnt/user-data or equivalent Claude workspace paths.
• Treat files uploaded to Claude workspaces as potentially sensitive local data, not disposable cache.

The key control is not a single blocklist entry. Block this package, yes. But the durable risk is install-time execution combined with broad filesystem and token access. A malicious package does not need administrator privileges if the current user already has access to useful files and credentials.

For developer machines and CI environments, the harder questions are about defaults:

• Which installs are allowed to run lifecycle scripts?
• Which environments expose GitHub tokens to arbitrary package installation steps?
• Which AI workspace directories are readable by general tooling?
• Which outbound destinations are normal enough to hide exfiltration?

None of those questions are new. AI tools just raise the value of the local directories attackers will search first.

What not to overclaim#

The public report does not prove widespread compromise. The reported 676 downloads are a signal, not a victim count. The unavailable GitHub account limits independent visibility into what was received, retained, or deleted. The source also does not establish that every install had Claude data in the targeted directory.

It is also too early to treat this as a sophisticated AI-era attack. The mechanics are conventional. The packaging is deceptive but not subtle. The OPSEC appears weak. That does not make the incident harmless; it makes it more worrying in a different way. If low-quality malware can still reach AI workspace files through a public package registry, the threshold for useful theft is low.

The clean lesson is this: AI workspaces are now part of the developer attack surface. Package installs, lifecycle scripts, local assistant directories, and GitHub tokens sit close together on many machines. Attackers do not need to break the AI model to steal what users gave it.