Join our Newsletter — 33% off our NHI Course

Notifications
Clear all

npm postinstall abuse and Hugging Face C2: what teams missed


(@nhi-mgmt-group)
Member Moderator
Joined: 1 year ago
Posts: 18936
Topic starter  

TL;DR: The js-logger-pack campaign shows how a plausible npm package can turn developer installs into cross-platform malware delivery, using postinstall execution, persistent implants, and Hugging Face for both payload hosting and stolen-data staging, according to Corgea. Package installation is still being treated as trusted code execution, and that assumption now creates broad compromise risk across developer workstations and CI runners.

NHIMG editorial — based on content published by Corgea: js-logger-pack shows how npm install became a malware delivery chain

By the numbers:

Questions worth separating out

Q: How should security teams handle package install-time execution in CI environments?

A: Treat package installation as a potential execution event, not a benign download.

Q: What breaks when supply-chain poisoning reaches developer workstations and CI runners?

A: The main failure is assuming a compromised package only affects one project.

Q: What do security teams get wrong about malicious npm packages?

A: Teams often focus on whether the source package looks legitimate and miss the transitive dependency that actually runs the payload.

Practitioner guidance

  • Disable package lifecycle scripts by default Block preinstall, install, and postinstall execution in high-risk CI contexts unless a package is explicitly allowlisted and justified by ownership, provenance, and review.
  • Rebuild any exposed developer host or runner If an affected package was installed, treat the workstation or CI runner as fully compromised and rebuild it from a known-good image rather than trying to clean in place.
  • Rotate every credential reachable from the host Rotate cloud tokens, npm tokens, SSH keys, GitHub credentials, database passwords, deployment secrets, browser-saved credentials, and AI-tool tokens that were accessible on the infected system.

What's in the full analysis

Corgea's full analysis covers the operational detail this post intentionally leaves for the source:

  • Package-by-package indicators for the js-logger-pack and terminal-logger-utils clusters, including affected versions and payload behaviour
  • Operating-system-specific persistence artefacts for Windows, macOS, and Linux that help responders verify compromise
  • Command-and-control task details such as file access, upload, session clearing, and binary deployment primitives
  • Detection ideas and remediation sequencing for developer workstations and CI runners that still need to be investigated in depth

👉 Read Corgea's analysis of js-logger-pack and Hugging Face malware delivery →

npm postinstall abuse and Hugging Face C2: what teams missed?

Explore further

View Full Forum →  |  NHI Foundation Course →



   
Quote
(@mr-nhi)
Member Moderator
Joined: 3 months ago
Posts: 18527
 

Supply-chain trust is now an identity problem as much as a software problem. A malicious package install is not just code execution, because the affected host often holds secrets, browser sessions, cloud tokens, and signing material. When install-time code can reach those assets, the compromise boundary shifts from application security into identity and access governance. Practitioners should treat package installation as a privileged event with NHI exposure, not a routine dependency action.

A few things that frame the scale:

  • The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to The State of Secrets in AppSec.
  • Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap.

A question worth separating out:

Q: What should organisations do immediately after a supply chain secret theft event?

A: Contain the execution surface first by revoking exposed tokens, disabling suspicious runners, and isolating affected build systems before the attacker can reuse stolen credentials. Then rotate secrets, validate repository integrity, and review workflow history for unauthorised commits or discussions. Recovery is slower if the execution path remains open.

👉 Read our full editorial: js-logger-pack shows how npm install can become malware delivery



   
ReplyQuote
Share: