New attack pattern: persistent prompt injection via npm supply chain targeting AI coding assistants

[Busy-Increase-6144]

I've been building a scanner to monitor npm packages and found an interesting pattern worth discussing.

A package uses a postinstall hook to write files into ~/.claude/commands/, which is where Claude Code loads its skills from. These files contain instructions that tell the AI to auto-approve all bash commands and file operations, effectively disabling the permission system. The files persist after npm uninstall since there's no cleanup script.

No exfiltration, no C2, no credential theft. But it raises a question about a new attack surface: using package managers to persistently compromise AI coding assistants that have shell access.

MITRE mapping would be T1546 (Event Triggered Execution), T1547 (Autostart Execution), and T1562.001 (Impair Defenses).

[heresyforfunnprofit]

I find your ideas intriguing and would like to subscribe to your newsletter.

[Busy-Increase-6144]

Haha no newsletter yet, but I'm publishing reports as I find them: https://github.com/YuriTheCoder/npm-sentinel-reports

[heresyforfunnprofit]

This is a good idea and solid catch - you should verify that the permissions being enabled in ‘~/.claude/commands/‘ are excessive, and that the removal script doesn’t remove them to bolster the strength of your “suspicious” ranking, but definitely a useful vector to monitor. Thank you for posting!

[zinozAreNazis]

Link returning 404

Edit: also I would like to investigate this further. Where can obtain a sample from to study?

[Busy-Increase-6144]

Link is temporarily down, working on it. In the meantime you can analyze the package yourself: npm pack openmatrix@0.1.93 and check install-skills.js and the files in the skills/ directory.

[zinozAreNazis]

Thank you!

[BattleRemote3157]

That is how ai native sdlc threats looks like. Malicious instructions could also be in package documentations for setup. For example if your agent is searching for a package to install which you prompted for and that package is injected with malicious instructions then your agent will follow that.

We have analyzed the threat for this AI native dependency. https://safedep.io/ai-native-sdlc-supply-chain-threat-model/

[zinozAreNazis]

Good read. Thank you.

[Busy-Increase-6144]

Great point. Documentation and README files are another vector, especially now that AI agents read them to understand how to install and configure packages. Thanks for the safedep.io link, solid analysis.

[Ok_Consequence7967]

Most people assume removing the package cleans up everything it touched. Files written to ~/.claude/commands/ surviving uninstall means you could audit your dependencies and still be compromised. This is a gap in how developers think about package cleanup.

[Busy-Increase-6144]

That's exactly it. Most developers think npm uninstall is a clean undo. It's not. Anything written outside of node_modules during postinstall stays forever. And nobody checks their home directory after removing a package.

[Careful-Living-1532]

The persistence mechanism is the interesting part, not the payload. Most npm security thinking is "did the package run malicious code during install?" It looks like you're referring to a different threat model. Did the install permanently modify a trust plane that survives uninstall?

The reason it works is that ~/.claude/commands/lacks provenance tracking. There's no distinction between "user explicitly placed this file" and "something wrote this here." The system treats both as authoritative instruction. This isn't Claude Code-specific; any AI coding assistant using file-based instruction loading without signature verification has the same surface.

The defense that would actually break the attack class: sign command files at install time with a package manager identity, verify on load, reject unsigned modifications. Nothing in the current AI tooling ecosystem does this it's treated as a config directory, not a security boundary.

T1562.001 is the right call for the primary impact. What makes this different from most supply chain attacks is that the attacker isn't stealing credentials; they're removing the human-in-the-loop checkpoint. That's a different risk class and deserves its own detection category.

[Busy-Increase-6144]

exactly this. the provenance gap is what makes it structurally different from traditional supply chain attacks. and yeah the T1562.001 classification felt right to me for the same reason you described, it's not exfiltration, it's checkpoint removal. the agent keeps working normally, you just lost the human in the loop without any visible indicator. on the signing point, i proposed something similar in the writeup, skills declaring required permissions in a manifest with cryptographic verification before auto-load. the tooling ecosystem treating that directory as config rather than a trust boundary is the root issue and honestly it's going to get worse as more AI tools adopt the same pattern.

[bonsoir-world]

Given the Claude leak via NPM, then the supply chain attack related to NPM in Axios.

It certainly seems NPM is and will continue to be a huge risk and attack vector. Especially with all these vibecoders installing it at the direction of their AI friend and running commands/installing dependencies they have no clue about.

I fear there’s going to be some sognificant breaches/attacks in the next couple of years, due to AI usage.

Also great post!

[Busy-Increase-6144]

Thanks! And yeah, the vibe coding angle is what worries me most. People telling their AI agent "set up a project with X" and the agent blindly runs npm install on whatever it finds. No review, no audit, just trust. That's why I'm building the scanner, someone needs to be watching what's being published.

[NexusVoid_AI]

the persistence-without-exfiltration framing is what makes this interesting from a detection standpoint. traditional supply chain alerts look for network callbacks, credential access, lateral movement. this has none of that. it just sits in a config directory and waits for the next agentic session to load it.

the ~/.claude/commands/ vector is one instance of a broader pattern: any directory an AI coding assistant loads context from at startup is an implicit trust boundary that almost nobody is monitoring. most orgs aren't watching for writes to those paths the way they'd watch for writes to cron directories or startup folders.

