Supply Chain Compromise: Malicious CAP.js Package Versions with Credential Harvesting

Vulnerability Description

This incident represents a supply chain compromise leveraging NPM package distribution. The malicious packages likely executed credential harvesting during installation (via post-install scripts or dependency resolution hooks), capturing sensitive authentication material stored on the host system. The attempted self-propagation mechanism suggests the attacker aimed to expand the compromise through transitive dependencies or compromised developer environments. The attack surface is exceptionally broad—any organization using CAP.js database modules became potential victims regardless of their direct security posture.

PoC Significance & Preconditions

The PoC significance lies not in exploit mechanics but in supply chain trust betrayal. The malicious packages were published to the official NPM registry during a window where the publisher account or registry security was compromised. The precondition is simply: running npm install (or yarn install/pnpm install) between April 29, 2026 and the patch release. This is a "drive-by compromise"—no user interaction beyond normal dependency installation was required. The threat model proves that package managers remain a critical attack vector for reaching thousands of organizations simultaneously.

Detection Guidance

Inventory and Retrospective Detection:

• Query package-lock.json, yarn.lock, pnpm-lock.yaml files for presence of affected versions across all repositories and CI/CD environments
• Check NPM audit logs: npm audit will flag these versions if still installed
• Scan container image registries for builds containing @cap-js/sqlite@2.2.2, @cap-js/postgres@2.2.2, or @cap-js/db-service@2.10.1
• Review Git history for any commits between April 29 and patch release mentioning CAP.js versions

Runtime Indicators:

• Monitor for unusual outbound connections from Node.js processes during package installation phases
• Log post-install script execution; flag unexpected network I/O or file access to credential stores (~/.ssh, ~/.npm, ~/.aws, cloud provider config directories)
• YARA: Flag processes executing node with child processes accessing /home/*/.ssh/id_*, /root/.kube/config, or environment variable exfiltration patterns

Mitigation Steps

Immediate Actions:

1. Upgrade immediately to patched versions: @cap-js/sqlite >= 2.4.0, @cap-js/postgres >= 2.3.0, @cap-js/db-service >= 2.11.0
2. Credential rotation (mandatory): Assume all credentials accessible during installation are compromised—rotate SSH keys, GitHub PATs, npm tokens, AWS/GCP/Azure service accounts, and any secrets stored in environment or credential files
3. Scope determination: Identify all machines where compromised versions were installed (developer laptops, CI/CD runners, production environments, containers)
4. Audit access logs: Review cloud provider, Git hosting, and internal system logs for suspicious activity from compromised credentials since April 29
5. No workarounds exist—patching is the only remediation

Risk Assessment

Likelihood & Threat Actor Interest: This incident demonstrates critical real-world risk. Supply chain attacks have become a preferred vector for sophisticated threat actors (state-sponsored and criminal groups alike) because they achieve massive reach with minimal per-target effort. The April 29 publication window suggests either: (a) a compromised maintainer account, (b) compromised NPM registry infrastructure, or (c) insider threat. Given the self-propagation attempt, the attacker demonstrated intent to maximize downstream impact. Organizations should assume this compromise was actively exploited in the wild and threat actor(s) are selling or using harvested credentials for lateral movement, data exfiltration, and persistent access establishment. The blast radius includes any organization's supply chain that consumed these packages—not just direct users but their customers and downstream dependencies.