Compromised official SAP npm packages injected a malicious preinstall script to steal tokens and CI secrets. Misryoum breaks down what happened and how to respond.
Four official SAP npm packages have been compromised in a supply-chain attack designed to steal credentials from developers and CI/CD systems.
The focus keyphrase. “SAP npm credential theft. ” matters because it points to the real target: not just npm accounts. but the authentication tokens and cloud keys that enterprise teams routinely embed in development workflows.. Misryoum readers should treat this as a serious warning about how quickly a trusted dependency can become a quiet backdoor.
The incident centers on packages linked to SAP’s Cloud Application Programming Model (CAP) and related tooling. Researchers say the compromised releases have been deprecated on npm and include:
@cap-js/sqlite (v2.2.2)
@cap-js/postgres (v2.2.2)
@cap-js/db-service (v2.10.1)
mbt (v1.2.48)
According to reports circulated by security researchers. the malicious change was added through an npm “preinstall” script—code that runs automatically when the package is installed.. That detail is crucial: it turns a routine developer action (installing dependencies) into an execution trigger. often before teams have time to notice anything unusual.
The payload is reported to use a multi-step loader flow.. It pulls the Bun JavaScript runtime from GitHub. then uses it to execute an obfuscated script (setup.mjs leads to an execution payload).. While the implementation details are technical, the outcome is straightforward and damaging: the malware is designed as an information stealer.
Reports describe a wide theft scope, reaching beyond a single type of token.. Stolen items can include npm and GitHub authentication tokens. SSH keys and other developer credentials. cloud credentials for major providers. Kubernetes configuration and secrets. and secrets placed into CI/CD environments.. In practice. that means a compromise doesn’t stop at one workstation—it can pivot into the systems that build. test. and deploy software.
A particularly alarming part of the report is how the malware targets CI runners.. Instead of relying only on files or logs, it attempts to read secrets directly from runner memory.. Misryoum notes that this approach matters because many CI platforms mask values in logs. but memory-based extraction can bypass those safeguards—especially when secrets are held briefly and operations are automated.
Once the malware collects data, it is encrypted and exfiltrated.. Researchers also report that the stolen information is uploaded to public GitHub repositories under the victim’s account. obscuring the theft within what looks like normal repository activity.. An additional dead-drop mechanism is described as well: the malware searches GitHub commit messages for a specific string and uses matching commit content to retrieve tokens for further access.
The attackers are also reported to include self-propagation logic.. After obtaining npm or GitHub access. the malware attempts to modify other packages and repositories it can reach. injecting the same malicious behavior to spread the compromise further.. That’s how supply-chain incidents evolve from a single compromised release into wider ecosystem damage—especially when organizations reuse dependencies across projects.
Misryoum’s editorial takeaway is about trust, not just technique.. CAP-related packages and enterprise build tools tend to be pulled into long-lived corporate pipelines. so a single dependency tampering can create a repeated exposure pattern.. Even teams that practice dependency hygiene can still be caught if a compromised version is installed during routine updates. fresh environments. or incident-driven rebuilds.
There’s also the open question of how SAP’s npm publishing process was compromised.. The reports suggest it may have involved exposure of an npm token. potentially tied to misconfiguration in an automated workflow environment.. Misryoum highlights this because it’s a recurring supply-chain theme: attackers don’t always need to break cryptography or invent a new vulnerability.. Sometimes they only need a credential foothold inside a pipeline.
What should organizations do now?. Start by treating the deprecated versions as unsafe defaults: remove them from lockfiles where possible. rebuild clean environments. and confirm that CI runner credentials and access keys were not exposed during installs.. Review recent CI/CD logs for signs of unusual network activity related to dependency installation steps. and rotate any tokens that could have been present during builds—particularly npm. GitHub. cloud. and Kubernetes-related credentials.. Finally, validate that build scripts and package install steps have not been altered beyond what your team expects.
The broader lesson for the software supply chain is grim but actionable: “official” doesn’t mean “immutable. ” and “install” doesn’t mean “safe.” With supply-chain attacks increasingly engineered around automation. Misryoum expects more incidents that blend credential theft. CI memory scraping. and public-platform exfiltration in ways that are hard to detect with traditional file-scanning alone.