SAP npm Packages Backdoored in TeamPCP Supply Chain Attack

TeamPCP has expanded their supply chain campaign to enterprise infrastructure, backdooring four official SAP npm packages used in the Cloud Application Programming Model (CAP) ecosystem. The malicious versions were published on April 29, 2026, and harvested developer credentials, cloud secrets, and CI/CD tokens before detection.

This attack—dubbed "Mini Shai-Hulud" by the threat actors—continues TeamPCP's systematic targeting of developer tools throughout 2026. The same day, the group also compromised PyTorch Lightning on PyPI. Enterprise organizations using SAP CAP should verify their installed package versions and rotate any potentially exposed credentials.

Affected Packages

Wiz Research identified four compromised packages from SAP's official npm namespace:

Package	Malicious Version	Purpose
@cap-js/sqlite	2.2.2	SQLite adapter for CAP
@cap-js/postgres	2.2.2	PostgreSQL adapter for CAP
@cap-js/db-service	2.10.1	Database service layer
mbt	1.2.48	Cloud MTA Build Tool

The suspicious versions were published between 09:55 and 12:14 UTC on April 29. SAP has since removed the malicious releases, but the attack window gave threat actors several hours to collect credentials from organizations installing or updating these dependencies.

Attack Mechanism

The compromised packages contained malicious preinstall scripts in their package.json files—code that executes automatically when npm installs the package, before the main installation completes. Developers wouldn't see any obvious indication of compromise.

The attack chain worked as follows:

1. A loader named setup.mjs downloaded the Bun JavaScript runtime from GitHub
2. Bun executed a heavily obfuscated payload (execution.js)
3. The payload harvested credentials and exfiltrated them to attacker-controlled infrastructure

The malware also included a Python script that read /proc/[pid]/maps and /proc/[pid]/mem from CI runner processes. This technique extracts secrets directly from process memory, bypassing log masking and other runtime protections that organizations rely on to protect credentials.

What Was Stolen

The payload targeted an extensive list of developer and infrastructure credentials:

• npm and GitHub tokens - Package publishing and repository access
• SSH keys - Developer machine and server access
• AWS, Azure, GCP credentials - Cloud infrastructure secrets
• Kubernetes configurations - Cluster access and service accounts
• CI/CD secrets - Environment variables from build pipelines
• Browser credentials - Passwords from Chrome, Safari, Edge, Brave, and Chromium

The browser credential theft is notable—TeamPCP is expanding beyond developer tooling to harvest any authentication material present on compromised machines. This mirrors the credential-harvesting approach we saw in their Bitwarden CLI compromise last week.

Data Exfiltration Method

Stolen data was encrypted using a shared RSA public key and exfiltrated to public GitHub repositories created on the victim's own account. Each repository was created with the description "A Mini Shai-Hulud has Appeared"—a reference to the sandworms from Dune and a signature of this TeamPCP campaign.

This exfiltration method is clever: it uses the victim's own credentials to move data, making detection harder since the activity appears to originate from a legitimate account.

Attribution and Connection to Other Attacks

Researchers linked this attack with medium confidence to TeamPCP based on code similarities and operational patterns matching previous supply chain compromises. The group has been on a tear in 2026, hitting:

• Trivy container scanner - March 19
• LiteLLM AI proxy - March 2026
• Checkmarx KICS - March 23
• Bitwarden CLI - April 25
• SAP CAP packages - April 29 (this incident)
• PyTorch Lightning - April 30

Each attack builds on credentials stolen from previous compromises. Tokens harvested from one organization enable access to repositories at another—a self-sustaining attack cycle that we documented extensively in our Checkmarx KICS analysis.

Initial Access Vector

According to BleepingComputer, a misconfigured CircleCI job may have exposed an npm publishing token, though SAP hasn't confirmed the compromise vector. If true, this highlights how CI/CD misconfigurations can cascade into full supply chain compromises.

Organizations should audit their CI/CD pipelines for exposed secrets—not just in code, but in logs, environment variables, and runner artifacts that may inadvertently leak credentials.

Remediation Steps

Enterprise teams using SAP CAP should take these steps:

1. Audit installed versions - Check your package-lock.json for any of the malicious versions listed above
2. Rotate all credentials - If compromised versions were installed, assume all accessible secrets are exposed
3. Audit CI/CD pipelines - Check for unauthorized runs or modified workflows
4. Review GitHub activity - Look for repositories created with "Mini Shai-Hulud" in the description
5. Check browser passwords - Consider the stored credentials in development browsers compromised
6. Update to safe versions - Once SAP publishes clean releases, update immediately

Why Enterprise Infrastructure Is at Risk

This attack demonstrates that enterprise software ecosystems aren't immune to supply chain compromise. SAP packages are used in corporate environments with access to production databases, ERP systems, and sensitive business data.

The same developers installing @cap-js/postgres for their CAP applications likely have access to enterprise cloud infrastructure, internal APIs, and production secrets. Compromising developer tooling gives attackers a foothold in environments that traditional perimeter security doesn't protect.

For organizations evaluating their supply chain risk, this incident illustrates the need for dependency scanning, version pinning, and network segmentation that limits what development machines can access. The SLSA framework provides a structured approach to supply chain security that can help organizations mature their defenses.