TL;DR: Malicious npm packages used in SAP CAP and MTA build workflows executed during dependency installation, targeting developer machines, CI/CD runners, build containers, and repositories for secrets, tokens, and cloud credentials, according to Pathlock and SAP Security Note 3747787. The incident shows that SAP security now has to cover the software supply chain that builds and deploys extensions, not just the application stack.
At a glance
What this is: This is a supply chain compromise in SAP’s JavaScript build ecosystem that turned dependency installation into a credential-stealing event across developer and CI/CD environments.
Why it matters: It matters because build systems often hold the deployment, cloud, and repository credentials that let attackers move from code supply chain compromise into production access.
Context
This incident is not a classic SAP application exploit. It is a software supply chain compromise in the SAP development and deployment layer, where npm packages, build tools, and automation jobs can execute code before a team ever deploys an application.
The governance gap is that many SAP programmes still separate application security from build security. Once dependency installation can run attacker-controlled code, the identity boundary shifts to developer workstations, CI/CD runners, artifact caches, and the credentials those systems can access.
For SAP BTP and extension-heavy environments, that means the security model has to include repository trust, build provenance, and secrets exposure in the same programme that covers transport and runtime controls.
Key questions
Q: What breaks when a malicious npm package runs inside SAP build workflows?
A: The assumption that dependency installation is a safe, pre-runtime activity breaks immediately. A package can execute during install, access credentials already present on developer or CI/CD systems, and turn a build step into a secret-exposure event before the application ever runs.
Q: Why do CI/CD runners and developer machines make supply chain attacks more damaging?
A: They often hold cloud credentials, repository tokens, deployment keys, and other high-value identities in one place. If those systems are allowed broad secrets access, a package compromise can move from code execution to repository control and environment access with very little extra effort.
Q: What signs suggest a package-based supply chain compromise has spread beyond source code?
A: Look for unexpected workflow changes, new repositories, unusual package publishes, injected IDE or automation files, and token activity that does not match approved developer behaviour. Those signals indicate the attacker may have used stolen build credentials to propagate the compromise.
Q: How should teams reduce build-system identity risk without slowing delivery?
A: Start with exact version pinning, least-privilege publishing rights, isolated ephemeral runners, and short-lived credentials on build hosts. Then add provenance checks and tighter review of dependency updates so installation-time execution has fewer opportunities to reach sensitive identities.
Technical breakdown
Installation-time execution in npm workflows
The malicious packages executed during dependency installation through package lifecycle scripts, not through the target application itself. That matters because npm install, npm ci, yarn install, and similar jobs often run in privileged developer or pipeline contexts that already contain tokens, cloud credentials, and repository secrets. The payload therefore inherits the trust of the build process and can act before runtime controls, testing gates, or application telemetry have any chance to intervene. In practice, this is a build-chain execution problem, not a production-app defect.
Practical implication: Treat dependency installation as an execution boundary and review what code is allowed to run during builds.
Credential collection from developer and CI/CD environments
The malware searched local hosts and runners for secrets, tokens, configuration files, and environment variables. That included GitHub tokens, npm tokens, cloud credentials, Kubernetes config, SSH keys, and SAP-related deployment credentials where present. Build and developer systems are attractive because they concentrate short-lived and long-lived identities in one place, often with broader scope than production workloads. Once those credentials are harvested, the compromise moves from package installation into downstream access risk across source control, cloud, and deployment services.
Practical implication: Map which identities are present on build hosts and reduce the blast radius of every credential stored there.
Propagation through repository and workflow abuse
The article describes stolen tokens being used to modify repositories, inject workflow or IDE configuration, and publish additional malicious versions. That creates a recursive supply chain loop: a compromised build identity can generate new artifacts, which then become new trusted inputs elsewhere. Using a separate runtime such as Bun during installation also changes the execution profile and can bypass monitoring tuned only for expected Node.js behaviour. The control problem is not merely detection, but trust in who can alter the software inputs that other systems consume.
Practical implication: Harden publishing rights, workflow permissions, and provenance checks so one compromised build identity cannot seed the next compromise.
Threat narrative
Attacker objective: Steal build and deployment credentials so compromise can extend from package installation into repository control, cloud access, and SAP BTP deployment abuse.
- Entry occurred when a malicious npm version was resolved during a normal dependency install in SAP CAP or MTA build workflows.
- Credential harvesting followed as the payload searched developer machines, CI/CD runners, build containers, and caches for secrets, tokens, and cloud credentials.
- Escalation and propagation occurred when stolen GitHub or npm credentials were used to modify repositories, inject workflow files, and publish further malicious versions.
- Impact was unauthorized access to source, pipelines, cloud services, and SAP BTP-related deployment paths, with possible business and compliance consequences.
Breaches seen in the wild
- Mini Shai-Hulud SAP npm attack 2026: Mini Shai-Hulud poisoned SAP npm packages with a Bun-based stealer in April 2026, then hit Mistral and OpenSearch; Wiz blames TeamPCP.
- Shai Hulud npm malware campaign: Shai Hulud campaign: npm malware exposed secrets on GitHub.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Build identity has become part of the SAP security boundary: The compromise worked because dependency installation is now a privileged identity event, not a neutral software step. CAP and MTA workflows can execute code with access to deployment tokens, cloud credentials, and repository secrets before any runtime control exists. The practical implication is that SAP security programmes must treat build runners, caches, and package managers as governed identity surfaces, not just engineering infrastructure.
Trusted package execution is a supply chain trust problem, not only a malware problem: The malware kept legitimate package behaviour intact long enough to avoid immediate suspicion, which is why classic app-centric detection is insufficient. A package that installs cleanly can still run attacker code in preinstall or setup stages and use a different runtime to sidestep expected telemetry. The implication is that provenance, version pinning, and install-time policy have to carry more weight than after-the-fact endpoint review.
Credential exposure in build systems is the identity blast radius that matters: The article shows that build hosts often contain the exact identities attackers want, including cloud tokens, npm tokens, SSH keys, and SAP BTP deployment credentials. Once those are stolen, the compromise moves well beyond source code and into deployment authority. The implication is that security teams should judge build-system risk by what identities it can issue or reveal, not by whether the build node itself is hardened.
Repository and workflow integrity are now downstream controls for software supply chain compromise: If stolen credentials can create repositories, alter workflows, or publish package updates, then the governance failure is not only credential theft but unchecked reuse of build authority. This is where NHI governance, DevSecOps, and incident response converge. The implication is that teams need one control model for package trust, workflow permissions, and credential lifecycle rather than separate silos.
Dependency trust debt: This incident is a clear example of accumulated trust in package ecosystems becoming operational debt. The more build pipelines depend on transitive packages, internal mirrors, and cached artefacts, the wider the hidden exposure window becomes. The implication is that practitioners should assume any build dependency can become an identity compromise path until provenance and install-time controls prove otherwise.
From our research library:
- 92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to the Ultimate Guide to NHIs.
- Read next: AI Supply Chain Security and AI-BOM Guide
What this signals
Identity in the build layer is no longer optional governance: Teams that still separate application security from CI/CD identity controls will miss the place where modern supply chain compromises actually land. The practical shift is to treat package installation, artifact creation, and publishing authority as one governed identity path.
Build provenance and secrets containment now belong in the same control conversation: A dependency that can execute during install and a runner that stores deployment credentials create one risk surface. Once those two conditions exist together, a compromise can jump from code to deployment without needing a production exploit.
Supply chain trust debt grows when package ecosystems are allowed to touch broad credentials: The more a build system can reach cloud, repository, and SAP deployment identities, the wider the blast radius becomes. Teams should expect attacker focus to keep moving toward the identities that sit inside pipeline tooling.
For practitioners
- Identify every affected install path Search source repositories, lockfiles, package caches, artifact repositories, container layers, and CI/CD logs for the compromised package versions and related install jobs.
- Quarantine build hosts with exposure Isolate developer machines and CI/CD runners that installed the affected versions, and re-image systems where compromise is confirmed or cannot be ruled out.
- Rotate credentials in the build blast radius Revoke and recreate GitHub tokens, npm tokens, cloud credentials, Kubernetes config, SSH keys, SAP BTP service keys, and any deployment secrets present on affected hosts.
- Audit repository and workflow changes Review new repositories, workflow files, branch pushes, package publishes, and unexpected IDE or automation files that may have been used for persistence or propagation.
- Pin and constrain dependency execution Use exact version pinning for high-risk build dependencies, restrict install-time scripts where feasible, and scope publishing or OIDC trust to protected workflows only.
Key takeaways
- This incident shows that malicious npm packages can turn SAP build workflows into credential collection points, not just code delivery paths.
- The exposure is operationally broad because developer machines, CI/CD runners, caches, and artifact layers may all hold identities worth stealing.
- Reducing risk depends on tighter control of build-time execution, repository trust, and credential scope, not only on application patching.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | The article centers on secrets stolen from build hosts and runners during package installation. |
| NHI-03 — Vulnerable Third-Party NHI | A third-party package became the execution path for credential theft in SAP build workflows. | |
| NHI-07 — Long-Lived Secrets | Broad deployment and repository credentials expanded the blast radius once the malware landed. | |
| Recommendation — Scan build systems for exposed secrets and revoke any credentials touched by compromised installs. Review third-party package trust and limit what install-time code can execute in pipelines. Replace long-lived build secrets with short-lived credentials wherever pipelines can support them. | ||
| MITRE ATT&CK | TA0006;TA0010 — Credential Access; Exfiltration | The campaign harvested credentials and exfiltrated them through attacker-controlled infrastructure. |
| TA0003;TA0008 — Persistence; Lateral Movement | Stolen tokens were used to modify repositories and spread the compromise through trusted workflows. | |
| Recommendation — Map install-time credential theft to TA0006 and TA0010 and hunt for secret exfiltration in build logs. Track repository tampering and token reuse as persistence and lateral movement indicators. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | The incident depended on exposed tokens, keys, and deployment credentials on build hosts. |
| Recommendation — Apply IA-5 to shorten credential lifetime and enforce rotation for pipeline identities. | ||
| CIS Controls v8 | CIS-5 — Account Management | The response requires revoking and reviewing the accounts and tokens used in affected workflows. |
| Recommendation — Use CIS-5 to inventory and remove accounts and tokens that touched compromised builds. | ||
Key terms
- Build identity: The set of credentials, tokens, keys, and permissions used by CI/CD systems, runners, and developer tooling. Build identity is often overlooked, yet it can expose secrets, alter repositories, and propagate compromise into downstream software if not tightly scoped and monitored.
- Install-Time Execution: Install-time execution is code that runs while dependencies are being installed rather than when an application is launched. In supply chain attacks, this matters because the install phase often has access to the richest secrets in developer and CI environments, making it a high-value privilege boundary.
- Repository Propagation: The spread of a compromise through source control, workflow files, package publishing, or automation artefacts. In modern supply chain attacks, stolen credentials can be used to modify trusted repositories, publish follow-on malicious packages, or inject persistence into tools that other teams treat as legitimate inputs.
- Credential Blast Radius: Credential blast radius is the amount of access, data, and system reach that a single compromised secret can unlock. The wider the blast radius, the more damage one leaked token or certificate can cause. Reducing it requires tighter scope, faster revocation, and better segmentation.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on June 2, 2026.
Updated on October 8, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org