A fake npm formatter shows how Claude work files become a supply-chain target
The suspect npm package opens a path toward Claude's working directory.📷 AI-generated image / TECH&SPACE
- ★OX Security found the npm package mouse5212-super-formatter with file-stealing behavior.
- ★The attack targeted Claude's workspace for user uploads and generated outputs.
- ★The case expands the risk model from classic developer secrets to AI working files.
A malicious package on the npm registry is no longer just a node_modules problem or a hunt for classic repository secrets. According to The Hacker News, researchers at OX Security found mouse5212-super-formatter, a package with information-stealing capabilities designed to upload files from /mnt/user-data.
The package name sounds ordinary, almost dull: a formatter, the kind of utility a developer might add to a project without much friction. That is precisely why it matters. Supply-chain attacks in the JavaScript ecosystem do not need theatrical packaging; they only need a package to pass through an install path, script, or automated workflow and reach a place it should not be able to read.
The critical detail is the /mnt/user-data path. In the supplied context, it is described as a dedicated directory used by Anthropic's Claude to handle user uploads and generated outputs in the background. That means the target is not limited to .env files, SSH keys, npm tokens, or CI configuration. It can also include documents, code snippets, analyses, temporary exports, and other material a user gives to an AI tool for processing.
OX Security says mouse5212-super-formatter tried to upload files from /mnt/user-data, a directory tied to Claude uploads and generated outputs.
The target is the folder holding AI uploads and outputs.📷 AI-generated image / TECH&SPACE
That changes the threat model. A classic package-registry attack is usually treated as a developer incident: someone installs the wrong dependency, a script runs, and the attacker looks for repository or infrastructure access. Here the surface is wider because the AI tool is also a working directory. If that workspace contains input files and model outputs, a malicious dependency is not only attacking the development process; it may be reaching content that never enters git at all.
The uncomfortable part is that the attack leans on a familiar trust pattern. A formatter is not a category that automatically triggers alarm. In teams that test packages quickly, rely on generated scripts, or push some install decisions into automation, that kind of name can pass as routine plumbing. But any dependency that can read outside the expected project tree should be treated as a security signal, not an implementation footnote.
For organizations using AI assistants in development, the lesson is not to panic about tools such as Claude. The lesson is that AI working directories need to be protected with the same seriousness as source code, secrets, and build artifacts. If a package can reach a folder containing user uploads, dependency review has to cover that data path as well.
In practical terms, that means stricter review of new npm packages, pinned versions, scrutiny of install scripts, and clearer segmentation of directories that development tools are allowed to read. npm's guidance on securing code already frames dependencies as part of the attack surface. This case adds the AI layer to the same equation: once an AI tool becomes a place where users place sensitive files, any helper package that can touch that workspace stops being harmless plumbing.

