A new wave of malicious code has slipped into the heart of the SAP development ecosystem. Researchers tracking a campaign nicknamed "Mini Shai-Hulud" confirmed that several official SAP-related npm packages were trojanized to harvest developer, CI/CD, and cloud credentials, then self-propagate through any token they could reach. For Saudi banks running SAP on top of cloud-native pipelines, the blast radius is wider than it looks.

What happened in the SAP npm compromise

On April 29, 2026, multiple research teams publicly detailed a coordinated supply chain attack against npm packages that underpin SAP's Cloud Application Programming Model (CAP) and Multi-Target Application (MTA) tooling. Confirmed compromised versions include @cap-js/sqlite 2.2.2, @cap-js/postgres 2.2.2, @cap-js/db-service 2.10.1, and mbt 1.2.48. Each tampered release introduced a malicious npm preinstall hook that fired the moment a developer or build agent ran npm install. The hook downloaded the Bun JavaScript runtime from GitHub and used it to execute an obfuscated payload — a tradecraft borrowed almost directly from the original Shai-Hulud worm and attributed by Wiz researchers to the TeamPCP cluster.

Why this is more dangerous than a typical npm typosquat

The "Mini" label undersells the impact. Unlike opportunistic typosquats, this campaign rode legitimate, signed package names already trusted inside enterprise SAP delivery pipelines. Once executed, the payload swept the host for npm tokens, GitHub Actions secrets, AWS, Azure, GCP, and Kubernetes credentials, then exfiltrated them through public GitHub repositories created on the victim's own account labelled "A Mini Shai-Hulud has Appeared." The same payload then attempted to use those harvested tokens to publish trojanized versions of further packages and repositories — meaning a single infected build agent inside a bank can become an upstream attacker against partners, fintech subsidiaries, and downstream regulators.

Impact on Saudi financial institutions

SAP is the de facto core of finance, treasury, and ERP operations across most SAMA-regulated banks and several PIF portfolio companies. Many of those teams have moved CAP-based extensions into Azure DevOps, GitHub Enterprise, and SAP BTP pipelines, which is exactly where this campaign lands. Under the SAMA Cyber Security Framework and the SAMA Cyber Security Compliance Controls (CSCC), supply chain risk is no longer a soft control — Domain 3 expects member organizations to maintain an authoritative inventory of third-party software, monitor cryptographic integrity of dependencies, and contain blast radius from build agents. NCA ECC subdomain 2-12 carries similar weight, and PDPL Article 29 holds the controller accountable when a processor's compromise leaks personal data of bank customers. A silent npm install inside a developer laptop in Riyadh or a GitHub-hosted runner in Frankfurt can trigger reportable obligations under all three regimes simultaneously.

Recommended actions and practical steps

  1. Pin and verify versions: lock @cap-js/sqlite, @cap-js/postgres, @cap-js/db-service, and mbt to known-good releases prior to the compromise window, and reject the trojanized versions in your private registry or Artifactory proxy.
  2. Hunt for the indicators: search developer endpoints and CI runners for the strings setup.mjs and execution.js spawned by Bun, unexpected outbound calls to raw.githubusercontent.com fetching Bun binaries, and freshly created public repositories on corporate GitHub accounts with the description containing "Shai-Hulud."
  3. Rotate every secret a build agent can reach — npm tokens, GitHub PATs, GitHub Actions OIDC trust policies, AWS access keys, Azure service principals, GCP service account keys, and Kubernetes kubeconfigs. Treat anything that touched an SAP CAP pipeline in the last two weeks as compromised by default.
  4. Disable npm preinstall, install, and postinstall scripts on CI by default using npm ci --ignore-scripts, and only allow them through an allow-list backed by code review.
  5. Move build runners behind egress filtering so that pulling arbitrary GitHub release binaries (Bun, Deno, custom loaders) requires explicit policy approval, not network silence.
  6. Map this incident to your SAMA CSCC evidence pack: update the third-party inventory, file the breach scenario inside your operational risk register, and ensure the cyber incident reporting workflow to SAMA is rehearsed end-to-end.
  7. Brief the board on systemic supply chain risk. Most Saudi banks still measure third-party risk by vendor questionnaire, not by build pipeline telemetry — Mini Shai-Hulud shows why that gap is now a regulatory exposure, not a technical preference.

Conclusion

Mini Shai-Hulud is a reminder that the modern bank perimeter no longer ends at the firewall — it extends into every npm registry, every GitHub Action, and every developer laptop touching SAP CAP code. The institutions that will pass their next SAMA CSCC and NCA ECC audits cleanly are the ones that can prove, with telemetry and not paperwork, that a tainted dependency cannot reach production undetected.

Is your organization prepared? Contact Fyntralink for a complimentary SAMA Cyber Maturity Assessment focused on software supply chain and CI/CD security controls.