Primary SAP reference: SAP Security Note 3747787 – Malicious open-source packages in SAP Cloud Application Programming Model & MTA Build Tool
Classification: Customer advisory – technical and operational guidance
For SAP security, BTP, DevSecOps, Basis, and incident response teams
Summary
On April 29, 2026, malicious versions of four npm packages used in the SAP development ecosystem were published to the public npm registry. SAP has addressed the incident in Security Note 3747787, which identifies malicious open-source package versions affecting SAP Cloud Application Programming Model (CAP) and the MTA Build Tool. This is not a conventional SAP application vulnerability. It is a software supply chain compromise that executes during dependency installation and targets developer workstations, CI/CD runners, build containers, and repositories.
The affected packages are used in normal SAP extension and deployment workflows. CAP is common in SAP BTP development, side-by-side extensions, Fiori application backends, and integration services. The MTA Build Tool is used to create deployable MTAR archives for SAP BTP and related Cloud Foundry or XSA-style deployment processes. In practical terms, the incident matters because the malware runs where development and deployment credentials often exist.
Operational priority
Any developer machine, CI/CD runner, build container, or artifact cache that installed the affected versions should be handled as a potential credential compromise. Downgrading the dependency is not enough. The response must include exposure hunting, isolation where needed, credential rotation, repository review, and CI/CD hardening.
Affected Packages
SAP Note 3747787 lists the following compromised package versions:
- @cap-js/sqlite v2.2.2
- @cap-js/postgres v2.2.2
- @cap-js/db-service v2.10.1
- mbt v1.2.48
These versions may have entered environments directly through package manifests or indirectly through lockfile updates, internal package mirrors, build caches, Docker layers, artifact repositories, or automated pipeline runs during the exposure window. Customers should not limit checks to source repositories. Package caches and CI worker images are equally important.
What Happened
The attacker published malicious versions of trusted SAP ecosystem npm packages. The legitimate package functionality remained largely intact, which reduced the chance of immediate failure or user suspicion. The malicious behavior was introduced through installation-time code, specifically a modified package.json that invoked a new setup.mjs loader during npm install.
This execution model is important: npm lifecycle scripts run before the application itself is used. A developer does not need to execute the application. A CI/CD job does not need to deploy anything. Simply installing the dependency can be enough to execute the payload.
How the Attack Worked
Based on SAP Note 3747787 and public technical reporting, the attack chain can be summarized as follows:
- A malicious package version is resolved by npm, either directly or through an allowed dependency update.
- The package installation triggers a preinstall script in package.json.
- The preinstall script runs setup.mjs, which bootstraps the next stage.
- The loader downloads the Bun JavaScript runtime and uses it to execute a large obfuscated payload named execution.js.
- The payload searches the local host or CI/CD runner for credentials, tokens, secrets, and configuration files.
- The stolen data is encrypted and exfiltrated through GitHub infrastructure, including repositories created under the victim account with a distinctive description.
- Where possible, the malware attempts to propagate by using stolen GitHub or npm tokens to modify repositories, inject workflow or IDE configuration, and publish further malicious package versions.
The use of Bun is notable. Most Node.js dependency controls, npm audit workflows, and EDR detections are tuned around node and npm process behavior. Using a separate runtime during installation changes the execution profile and can reduce the effectiveness of monitoring that only expects Node.js processes.
What the Malware Tried to Steal?
The payload was built for developer and build environments. Public analysis and SAP guidance indicate that the malware targeted secrets such as:
- GitHub tokens, GitHub Actions secrets, and repository credentials
- npm tokens and .npmrc configuration
- AWS, Azure, and GCP credentials or tokens
- Kubernetes configuration and service account tokens
- SSH keys and local Git credentials
- CI/CD environment variables and build-time secrets
- IDE or AI coding tool configuration files used for persistence or re-execution
For SAP customers, the concern is not limited to source code exposure. SAP BTP subaccount credentials, Cloud Foundry deployment credentials, service keys, Destination service credentials, XSUAA bindings, HANA service keys, artifact repository credentials, and transport or release automation tokens may all be within blast radius if they were present on an affected machine or runner.
Why This Matters for SAP Customers?
This incident expands the SAP attack surface beyond ABAP, SAP Gateway, RFC, NetWeaver Java, SAProuter, and kernel patching. The compromised packages sit in the JavaScript and cloud development layer that many organizations now use to extend SAP landscapes.
The practical risk is that attackers do not need to exploit a production SAP application server first. They can target the development path that leads to production. In many enterprises, build pipelines have privileged access to deploy applications, bind services, read secrets, create releases, or update packages. If those credentials are stolen, the attacker may gain a path to business-critical systems without triggering classic SAP intrusion indicators.
Organizations most exposed are those that:
- Develop SAP CAP applications or Node.js services for SAP BTP.
- Use MBT or MTA-based deployment workflows.
- Run automated CI/CD pipelines with access to SAP BTP, Cloud Foundry, GitHub, npm, or artifact registries.
- Use loose dependency ranges such as caret or tilde versioning in development or build dependencies.
- Cache npm packages internally without rapid malicious package revocation workflows.
- Permit long-lived developer or automation tokens with broad repository or deployment scope.
Indicators Customers Should Check
SAP Note 3747787 provides the authoritative indicators, including hashes. At a minimum, customers should search for:
- The affected package versions listed above in package-lock.json, yarn.lock, pnpm-lock.yaml, npm caches, artifact registries, and container images.
- Unexpected setup.mjs or execution.js files under affected package directories.
- GitHub repositories whose description contains “A Mini Shai-Hulud has Appeared”.
- Commits containing the marker “OhNoWhatsGoingOnWithGitHub”.
- Commits with the message “chore: update dependencies” where the change is not expected or cannot be tied to normal automation.
- Commits authored by claude <claude@users.noreply.github.com>, where this is not part of approved developer tooling.
- Unexpected .vscode/tasks.json entries that execute setup scripts when a folder opens.
- Unexpected .claude/settings.json, .claude/setup.mjs, or .claude/execution.js files.
- New or modified GitHub Actions workflows, branches, package publishing jobs, or npm version bumps that were not approved.
Version checks are necessary but not sufficient. Internal mirrors or cache layers may contain the malicious package even after the public npm version has been superseded. Customers should use SAP-provided hashes for forensic confirmation where available.
Recommended Customer Response
Treat this as a potential credential theft incident. The response should be coordinated between SAP security, BTP development, DevSecOps, endpoint security, cloud security, and repository administrators.
1. Confirm whether the affected versions were installed
- Search all source repositories and lockfiles for the four package versions.
- Search CI/CD logs around April 29-30, 2026, for npm install, npm ci, yarn install, or pnpm install jobs that resolved the affected versions.
- Search internal npm mirrors, artifact repositories, container registries, and build cache layers.
- Identify the exact machines, runners, projects, repositories, and accounts that touched the packages.
2. Contain affected systems
- Quarantine affected developer machines and CI/CD runners before normal reuse.
- Preserve forensic evidence in accordance with your incident response process.
- Re-image affected systems where compromise is confirmed or cannot be ruled out.
- Do not assume that uninstalling or downgrading the package removes persistence or repository changes.
3. Rotate credentials within the blast radius
- Revoke and recreate GitHub personal access tokens, OAuth tokens, deploy keys, and GitHub Actions secrets exposed to affected hosts.
- Rotate npm tokens and review publishing permissions for every maintained package.
- Rotate cloud credentials, including AWS, Azure, GCP, Kubernetes, and container registry credentials.
- Rotate SAP BTP service keys, Cloud Foundry credentials, Destination service credentials, XSUAA credentials, HANA service bindings, and any deployment tokens present in the affected environment.
- Review whether emergency rotation is required for shared SSH keys, Git credentials, VPN profiles, or developer secrets.
4. Audit repositories and build automation
- Review new repositories, public repositories, branches, commits, workflow files, IDE configuration files, and package publishing logs.
- Remove injected .vscode and .claude persistence artifacts where present.
- Delete unauthorized repositories and revoke tokens used to create them.
- Review npm package ownership and unpublish or deprecate unexpected releases where permitted.
- Check GitHub organization audit logs for repository creation, workflow modification, token usage, and unusual branch pushes.
5. Harden dependency and publishing controls
- Pin exact versions for high-risk build dependencies and avoid floating ranges for deployment-critical packages.
- Require lockfile review for CAP and MBT projects.
- Use isolated, ephemeral CI/CD runners with minimal secrets and no reusable workspace state.
- Use least-privilege tokens and short-lived credentials wherever possible.
- Scope npm trusted publishing and OIDC rules to specific workflows on protected branches only.
- Disable automatic dependency upgrades in production-bound SAP BTP pipelines unless changes are reviewed and signed off.
- Consider dependency allowlisting, malware scanning, and provenance verification for packages used in SAP deployment workflows.
Business Impact
The main business risk is credential exposure, leading to unauthorized access. Affected credentials could allow attackers to read source code, access business logic, modify deployment pipelines, publish malicious packages, create unauthorized cloud resources, or reach SAP BTP services connected to core business processes.
For regulated customers, the exposure may also create audit and compliance implications. If secrets used for production deployments or data integrations were available to affected runners, organizations should assess whether unauthorized access to business data, regulated data, or financial reporting systems is plausible.
Availability impact is also possible. Attackers with CI/CD or BTP deployment credentials can disrupt deployment pipelines, alter runtime applications, break service bindings, or force emergency credential rotations, temporarily interrupting release processes.
Pathlock Perspective on SAP npm Supply Chain Incidnet
This incident reinforces a point SAP customers can no longer ignore: SAP security now extends to the development and automation layers. CAP, BTP, MTA build processes, GitHub workflows, npm dependencies, and build runners are part of the security boundary for productive SAP landscapes.
Pathlock customers should combine traditional SAP security controls with DevSecOps and incident response processes. SAP-side monitoring remains important, especially after credential rotation, but the first evidence of this incident is more likely to appear in lockfiles, build logs, endpoint telemetry, repository audit logs, and cloud credential activity than in classical ABAP logs.
Where Pathlock is deployed, customers can use SAP-focused vulnerability management, threat detection, code scanning, and transport monitoring as part of a wider assurance program. These controls do not replace npm/package forensic work, but they help validate SAP-side exposure, support continuous monitoring, and strengthen defense-in-depth after the immediate containment phase.
Customer Checklist
- Search all repositories, lockfiles, internal registries, containers, caches, and CI/CD logs for affected versions.
- Identify all developer machines and runners that installed affected packages.
- Quarantine or re-image affected hosts according to incident response policy.
- Rotate all credentials present on affected hosts or runners, including SAP BTP and cloud deployment credentials.
- Audit GitHub repositories, branches, workflow files, package releases, and suspicious commits.
- Remove injected IDE and AI-tool persistence files where present.
- Pin exact npm versions and review dependency update automation.
- Harden npm publishing, GitHub Actions, CI/CD secrets, and OIDC trusted publisher rules.
- Document findings, actions taken, and residual risk for audit and governance.
Recommendations
Customers using SAP CAP, SAP BTP, MBT, or JavaScript-based SAP extension development should treat SAP Note 3747787 as an incident response trigger. Even if the malicious versions were available for only a short period, automated builds, developer installs, dependency caching, and transitive dependencies can expand the real exposure window. Start with package exposure identification, then move quickly to credential rotation and repository review, where exposure is confirmed.
The key lesson is practical: patching SAP systems remains essential, but it is no longer sufficient by itself. The SAP security program must also cover the software supply chain that builds, deploys, and extends those systems.
References
- SAP Security Note 3747787 – Malicious open-source packages in SAP Cloud Application Programming Model & MTA Build Tool, released April 30, 2026.
- Aikido Security – Mini Shai-Hulud Targets SAP npm Packages With a Bun-Based Secret Stealer, published April 29, 2026.
- StepSecurity – A Mini Shai-Hulud Has Appeared: Obfuscated Bun Runtime Payloads Hit SAP-Related npm Packages, published April 29, 2026.
- Onapsis – Emerging Supply Chain Attack (Mini Shai-Hulud) Targeting SAP Cloud Application Programming Ecosystem, published April 29, 2026.
- SAP Cloud MTA Build Tool documentation – Cloud MTA Build Tool overview.
