Mini Shai-Hulud attack poisons SAP npm packages to steal GitHub, cloud, and AI coding secrets

A new npm supply chain attack hit SAP’s developer ecosystem by poisoning four packages used in SAP CAP and Cloud MTA build workflows.

The campaign, tracked as Mini Shai-Hulud, used malicious preinstall scripts to steal developer and CI/CD secrets before npm installation finished. The affected packages were mbt, @cap-js/sqlite, @cap-js/postgres, and @cap-js/db-service.

Developers or build systems that installed the compromised versions should treat GitHub tokens, npm tokens, cloud credentials, Kubernetes secrets, AI coding tool settings, SSH keys, and environment variables on the affected host as exposed.

What happened

The malicious versions were published on April 29, 2026. The attack targeted real SAP ecosystem packages, which made the incident more dangerous than a simple typosquatting campaign.

Each compromised package added a preinstall hook that ran setup.mjs. That file downloaded the Bun JavaScript runtime, then used Bun to execute a large obfuscated payload called execution.js.

The normal package files largely remained intact, so developers may not have noticed anything wrong during installation. The malicious code ran before the install process completed.

At a glance

Package	Malicious version	Last clean version	Main risk
mbt	1.2.48	1.2.47	Credential theft during install
@cap-js/sqlite	2.2.2	2.2.1	Credential theft during install
@cap-js/postgres	2.2.2	2.2.1	Credential theft during install
@cap-js/db-service	2.10.1	2.10.0	Credential theft during install

How the malware ran

The attack relied on npm lifecycle scripts. When npm sees a preinstall script, it can run that script automatically during package installation.

In this campaign, setup.mjs acted as the first stage. It checked the operating system and architecture, downloaded Bun 1.3.13 from GitHub Releases when needed, and launched execution.js.

execution.js was an obfuscated payload of about 11.6 MB to 11.7 MB. Researchers found that it used custom obfuscation and a string-scrambling layer connected to earlier Shai-Hulud-style campaigns.

Why Bun made the attack harder to spot

The malware did not run the main payload directly with Node.js. It used Node only as the loader, then shifted execution to Bun.

That matters because many JavaScript security controls focus on Node.js behavior, npm hooks, and known package-manager patterns. A separate runtime can reduce visibility if security tools do not monitor Bun execution.

The loader also downloaded Bun from the official GitHub release path. This avoided the need for an obvious attacker-controlled download server during the first stage.

What Mini Shai-Hulud stole

• GitHub personal access tokens and OAuth tokens
• npm tokens and publish-capable credentials
• GitHub Actions secrets
• AWS keys, AWS STS identity data, Secrets Manager values, and SSM parameters
• Azure subscription data, token caches, Key Vault names, and secret values
• Google Cloud project data, token databases, and Secret Manager values
• Kubernetes service account tokens
• SSH private keys
• .env files and environment variables containing keys, tokens, passwords, or secrets
• Claude Code settings, MCP configuration, VS Code task files, and Cursor-related state
• VPN configuration files, crypto wallet files, and other local developer secrets

GitHub became the exfiltration channel

The malware used stolen GitHub access to create public repositories under the victim’s own account. It then uploaded encrypted stolen data into those repositories.

The repositories used a recognizable description tied to the Mini Shai-Hulud campaign. This helped researchers find affected accounts, but it also meant sensitive corporate data could become searchable on the public internet.

The payload encrypted the collected data before upload. However, that does not protect the victim because the attacker controlled the keys needed to decrypt the stolen material.

AI coding tools were also targeted

Mini Shai-Hulud did not only target traditional developer secrets. It also looked for files used by AI coding tools and agent-style development workflows.

Researchers reported checks for Claude Code settings, MCP configuration, VS Code task files, Cursor IDE state, and related project files. These files can reveal repository access, automation hooks, local workflows, and developer environment details.

The attack also included persistence-style behavior through development tool configuration. That means opening or working inside an affected project could create more opportunities for malicious execution if poisoned files remained in place.

How the attack reached SAP packages

Public analysis points to a publishing pipeline compromise rather than a simple fake package upload. Researchers reported malicious changes in the SAP package release flow and unauthorized npm publications.

For the @cap-js packages, the trusted publishing setup appeared too broad. Researchers said the configuration trusted the repository at a wide level instead of limiting publishing to a specific workflow file and branch.

