←back to thread

Malicious versions of Nx and some supporting plugins were published

(github.com)
441 points longcat | 1 comments | 27 Aug 25 01:38 UTC | HN request time: 0.341s | source
Show context
mdrzn ◴[27 Aug 25 12:58 UTC] No.45039032[source]▶
the truly chilling part is using a local llm to find secrets. it's a new form of living off the land, where the malicious logic is in the prompt, not the code. this sidesteps most static analysis.

the entry point is the same old post-install problem we've never fixed, but the payload is next-gen. how do you even defend against malicious prompts?

replies(1): >>45040046 #
christophilus ◴[27 Aug 25 14:15 UTC] No.45040046[source]▶
Run Claude Code in a locked down container or VM that has no access to sensitive data, and review all of the code it commits?
replies(2): >>45040397 #>>45041032 #
spacebanana7 ◴[27 Aug 25 15:27 UTC] No.45041032[source]▶
Conceivably couldn’t a post install script be used for the malicious dependency to install its own instance of Claude code (or similar tool)?

In which case you couldn’t really separate your dev environment from a hostile LLM.

replies(2): >>45045892 #>>45051046 #
1. christophilus ◴[28 Aug 25 11:53 UTC] No.45051046[source]▶
I run npm in the container, too, along with my dev tooling. They’d have to break out of the container, which I’m sure is possible, but is a good bit harder than just running an arbitrary nom script.