Pgserve package compromise shows why SBOM search speed matters

At a glance

What this is: Arnica describes a pgserve npm supply-chain compromise that turned package installation into credential theft and self-propagation.

Why it matters: It matters because software supply-chain incidents often become identity incidents when publish tokens, build secrets, and developer credentials are exposed inside the same workflow.

By the numbers:

• The compromised pgserve versions injected a 1,143-line credential-harvesting script that executes automatically on every npm install.
• The malicious pgserve releases appeared on April 21, 2026, with three compromised versions published before detection.

👉 Read Arnica's attack analysis for the pgserve npm supply-chain compromise

Context

Package compromise is no longer just a code integrity issue. When a trusted dependency carries an install-time payload, the risk moves into secrets exposure, token abuse, and downstream propagation across the build estate. For identity and security teams, that makes software supply chain events part of the same governance problem as secrets management and privileged access.

In this case, the malicious pgserve releases combined credential harvesting with worm-like reuse of npm publish tokens. That is a classic non-human identity problem because build-time and publish-time credentials behave like machine identities: they are reusable, high-value, and often insufficiently lifecycle-managed. The starting position is increasingly typical, not exceptional, in modern JavaScript ecosystems.

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. That lets attacker-controlled scripts read memory, steal secrets, and potentially publish more malicious artifacts before defenders notice. The control that breaks is the assumption that dependency installation is operationally harmless. Treat install-time execution as a governed security boundary, not a routine developer convenience.

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. Once stolen, they support re-infection and downstream spread rather than just one-off access. That is why publish privileges should be treated like high-risk machine identities with tight scope and rapid revocation.

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. If any one of those steps is inconsistent, the process is only partially controlled.

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.

Technical breakdown

How install-time payloads turn dependencies into secret harvesters

A malicious npm package can execute code during installation through lifecycle scripts, which means compromise begins before the application ever runs. In pgserve, the payload executed automatically on install and searched the local environment for credentials. That matters because developers commonly store npm tokens, cloud keys, and CI secrets on the same machines used for package installation. Once an attacker reaches that context, the package is no longer just code. It becomes a delivery vehicle for credential theft and a stepping stone to broader estate compromise.

Practical implication: block install scripts where possible and treat developer workstations and build runners as credential-bearing systems.

Why publish tokens create worm-like propagation in package ecosystems

The worm behaviour comes from privilege reuse. If malicious code finds an npm publish token, it can publish new poisoned versions to any package that token is allowed to update, extending the compromise into new projects and consumers. This is not a traditional self-replicating malware model on endpoints. It is a supply-chain propagation model built on overprivileged non-human identities, where one credential can authorize multiple downstream releases and silently widen blast radius.

Practical implication: scope publish tokens narrowly and rotate them immediately after any suspected package compromise or developer workstation exposure.

Why SBOM search and continuous SCA scanning matter after disclosure

An SBOM helps only if teams can query it quickly against an emerging package name, version, or compromise window. Continuous software composition analysis adds a time dimension by checking repositories beyond pull request events, which is essential when malicious versions are live only briefly. Without that coverage, organisations discover exposure long after the package has propagated through builds, caches, and artifact stores. The control gap is not visibility alone. It is visibility that is too slow to drive containment.

Practical implication: wire SBOM search to continuous SCA scanning so exposure can be found across the whole estate, not just at commit time.

Threat narrative

Attacker objective: The attacker wants credential access that can be reused to publish more malicious packages and expand compromise across the software supply chain.

1. Entry occurs when developers or build systems install a malicious npm package that executes an install-time credential-harvesting script.
2. Escalation follows when the malware finds an npm publish token or other secrets on the victim machine and uses them to extend its reach into package publishing.
3. Impact occurs when stolen credentials are exfiltrated and the poisoned package is propagated into additional repositories and downstream consumers.

Breaches seen in the wild

• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.
• GitHub Dependabot Breach — GitHub Dependabot tokens stolen and abused to push malicious commits to repositories.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

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.