That distinction matters. Provenance can show that a package came from a GitHub Actions workflow, but it does not prove the workflow was the intended release workflow unless trust is tightly scoped.

Timeline

Time or date	Event
April 29, 2026, 09:55 UTC	mbt 1.2.48 was published
April 29, 2026, 11:25 UTC	@cap-js/sqlite 2.2.2 was published
April 29, 2026, 12:14 UTC	@cap-js/postgres 2.2.2 and @cap-js/db-service 2.10.1 were published
April 29, 2026, later the same day	Clean replacement versions were released and malicious versions were deprecated or superseded
April 30, 2026	SAP released Security Note 3747787 addressing the malicious open-source packages

Why SAP developers should act quickly

SAP CAP and MTA build tools often run inside developer laptops, CI systems, and build agents that hold sensitive deployment credentials.

A single poisoned npm install can expose secrets used to access SAP-related applications, cloud accounts, GitHub repositories, package registries, and Kubernetes clusters.

The attack window was short, but that does not make the risk small. Any install during the malicious window can expose everything available to that user or runner at that time.

How to check for exposure

Teams should inspect lock files, package manifests, CI logs, and npm cache data for the affected versions. This check should cover local developer machines and build environments.

grep -rE "mbt@?1\.2\.48|@cap-js/sqlite@?2\.2\.2|@cap-js/postgres@?2\.2\.2|@cap-js/db-service@?2\.10\.1" package-lock.json yarn.lock pnpm-lock.yaml 2>/dev/null

Security teams should also search for setup.mjs, large execution.js files, local Bun binaries downloaded during package installation, and unexpected GitHub repositories created under developer accounts.

Indicators to review

• setup.mjs inside node_modules for the affected SAP packages
• execution.js files around 11 MB or larger
• Downloads from github.com/oven-sh/bun/releases during npm install
• Unexpected public GitHub repositories with Mini Shai-Hulud-related descriptions
• New branches or workflow files that the team did not create
• .claude/settings.json files with suspicious SessionStart hooks
• .vscode/tasks.json files that launch code from .claude paths
• GitHub Actions logs showing unusual token or repository activity
• Cloud audit logs showing secret reads shortly after npm install

What to rotate after exposure

If any affected version was installed, teams should rotate secrets from a clean machine. Rotating from the compromised host can expose the new credentials too.

Start with GitHub tokens, npm tokens, SSH keys, cloud keys, Kubernetes service account tokens, SAP deployment credentials, database passwords, and every secret stored in .env files.

Then review SaaS and cloud audit logs. Look for repository creation, package publication, secret reads, new access keys, unusual API calls, or activity from developer machines and CI runners shortly after installation.

Recommended response steps

• Remove the malicious versions from all projects and caches.
• Install clean versions with scripts disabled during emergency remediation.
• Rebuild affected CI runners from clean images.
• Delete unauthorized public GitHub repositories created by the malware.
• Revoke and reissue GitHub and npm tokens.
• Rotate AWS, Azure, Google Cloud, Kubernetes, database, and SAP deployment credentials.
• Review GitHub Actions, CircleCI, Jenkins, Azure Pipelines, and other CI logs.
• Check for poisoned Claude Code and VS Code project configuration files.
• Move npm trusted publishing to a specific workflow file and branch.
• Use –ignore-scripts in CI where package lifecycle scripts are not required.

How to reduce future risk

Organizations should avoid giving CI runners long-lived secrets when short-lived OIDC-based credentials can do the job. Tokens should carry the minimum permissions needed for one workflow.

Trusted publishing should also be scoped tightly. A repository-level trust setting can still be abused if an attacker can run a different workflow or branch inside the trusted repository.

Dependency monitoring should include lifecycle scripts, not only package names and version numbers. Install-time execution remains one of the fastest ways for malicious packages to reach developer secrets.

What this means for software supply chain security

Mini Shai-Hulud shows how attackers are moving toward developer environments that combine cloud access, source code, package publishing, and AI coding tools.

The campaign also shows that provenance alone cannot solve supply chain risk. A package can come from a real repository and still be malicious if the release workflow was hijacked.

For SAP developers and enterprise security teams, the priority is clear: audit affected versions, rotate broadly, clean developer tooling configs, and lock down CI publishing paths before the next poisoned dependency appears.

FAQ