Notifications
Clear all
Topic starter
19/08/2026 3:46 pm
TL;DR: A malicious pgserve npm release injected a 1,143-line credential-harvesting script, propagated by reusing found npm publish tokens, and pushed stolen data to an Internet Computer Protocol canister, according to Arnica. The incident shows that SBOM visibility and continuous SCA scanning only help when teams can find and contain impacted packages fast.
NHIMG editorial — based on content published by Arnica: How to Check for Impacted pgserve Packages in Your SBOM
By the numbers:
- The malicious pgserve releases appeared on April 21, 2026, with three compromised versions published before detection.
Questions worth separating out
Q: What breaks when malicious npm packages execute during CI/CD installs?
A: The main failure is that package installation becomes code execution inside a trusted build context.
Q: Why do publish tokens make supply-chain compromises much harder to contain?
A: Publish tokens can extend a single compromise into many repositories because they authorize package updates across trusted registry workflows.
Q: How can organisations tell whether their SBOM process is actually working?
A: A working SBOM process can generate an SBOM for every release, sign it automatically, let consumers verify it independently, and retrieve the record quickly during an audit or incident.
Practitioner guidance
- Search the SBOM against compromised package versions Query the full dependency estate for pgserve 1.1.11, 1.1.12, and 1.1.13, including transitive and historical resolutions, so you can identify repositories that ever pulled the malicious releases.
- Block newly published packages during the cooldown window Enable a package-manager cooldown period of at least seven days so malicious releases are blocked before they can enter build pipelines, especially for packages with fast-moving release cycles.
- Disable install scripts where business risk allows Turn on ignore-scripts=true or equivalent controls in npm, pnpm, yarn, or bun to prevent package install hooks from executing arbitrary code on developer and CI machines.
What's in the full article
Arnica's full attack post covers the operational detail this post intentionally leaves for the source:
- Version-by-version compromise timeline for pgserve 1.1.11 through 1.1.13 and the detection milestones that followed
- Step-by-step guidance for finding impacted packages in Arnica's advanced SBOM search view
- Specific DepsGuard controls for npm, pnpm, yarn, bun, uv, Renovate, and Dependabot deployments
- Implementation detail on cooldown periods, provenance checks, and transitive dependency trust controls
👉 Read Arnica's attack analysis for the pgserve npm supply-chain compromise →
Pgserve supply-chain worm: what should SBOM and SCA teams do now?
Explore further
19/08/2026 4:23 pm
Package compromise becomes identity compromise the moment install-time code can reach secrets. Dependency integrity matters, but the more important governance issue is whether build and developer environments contain reusable credentials in the first place. When install scripts can see tokens, keys, and publish credentials, the package ecosystem becomes an identity attack surface. Practitioners should treat dependency execution as credential exposure, not just code execution.
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.
- 43% of security professionals are concerned about AI systems learning and reproducing sensitive information patterns from codebases, according to The State of Secrets in AppSec.
A question worth separating out:
Q: What should teams do after a malicious package is discovered in the registry?
A: Contain the exposure by identifying every repository, build cache, and environment that resolved the affected versions, then rotate any credentials that may have been present on those systems. After that, tighten package-install controls and publish-token scope so the same compromise pattern cannot repeat.
👉 Read our full editorial: Pgserve package compromise shows why SBOM search speed matters
