How to Check for Impacted pgserve Packages in Your SBOM

On April 21, 2026, malicious versions of the npm package pgserve (versions 1.1.11, 1.1.12, and 1.1.13) were published to the npm registry. The compromised versions inject a 1,143-line credential-harvesting script that executes automatically on every npm install.

pgserve

is a popular embedded PostgreSQL server for development: zero config, auto-provisioned databases, designed to be dropped into any Node.js project. The three compromised versions contain a sophisticated supply-chain worm: if the malware finds an npm publish token on the victim machine, it re-injects itself into every package that token can publish, propagating the compromise further. Stolen credentials are encrypted with RSA-4096 + AES-256 and exfiltrated to a decentralized Internet Computer Protocol (ICP) canister, a blockchain-hosted endpoint deliberately chosen because it cannot be taken down by law enforcement or domain seizure.

None of the three compromised versions have a corresponding git tag in the upstream repository. Full technical details are available in the StepSecurity disclosure. The last legitimate release was tagged on April 17, 2026 and is:

v1.1.10

Attack Timeline

• April 17, 2026 21:57 UTC -- pgserve@1.1.10 published with git tag v1.1.10 (last legitimate release)
• April 21, 2026 22:14 UTC -- pgserve@1.1.11 published to npm, no git tag
• April 21, 2026 22:26 UTC -- pgserve@1.1.12 published to npm, no git tag (identical payload to 1.1.11)
• April 21, 2026 -- pgserve@1.1.13 published to npm, no git tag
• April 22, 2026 -- StepSecurity AI Package Analyst flags all three versions as Critical / Rejected; IOC domains added to block lists; maintainer disclosed via GitHub issue #25

How to Check with Arnica

Arnica customers can search their SBOM for the impacted packages directly from the platform by filtering for "pgserve (Apr 2026)" in the advanced search view. This surfaces any repository in your estate that has ever resolved one of the three compromised versions.

Continuous SCA scanning across all repositories, not just on pull requests, is what gives teams the speed to respond to incidents like this in minutes rather than days.

‍

‍