Malicious versions of four SAP-related npm packages exposed developer machines and CI/CD systems to possible credential theft. Rather than targeting production SAP servers directly, the attack reached into the build pipeline used to create and deploy SAP applications.
The malicious package versions were published to the public npm registry on April 29, according to Pathlock. The affected versions were @cap-js/sqlite 2.2.2, @cap-js/postgres 2.2.2, @cap-js/db-service 2.10.1 and mbt 1.2.48.
The packages are used in standard SAP development and deployment workflows. CAP is commonly used to build SAP BTP applications, side-by-side extensions, Fiori backends, and integration services. The MTA Build Tool is used to package applications for deployment into SAP BTP and related Cloud Foundry-style environments.
“In practical terms, the incident matters because the malware runs where development and deployment credentials often exist,” said Jonathan Stross, Senior Product Manager, R&I Cybersecurity at Pathlock.
The compromised packages sat inside tooling that developers use to build and deploy SAP applications. The compromise did not target SAP production infrastructure directly, but the development layer around it: machines, build systems, package caches, containers and CI/CD runners that sit upstream from production.
Installation, Not Deployment, Triggered the Risk
The malicious code could run before an application was ever deployed.
According to Pathlock, the compromised packages used npm installation-time code. A modified package.json invoked a new setup.mjs loader during npm install, which then bootstrapped the next stage of the attack.
That timing widened the exposure. Because npm lifecycle scripts can run during installation, the payload could execute on any developer workstation, CI/CD runner, build container, or automated job that installed one of the affected package versions. No application launch or deployment was required.
Build systems are especially sensitive targets because they often operate from a trusted position. They pull dependencies, handle credentials, communicate with repositories, package applications, and prepare releases. In this case, that trust became the entry point.
The Malware Targeted Developer and CI/CD Credentials
Pathlock said the malware searched affected machines and CI/CD runners for credentials commonly found in developer and build environments, including GitHub tokens, npm credentials, cloud keys, Kubernetes configuration files, SSH keys, local Git credentials, environment variables and build-time secrets.
Those credentials are valuable because pipelines often need access to repositories, package registries, cloud services and deployment systems to function. For SAP customers, the potential blast radius could extend beyond source code or package publishing access. If affected environments held SAP BTP service keys, Cloud Foundry credentials, Destination service credentials, XSUAA bindings, HANA service keys or deployment tokens, attackers could potentially gain access to systems tied to SAP business processes.
A stolen token from a developer machine or build runner can become a route into business-critical systems. In that scenario, attackers may be able to reach SAP-connected environments through stolen deployment credentials rather than by exploiting production SAP servers directly.
GitHub Became Part of the Attacker’s Infrastructure
According to Pathlock, stolen data was encrypted and exfiltrated through GitHub infrastructure, including repositories created under victim accounts. The report also lists several GitHub-related indicators, including repositories with the description “A Mini Shai-Hulud has Appeared,” commits containing the marker OhNoWhatsGoingOnWithGitHub, unexpected workflow changes, suspicious branches, and unauthorized package publishing activity.
Pathlock advised organizations to look beyond repository history as well. Other indicators included unexpected .vscode/tasks.json entries and unfamiliar .claude files, including settings.json, setup.mjs and execution.js.
The use of GitHub complicates detection because the activity can resemble normal development work. Commits, workflow changes, new branches, package publishing, and IDE configuration files are routine in engineering environments, making repository and CI/CD-level review essential.
SAP Security Now Includes the Build Pipeline
SAP security has traditionally centered on systems most organizations recognize: ABAP, Gateway, RFC, NetWeaver, SAProuter, kernel patching and controls around production applications. Those remain important, but this incident shows how much of the SAP attack surface now sits outside that traditional stack.
CAP applications, BTP services, MTA build processes, npm dependencies, GitHub workflows, package registries, build containers, and CI/CD runners are now part of the same security boundary. They may not look like SAP infrastructure, but they help build and deploy applications that connect to SAP environments.
“The practical risk is that attackers do not need to exploit a production SAP application server first,” Stross said. “They can target the development path that leads to production.”
How Organizations Should Respond
“Any developer machine, CI/CD runner, build container, or artifact cache that installed the affected versions should be handled as a potential credential compromise,” Stross said.
Teams should first determine whether the affected versions were installed. That means checking repositories and lockfiles, but also internal package registries, npm mirrors, container images, build caches, artifact repositories, and CI/CD logs. The key question is not just whether the dependency appears in source control, but whether any developer machine, runner, container, or automated job installed it.
Where exposure is confirmed or cannot be ruled out, organizations should identify affected hosts, projects, repositories, and accounts; quarantine or re-image systems as needed; and rotate credentials within the blast radius. That includes GitHub, npm, cloud, Kubernetes, and SAP-specific credentials such as BTP service keys, Cloud Foundry credentials, XSUAA credentials, HANA service bindings, and deployment tokens.
Teams should also audit repositories, branches, workflow files, package releases, suspicious commits, and unexpected IDE or AI-tool configuration files for signs of unauthorized changes.
Longer term, organizations should tighten controls around the development path by pinning high-risk dependency versions, reviewing lockfile changes, restricting automatic updates in production-bound pipelines, using short-lived CI/CD runners with minimal secrets, and narrowing token permissions.
SAP security programs now have to account not only for production systems, but also for the software supply chain that builds and deploys them. If the build system can reach production, it has to be treated like part of production.
