Notifications
Clear all
Topic starter
20/08/2026 5:29 pm
TL;DR: Twenty-two npm packages under a single publisher used fabricated Web3 security brands, MCP-style tool names, and two payload families to harvest secrets or drop binaries, with 14 packages still live at analysis time, according to Xygeni. The campaign shows how package trust, AI-agent tool invocation, and dynamic C2 indirection can combine into a supply-chain trap that conventional install-time scanning misses.
NHIMG editorial — based on content published by Xygeni: the npm campaign using fake Web3 security brands and MCP-based payloads
Questions worth separating out
Q: How should security teams handle packages that resolve control endpoints at runtime?
A: Treat them as higher risk than ordinary dependencies, because mutable endpoints allow the operator to change exfiltration targets without changing the package hash.
Q: Why do AI agent tool calls increase supply-chain risk for secrets exposure?
A: Because the tool invocation can be the trigger that activates hidden logic after installation, at the exact moment the agent is interacting with a trusted workflow.
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
- Block mutable runtime endpoints in package workflows Prevent build and agent workflows from resolving executable content or collector targets from GitHub Pages, Gist, paste sites, or similar mutable sources unless explicitly approved and logged.
- Review MCP tool permissions as privileged access Require explicit approval before an AI agent can invoke package tools that scan repositories, secrets, or deployment contexts, especially when the tool name implies auditing or validation.
- Sweep developer environments for exposed credentials Check ~/.ssh, ~/.env, ~/.git-credentials, shell history, wallet files, and process environments for exposed material, then rotate any secret that could have been read by a malicious package.
What's in the full report
Xygeni's full article covers the operational detail this post intentionally leaves for the source:
- The full package catalogue with version-by-version grouping across all 22 malicious entries.
- Indicators of compromise, including the dynamic webhook resolver, the Pinggy tunnel, and the dropped binary path.
- The exact MCP tool names and scanner logic used in Variant A, including the file and regex targets.
- The publisher fingerprinting evidence, including the account pattern and brand-front structure.
👉 Read Xygeni's analysis of the 22-package npm campaign targeting Web3 secrets →
Fake Web3 security packages: what appsec teams need to watch?
Explore further
20/08/2026 6:17 pm
Brand prefabrication is now a trust attack, not just a packaging trick. The campaign did not merely use a plausible package name. It manufactured fake organisations, matching GitHub shells, and security-flavoured vocabulary to create social proof around malicious code. That matters because reviewers, developers, and AI agents often infer legitimacy from packaging signals before they inspect behaviour. Practitioners should assume that branding can be weaponised as part of the supply-chain attack surface.
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 teams do immediately if a malicious dependency may have accessed local secrets?
A: Assume any readable secret is compromised, rotate credentials that were present in dotfiles or environment variables, revoke tokens with broad scope, and isolate the affected workstation or build runner. Then review downstream systems for signs of token use, because the main risk is not just theft but follow-on access using still-valid identity material.
👉 Read our full editorial: npm package campaign uses fake Web3 security brands to steal secrets
