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.
Editorial analysis by NHI Mgmt Group, based on content published by Arnica: “How to Check for Impacted pgserve Packages in Your SBOM”.
By the numbers:
- Malicious versions 1.1.11, 1.1.12 and 1.1.13 of pgserve were published to the npm registry on April 21, 2026.
- The last legitimate pgserve release was v1.1.10, tagged on April 17, 2026.
Key questions
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 do security teams know if a package compromise is actually contained?
A: They should confirm three things: the bad version no longer appears in lockfiles, SBOM records no longer resolve to it, and running services no longer load it.
Practitioner guidance
- Search the SBOM for impacted versions Filter dependency inventories for pgserve versions 1.1.11, 1.1.12 and 1.1.13, then trace every repository and build path that ever resolved them.
- Quarantine publish tokens used by affected workflows Assume any npm publish token present on an infected host or runner may have been harvested and remove its ability to publish until reissued.
- Disable install-time scripts where possible Turn on ignore-scripts and apply package-manager controls that stop fresh packages from executing arbitrary install hooks during dependency resolution.
Bottom line: A malicious dependency can turn install-time convenience into secret theft, and that risk grows when package-manager defaults allow arbitrary scripts to run.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
19/08/2026 4:23 pm
Supply-chain search latency is now a governance control: this incident shows that inventory accuracy matters less than resolution speed once a malicious package is public. The estate must be searchable by package version, publish window, and dependency path, because a slow answer leaves the worm enough time to spread. Practitioners should treat SBOM query performance as a containment capability, not a reporting feature.
A few things that frame the scale:
- 59% of compromised machines in a major 2025 supply chain attack were CI/CD runners rather than personal workstations, according to the State of Secrets Sprawl 2026.
- The blast radius of the Salesloft-Drift OAuth supply chain attack was 10 times greater than earlier incidents in which attackers breached Salesforce directly.
A question worth separating out:
Q: Should organisations prioritise provenance or dependency scanning first?
A: Provenance should come first when the environment is AI-assisted, because scanning can only inspect what is already present. Provenance answers the harder question of whether an artefact, dependency, or build step was introduced through authorised paths. Scanning remains necessary, but it cannot compensate for unknown origin.
👉 Read our full editorial: Pgserve package compromise shows why SBOM search speed matters