Attack on SAP CAP in npm exposes tokens and credentials through memory theft of runners by TeamPCP

A set of official SAP packages published in the npm record was compromised and, according to analysis of several research teams, the intrusion coincides with the tactical-operational signature of the group known as TeamPCP. The affected versions that were published with malicious code and have already been deprecated in npm include @ cap-js / sqlite v2.2.2, @ cap-js / postgres v2.2.2, @ cap-js / db-service v2.10.1 and mbt v1.2.48, components linked to the Cloud Application Programming (CAP) and Cloud MTA model that are used in business developments.

Aikido and Socket researchers have documented that the compromised package adds a pre-installation script that launches a loader called setup.mjs, which in turn downloads the runtime Bun from GitHub and runs a dodged payload called exection.js. This payload acts as an information thief designed to extract tokens from npm and GitHub, SSH keys, cloud supplier credentials (AWS, Azure, GCP), Kubernetes settings and secrets and CI / CD environment variables, in addition to trying to read memory of CI runners to evade the masking of secrets.

The documented exfiltration mechanism includes the encryption of the stolen information and its rise to GitHub public repositories created under victim accounts, using descriptions with the "A Mini Shai-Hulud has Appeted" chain. In addition, malware uses a "dead-drop" technique by committing messages in GitHub with the form "OhNoWhatsGoingOnWithGitHub:"to recover tokens, which allows to expand the scope and persistence of the attacker. These details are included in the reports of Aikido and Socket: Aikido - Mini Shai-Hulud and Socket - SAP CAP attack analysis.

The ability of malware to read / proc / pid/ maps and / proc / pid/ mem in Linux runners reproduces tactics seen in previous commitments attributed to TeamPCP against suppliers such as Bitwarden and Checkmark: secrets are removed directly from the memory of the runner process to evade any masking of the CI supplier's login. With stolen credentials, the actor tries to spread automatically by modifying other packages and repositories to insert the same malicious chain.

On the initial vector, there is no public confirmation of SAP at the close of the reports, but researchers point to the possibility that a token npm would be exposed by a missetting of a CircleCI Job, which is in line with earlier patterns in which CI credentials served as a malicious publication pivot. As SAP investigates, organizations using CAP or the bookstores concerned must take a risk of commitment in their development chains.

The recommended immediate actions include rotating and revoking any token and credential that may have been present in machines or CI: regenerate npm and GitHub tokens, rotate SSH keys, renew cloud credentials and regenerate CI secrets. It is essential to inspect the repositories and accounts in GitHub in search of new repos created with the above description and to review the history of commitments by suspicious patterns such as "OhNoWhatsGoingOnWithGitHub:." It is also appropriate to revoke committed runners and reconstruct them from clean images to remove any backdoor in memory or in the file system.

In the background, development and deployment practices should be strengthened: enabling multi-factor authentication and the use of tokens with the least privilege possible, migrating to federated or ODIC authentication mechanisms for CI where feasible, activating secret scanning and advanced repository protection (e.g., GitHub Advanced Security), and setting dependency versions through lockfiles and pipeline change approval policies. Third-party software scanning tools (SCA) and package integrity monitoring help to detect unauthorized modifications in published artifacts.

From the operational point of view, it is critical to audit access logs to repositories and APis cloud by unusual activity, block unauthorized exfiltration with egress controls and review the CI configuration to prevent sensitive variables from getting soaked in buildings or exposed in public jobs. Consider the use of ephemeral tokens, automatic rotation and strict separation of publication credentials from those of execution reduce the exposure window to a future commitment.

This incident again highlights that software supply chains are a high-value target and that a single poorly configured token or pipeline can give access to complete corporate environments. The defence requires both technical controls (hardening CI, rotation of secrets, least privilege) and governance: clear policies on package publication, human reviews and rapid response to commitment signals. For practical guides on tokens management and credentials, please refer to GitHub's recommendations on personal and access tokens: GitHub - Personal Access Tokens, and npm documentation on safety and tokens: npm - Access Tokens.

If your organization uses SAP CAP or the bookstores concerned, act now: it evaluates exposure, makes commitment to prove otherwise, runs rotations and reconstructions, and takes advantage of this incident to raise the defense of the supply chain and the hygiene of secrets at the corporate level.