Secret-carrying build environments create a non-human identity lifecycle problem. npm publish tokens, CI variables, and local development credentials are all non-human identities with long-lived trust assumptions. The pgserve pattern shows that a single credential can be both harvested and repurposed for further compromise if lifecycle controls are weak. That is exactly the kind of overprivilege and persistence issue OWASP NHI guidance is meant to expose. Teams should audit these credentials as governed identities, not incidental configuration.

SBOMs are only operationally useful when the response window is shorter than the attacker’s dwell time. If malicious packages can be identified and removed quickly, continuous scanning changes the outcome. If discovery takes days, the SBOM becomes a historical record instead of a control. The named concept here is exposure-to-response latency, and it is now a measurable governance metric for software supply-chain resilience. Practitioners should optimise for rapid estate-wide search, not periodic inventory review.

Worm-like package propagation shows why publish privileges must be treated as high-risk access. A publish token that can update multiple packages creates a lateral movement path through trusted infrastructure. That is the same control problem seen in privileged access abuse, only expressed through package registries and developer tooling. The security conclusion is straightforward: publish rights need lifecycle boundaries, narrow scope, and immediate revocation pathways when compromise is suspected. Teams should review registry privileges as part of PAM and secrets governance.

From our research:

• 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.
• For a wider breach lens, The 52 NHI breaches Report shows how exposed credentials and overprivileged access repeatedly turn a local compromise into broader identity abuse.

What this signals

Exposure-to-response latency is now a meaningful control metric for software supply-chain defence. If malicious packages can be detected within hours but remediation takes days, the estate remains exposed long after the package disappears from the registry. Continuous scanning, registry intelligence, and fast identity revocation need to operate as one workflow, not separate programmes.

The identity lesson is that registry tokens, CI secrets, and developer credentials behave like non-human identities with a lifecycle problem. They need ownership, scoped privileges, and clear revocation triggers because they can be harvested and reused faster than traditional review cycles assume.

Teams should align package-control decisions with the OWASP Non-Human Identity Top 10 and the MITRE ATT&CK Enterprise Matrix, because dependency compromise is only the first step in a broader credential-access chain.

For practitioners

• 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.
• Treat publish tokens as privileged non-human identities Inventory npm publish tokens, constrain them to the smallest viable package scope, and rotate them immediately after any workstation or build-agent exposure.
• Add continuous SCA beyond pull requests Run software composition analysis across all repositories and historical artifacts, not just on pull requests, so you can find short-lived malicious versions after disclosure and before they spread.

Key takeaways

• pgserve shows how a compromised dependency can become a credential-harvesting platform before the application ever runs.
• The real control gap is not just package integrity, but how quickly teams can find and revoke affected credentials across the estate.
• Cooldown periods, script blocking, and scoped publish tokens materially reduce the blast radius of npm supply-chain attacks.

Key terms

• Install-Time Payload: An install-time payload is malicious behaviour that runs when software is installed rather than when it is later executed. This matters because package lifecycle hooks can read environment secrets, fetch remote content, or implant code before standard review tools have a chance to inspect the final state.
• Publish token: A credential that authorises a package maintainer or automation process to publish or overwrite software artefacts. In identity terms, it is a high-value non-human credential with direct supply chain impact, so it needs rotation, scope limitation, and strict lifecycle ownership.
• SBOM: A software bill of materials is an inventory of components, dependencies, and often transitive packages used in an application or build. It gives defenders visibility into what entered the software supply chain and helps spot risky or newly introduced dependencies.
• Exposure-To-Response Latency: The time between a compromise becoming known and the organisation fully identifying and containing affected assets. In dependency incidents, this latency determines whether the event is a manageable disclosure or a widespread supply-chain propagation problem.

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

👉 Arnica's full post covers the compromised versions, SBOM search workflow, and pipeline hardening controls

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, secrets management, and workload identity for practitioners who need to control credential lifecycle risk. It is designed for teams responsible for identity, DevSecOps, and privileged access decisions across modern estates.