Emerging Supply Chain Attack (“Mini Shai-Hulud”) Targeting SAP Cloud Application Programming Ecosystem

Onapsis is closely monitoring a sophisticated supply chain attack targeting SAP developers and organizations using the SAP Cloud Application Programming (CAP) model.

Identified as a variant of the “Shai-Hulud” worm, this attack involves the injection of malicious code into widely used SAP npm packages. The primary goal of this malware is the automated theft of cloud credentials, service tokens, and private keys.

The malicious package was available for a two to four hour window on April 29, 2026. If one of your developers downloaded the specific package(s) during the time window in which the malicious versions were available, then you may be affected. Clean versions of the packages were released to supersede the infected versions. Further details below.

Why This Matters Specifically for SAP Customers

CAP is the de facto framework for almost anything custom on SAP BTP as well as other non-BTP JavaScript development. For example  side-by-side extensions to S/4HANA, Fiori app backends, integration flows, and MTAs. Any SAP customer with JavaScript development may be pulling @sap/* and @cap-js/* packages into their build pipelines, frequently with loose version ranges and lots of transitive dependencies. 

While this supply-chain compromise could affect developers in general, this should be especially important to SAP customers, specifically those that use BTP and develop NodeJS applications on BTP, SAP customers developing custom XSA applications, SAP UI5 Applications or Fiori Applications.  

What We Know So Far

• Targeted Packages: Several official SAP npm packages have been identified as compromised. These packages were only published for a limited period of time, mitigating the scope of the risk. As reported by socket.dev:

• The Attack Vector: The malware triggers automatically during npm install via a preinstall hook. It utilizes a standalone “Bun” runtime to bypass standard Node.js security monitoring.
• Impact: The payload scans the victim’s environment for secrets (e.g., AWS, Azure, GCP, GitHub, and Kubernetes tokens). These secrets are then exfiltrated by creating public GitHub repositories under the victim’s own account, making sensitive corporate data searchable on the open web.
• Propagation: The malware is “worm-like,” attempting to use stolen tokens to infect other repositories the user has access to.

Business Impact and Primary Response

Npms are most often used by developers, so this primarily affects developer workstations and, thus, there is potential follow-on impact to systems, repositories, applications, and cloud infrastructure that the affected developer may have access to. Secondarily, but equally serious, there are potentially affected components of the CI/CD pipeline including artifactory and build tooling. Sequence of events:

• Npm install of an affected package, directly or indirectly as a dependency
• Execution of malicious code
• Extraction / exfiltration of secrets and credentials
• Leverage of secrets/credentials
  • Spread
    • Repopulation
    • Republication
  • Code tagging/defacement

All known methods for detection are discussed in detail below, but the primary vector and fingerprint would be via endpoint methods on developer workstations, and by examination of code repositories.

Onapsis Response & Collaboration 

This is a rapidly evolving situation. We are currently conducting a deep-dive technical evaluation of the payload and its exfiltration channels.

Immediate Guidance 

While our full assessment is underway, we recommend the following immediate precautions:

• Audit Dependencies: Check your package-lock.json files for any recent updates to the malicious versions of @cap-js scoped packages during the time window in which the malicious versions were available.
• Restrict GitHub Tokens: Ensure that developer Personal Access Tokens (PATs) are scoped with the “minimum privilege” necessary and avoid global write permissions.
• Monitor Public Repositories: Use automated tools or manual checks to ensure no unauthorized public repositories have been created under your organization’s or employees’ GitHub profiles.

More Detailed Technical Guidance

The following guidance is based on current published forensic analysis.

Immediate Dependency Audit

To directly check for exposure, scan project manifests for known-malicious package versions.

• Scan Lock Files: Search package-lock.json, yarn.lock, or pnpm-lock.yaml for these specific versions:
  • @cap-js/sqlite: v2.2.2
  • @cap-js/postgres: v2.2.2
  • @cap-js/db-service: v2.10.0
  • mbt (Cloud MTA Build Tool): v1.2.48
    
• Check Deep Dependencies: Use the command npm ls @cap-js/sqlite (or equivalent) to see if these versions are being pulled in as a sub-dependency of another tool.

Filesystem & Environment Inspection

If a malicious version was installed, the malware likely left artifacts on the developer’s machine or CI/CD runner.

• Search for Payload Files: Look in node_modules of SAP projects or in the system’s temporary directories for:
  • Setup.mjs
    • SHA-256: 4066781fa830224c8bbcc3aa005a396657f9c8f9016f9a64ad44a9d7f5f45e34
  • execution.js (Typically a large, ~11MB obfuscated file)
    • SHA-256:  ([email protected]) 80a3d2877813968ef847ae73b5eeeb70b9435254e74d7f07d8cf4057f0a710ac
  • bun or bun.exe (The malware often downloads its own Bun runtime to /tmp/ or the project root).
    • Bun download URL: https://github.com/oven-sh/bun/releases/download/bun-v1.3.13/{asset}.zip
      
• Check for Secret Dumps: The malware generates local files before exfiltration. Search for:
  • Cloud.json
  • Environment.json
  • truffleSecrets.json
    
• Identify Background Processes: Check for long-running processes (using the Bun runtime) that weren’t started by the user. On Linux/macOS: ps aux | grep bun.

GitHub & SaaS Activity Review

Since the malware uses the victim’s own tokens to exfiltrate data, the evidence is often visible in the user’s own GitHub account.

• Unauthorized Public Repositories: Search for any new public repositories created in the last 7 days with the following descriptions:
  • “A Mini Shai-Hulud has Appeared”
  • “Shai-Hulud Repository”
  • “Shai-Hulud Migration”
    
• Unexpected Branches: Look for new branches named shai-hulud in private or public repositories.
  
• Audit GitHub Actions:
  • Check for a new workflow file at .github/workflows/discussion.yaml or shai-hulud-workflow.yml.
  • Check for a self-hosted runner registered with the name “SHA1HULUD”.
    
• Commit History: Look for commits with the signature message: OhNoWhatsGoingOnWithGitHub:[Base64_String].

Network & Cloud Logs

• Egress Traffic: Look for unusual outbound connections to:
  • github.com/oven-sh/bun/releases (to download the runtime).
  • webhook.site (used by some variants for secondary exfiltration).
    
• Cloud Credential Usage: Check AWS CloudTrail, Azure Activity Logs, or GCP Audit Logs for unusual activity (e.g., DescribeInstances or GetSecretValue calls) originating from developer IP addresses or CI/CD runners that occurred shortly after an npm install.

Manual Remediation

If any of the above indicators are found, take these steps immediately:

1. Isolate the Machine: Disconnect the affected developer machine or CI/CD runner from the network.
   
2. Clean Caches: Run npm cache clean –force and delete the global node_modules and package-lock.json files.
   
3. Rotate ALL Secrets:This is CRITICAL. If the malware ran, assume the following are compromised:
   • SSH Keys stored in ~/.ssh/.
   • GitHub tokens, including output from gh auth token
   • NPM tokens from .npmrc
   • GitHub Actions secrets
   • GitHub Personal Access Tokens (PATs)
   • AWS STS identity, Secrets Manager secrets, and SSM parameters
   • Azure subscriptions, Key Vault names, and Key Vault secret values
   • GCP project identity and Secret Manager values
   • Kubernetes service account tokens
   • Environment variables
   • Claude config, MCP config, GCP token databases, Azure token caches, Signal config, Electrum wallets, and VPN config files
     
4. Delete Malicious Repos: Manually delete any GitHub repositories or branches created by the malware to prevent further exposure of the stolen secrets.

The “Mini” variant is particularly dangerous because it executes during the preinstall phase. This means even if the installation fails or is cancelled, the credentials may have already been exfiltrated.

Onapsis Product Coverage

In consideration of the primary detection vector, Onapsis products are not the best positioned to directly detect or respond to this. The primary detection vector is at the developer workstation or on the CI/CD runner system. Onapsis response, internal and external, has been to primarily leverage standard InfoSec and EDR tooling as well as repo-level inventory.

Next Steps 

Onapsis is committed to providing you with the most accurate information as it becomes available. We will continue to update this article as more information becomes known with further Indicators of Compromise (IoCs) and/or additional remediation steps.

If you have immediate concerns regarding your current SAP landscape, please contact your Onapsis customer success manager.

Key Articles for Additional Reference:

• Socket.dev: SAP CAP npm Packages Targeted in Shai-Hulud Supply Chain Attack
• Aikido Security: Mini Shai-Hulud Targets SAP npm Packages With a Bun-Based Secret Stealer
• Wiz Research: Shai-Hulud 2.0: Ongoing Supply Chain Attack Analysis
• Step Security:  https://www.stepsecurity.io/blog/a-mini-shai-hulud-has-appeared