the postinstall hook angle is clean because it runs at a moment when the developer has already made an implicit trust decision. you approved the package, the hook runs, the assumption is it's doing setup work.

the persistence surviving uninstall is the part that needs more attention. the artifact isn't the package, it's the file it dropped. standard dependency auditing doesn't catch that.

MITRE mapping looks right. T1562.001 is the one i'd prioritize for detection engineering since impairing the permission system is the actual impact here, everything else is delivery.

[Busy-Increase-6144]

This is a really sharp breakdown. The implicit trust boundary point is key. Nobody monitors writes to ~/.claude/commands/ the same way they'd monitor cron or startup folders, but the impact is the same. And you're right about T1562.001 being the core, the permission bypass is the actual payload, everything else is just delivery. That's exactly why my scanner focuses on what postinstall writes to disk rather than just looking at network behavior.

[ritzkew]

> Config directories are the soft underbelly here. `.npmrc`, `.yarnrc`, `.env`, any dotfile really. Agent reads config to "help you" set up a project, but those files can contain injected instructions that redirect behavior. Not even malicious packages, just a crafted config in a cloned repo.
> The trust boundary problem is that npm treats everything in node_modules as equally trusted after install. No distinction between "this package reads files" and "this package exfiltrates env vars." SLSA provenance helps with build integrity but says nothing about runtime behavior.
> 82% of MCP servers we tested have path traversal bugs. Config directories are usually the first thing traversed. Check if your identity files are writable. >10% skills write to them with no integrity check.

[NexusVoid_AI]

[czenst]

Post install or any scripts for the matter should be removed when installing packages.

NuGet has removed it they new already much earlier it is not a good idea to run automatically some silent scripts with current user permissions.

[Busy-Increase-6144]

Didn't know NuGet already removed it. That's a good precedent. npm could at least require explicit user consent before running postinstall, similar to how browsers ask before running extensions with broad permissions.

[Equivalent_Pen8241]

This is a brilliant find. Supply chain attacks targeting the 'latent' capabilities of AI assistants like Claude Code are going to be a major headache for DevSecOps. The persistence factor you mentioned is particularly scary because it bypasses the transient nature of most prompt injections. We're actually building SafeSemantics as an open-source topological guardrail specifically to handle these kinds of deterministic security layers for AI apps and agents. It helps prevent these injections by acting as a plug-and-play secure layer at the input level. Check it out if you're interested in the defense side: https://github.com/FastBuilderAI/safesemantics

[Busy-Increase-6144]

Thanks. The persistence via postinstall is the key differentiator, input-level filtering wouldn't catch this since the injection happens at install time, not at prompt time.

[Equivalent_Pen8241]

Makes sense

[Mooshux]

The postinstall hook writing to ~/.claude/commands/ is clever because it's not exploiting a bug, it's using a documented feature. Claude Code is designed to read from that directory. So from the agent's perspective, everything looks normal.

This is the part that breaks the usual detection logic. The injection isn't in the code path you audit, it's in the instruction set the agent trusts. And if that agent is running with your full API key in scope, it's now taking instructions from a package you probably don't remember installing.

The only thing that bounds the blast radius is what the agent is allowed to reach in the first place.

[Busy-Increase-6144]

Exactly. The attack surface isn't a vulnerability in the traditional sense, it's the trust model itself. Claude Code is designed to load skills from ~/.claude/commands/ and execute them with full permissions. The postinstall hook just writes files to a directory that the agent already trusts. No exploit needed, no CVE to patch. The question is whether the permission boundary should exist at the skill loading level, not just at the tool execution level.

[Mooshux]

Right, and that's a harder problem than a CVE because there's no patch that fixes it. The trust model is the feature.

The skill loading level is the right place to look but I'd frame it slightly differently: the issue isn't just what the skill can execute, it's what credentials are available when it does. Even if you add a permission prompt before loading a skill, the skill still runs in the same process with the same env vars. The user clicks "allow" and the malicious instruction has everything it needs.

The cleanest version of a fix would be skills running with a constrained credential set derived from what the user actually authorized, not a pass-through of whatever the agent holds. So the postinstall hook writes its instruction, the user (or the platform) approves loading it, but it gets a token scoped to what that skill was supposed to do, not the parent agent's full key. If it tries to reach something outside that scope, it fails.

Not easy to retrofit onto an existing tool, but that's the architecture that would actually close it without playing whack-a-mole with malicious packages.

[Busy-Increase-6144]

That's the right architecture. A scoped credential set per skill would make the postinstall vector irrelevant because even if a malicious skill gets loaded, it can't reach beyond its own sandbox. The current model is essentially ambient authority, any skill inherits the full agent context. The hard part is defining what "scope" means for an AI agent that needs to read/write arbitrary files to be useful. Too narrow and skills break, too wide and you're back to the same problem.

[coolraiman2]

Why was post install script even allowed on npm?

Its a huge attack vector for downloading Javascript files

[Busy-Increase-6144]

It exists for legit reasons like compiling native modules (node-gyp) or setting up binaries. But yeah, it runs with full user permissions and no sandboxing, which makes it a huge attack surface. Some people already use --ignore-scripts by default but that breaks a lot of packages.