Between April 29 and early May 2026, attackers compromised four npm packages spanning the SAP CAP framework ecosystem, the Lightning Python library, and an Intercom integration package. Researchers tracking the campaign named it Mini Shai-Hulud. Over 1,800 developers pulled the poisoned versions. Combined weekly download count across the affected packages exceeded 570,000. The malicious payloads targeted CI/CD secrets, npm authentication tokens, and environment variables at build time.
The entry point was not a zero-day. Attackers sourced compromised maintainer credentials from earlier breach dumps and used them to authenticate to npm's registry and publish malicious versions. The packages themselves looked normal: same README, same API surface, no obvious signs of tampering in a quick review. The malicious code was buried in postinstall scripts.
The SAP CAP Angle
Two of the four compromised packages belong to the SAP Cloud Application Programming (CAP) model framework: @cap-js/sqlite and @cap-js/db-service. SAP CAP is the standard development framework for building enterprise services on SAP Business Technology Platform. It is used in production environments across manufacturing, logistics, finance, and critical infrastructure verticals.
This is not a consumer npm package. Developers using these packages are building internal enterprise tooling against SAP systems that often connect to ERP databases, supply chain platforms, and operational backends. When the poisoned package runs at install time and exfiltrates environment variables, it is reaching into build environments that may hold credentials for those downstream systems.
A poisoned package in an enterprise dev toolchain does not affect one developer. It affects every environment that pulls the package: developer laptops, CI/CD runners, staging servers, and production build pipelines. One compromised version, dozens of credential surfaces.
What the Malicious Versions Exfiltrated
Postinstall scripts in the compromised versions executed at npm install time, before any developer code ran. The scripts collected and transmitted the following:
- npm authentication tokens from
~/.npmrc - CI/CD environment variables (GitHub Actions, Jenkins, GitLab CI secrets)
- Cloud provider credentials from environment:
AWS_ACCESS_KEY_ID,AWS_SECRET_ACCESS_KEY,AZURE_CLIENT_SECRET,GCP_SERVICE_ACCOUNT_KEY - General environment variable dumps from the build context
The exfiltration target was an attacker-controlled endpoint. The data was encoded and transmitted over HTTPS, making it difficult to distinguish from normal package manager telemetry traffic in network logs.
Detection and Response
The poisoned versions were pulled from npm's registry after researchers flagged the anomalous postinstall behavior. npm security reviewed and removed the malicious versions within hours of the initial report. However, any environment that ran npm install during the attack window should be treated as compromised until credentials are rotated.
Detection signatures to look for in retrospect: outbound HTTPS connections from CI/CD runners to non-package-registry endpoints during the npm install phase; unexpected reads of ~/.npmrc or cloud credential files by node processes; environment variable access patterns that do not match normal build behavior.
Check your build logs for the April 29 to May 2 window. If any affected package version was installed: rotate npm tokens, rotate cloud provider credentials used in that CI/CD environment, and audit for any subsequent unauthorized npm publishes under your organization's scope.
The broader pattern here is credential reuse across registries. npm maintainer accounts are not consistently protected with hardware MFA. Breach dumps contain valid npm credentials that remain active for months or years. The fix requires npm to enforce stronger authentication requirements for package publishing, which remains an open gap in the ecosystem.