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.

‍

Harden Your Pipeline While You're At It

Once you've identified affected packages, it's worth taking a few minutes to close the door on the next attack.

DepsGuard is a free, open-source CLI tool (also built by Arnica) that enables package manager security controls that ship with npm, pnpm, yarn, and bun, but aren't turned on by default. The most important one is a cooldown period: a setting that prevents your package manager from installing any version published less than seven days ago. Since most malicious packages are caught and removed within hours of publication, a 7-day cooldown stops them before they ever reach your pipeline.

It also enables

ignore-scripts=true

to block malicious install scripts, and adds pnpm-specific controls for provenance and transitive dependency trust.

One command. Supports npm, pnpm, yarn, bun, uv, Renovate, and Dependabot. Automatic backup before any file is touched. MIT-licensed, zero dependencies.

→ Try DepsGuard at depsguard.com

‍