What Happened
On April 29, 2026, attackers published malicious versions of four npm packages in the SAP development ecosystem. They exploited a CI pipeline vulnerability that allowed unauthorized npm publications. The malicious code included a credential stealer called "A Mini Shai-Hulud has Appeared" with self-propagation capabilities. StepSecurity analyzed the attack mechanism, and Snyk published advisories for the compromised packages. No additional package infections were observed beyond the initial four.
The attack succeeded because the CI/CD pipeline lacked a manual approval gate before publishing to npm—a single missing control that turned a build system into a distribution channel for malware.
Timeline
April 29, 2026: Attackers publish malicious versions of four packages in SAP's @cap-js and mbt ecosystem through a compromised CI pipeline.
Post-publication: Credential stealer begins harvesting npm tokens from infected development environments.
Detection: Snyk identifies compromised packages and issues advisories.
Analysis: StepSecurity completes deobfuscation of the Bun-based stealer, revealing a self-propagation mechanism.
Containment: No further package infections observed; attack vector contained to initial four packages.
Which Controls Failed or Were Missing
Missing Manual Approval Gate
The root cause was straightforward: the CI pipeline had no human-in-the-loop approval before publishing packages to npm. Your automated build passes all tests, generates artifacts, and pushes directly to the public registry. No review. No verification. No chance to catch unauthorized publications.
Insufficient Token Scoping
The npm token used by the CI pipeline had write access to publish packages. Once stolen, that token became a self-propagation mechanism. The malware could harvest tokens from developer machines and use them to publish more malicious packages—except the attack stopped at four packages.
Your CI token should be scoped to the minimum necessary permissions. If your pipeline only publishes packages from specific branches or tags, the token should enforce that restriction at the registry level.
Weak Pipeline Authentication
The attackers exploited a CI pipeline vulnerability to trigger unauthorized publications. This suggests either:
- Insufficient authentication on pipeline triggers
- Overly permissive branch protection rules
- Missing verification of commit signatures
- Inadequate secrets management
Your pipeline should treat every trigger as potentially hostile until proven otherwise.
What the Relevant Standards Require
PCI DSS v4.0.1 Requirement 6.3.2
"Security of bespoke and custom software and application code development is managed as follows: Software development personnel working on bespoke and custom software are trained at least once every 12 months in secure development techniques."
While this requirement focuses on training, it establishes the principle that secure development includes your build and deployment infrastructure. Your CI/CD pipeline is part of your software development process.
NIST 800-53 Rev 5 SA-10: Developer Configuration Management
"The organization requires the developer of the system, system component, or system service to: (b) Manage and control changes to the system, system component, or system service during development, implementation, and operation."
Manual approval gates are a form of change management control. SA-10 expects you to manage configuration changes through your development lifecycle—including what gets published from your CI pipeline.
ISO/IEC 27001:2022 Annex A.8.32: Change Management
"Changes to information processing facilities and systems shall be subject to change management procedures."
Publishing a package is a change to your information processing facilities. A.8.32 requires formal change management procedures. Your CI/CD pipeline needs approval workflows that match the risk level of what you're deploying.
SOC 2 Type II CC6.1
"The entity implements logical access security software, infrastructure, and architectures over protected information assets to protect them from security events to meet the entity's objectives."
If you're pursuing SOC 2, your auditor will ask about your deployment controls. "We automatically publish from CI" won't satisfy CC6.1. You need documented approval processes and evidence that they're consistently followed.
Lessons and Action Items for Your Team
Implement Manual Approval Gates
Add a required approval step before any package publication:
# GitHub Actions example
publish:
runs-on: ubuntu-latest
environment: production # Requires manual approval
steps:
- name: Publish to npm
run: npm publish
Your approval gate should require:
- Review by someone other than the commit author
- Verification of package contents against expected changes
- Confirmation that version numbers match release tags
Scope Your CI Tokens Aggressively
Create separate npm tokens for different purposes:
- CI publish token: Write access only, scoped to specific packages, restricted to specific IP ranges (your CI provider's IPs)
- Developer tokens: Read-only for most developers, write access only for maintainers
- Emergency tokens: Stored offline, used only for manual interventions
Enable token expiration. Rotate your CI tokens every 90 days. Yes, this means updating secrets in your CI system quarterly—that's the point.
Audit Your Pipeline Triggers
Review who can trigger your CI pipeline and under what conditions:
- Require signed commits for release branches
- Restrict pipeline execution to specific branches
- Implement branch protection rules that require reviews before merge
- Use separate workflows for publishing versus testing
Consider: if an attacker compromises a developer account, what can they publish through your CI pipeline? The answer should be "nothing without additional approvals."
Monitor Package Publications
Set up alerts for:
- Any package publication outside normal release windows
- Publications from unexpected geographic locations
- Changes to package maintainer lists
- New packages published under your organization's scope
Use tools like Snyk or Socket to monitor your dependencies for unexpected changes. The goal is detection within minutes, not days.
Document Your Approval Process
Write down exactly what happens between "merge to main" and "package published to npm." Include:
- Who can approve publications
- What they're expected to verify
- How long approvals remain valid
- What to do if an unauthorized publication is detected
Your documentation serves two purposes: it guides your team during normal operations and it satisfies auditor questions during compliance reviews.
Test Your Incident Response
Run a tabletop exercise: "We just discovered a malicious package was published from our CI pipeline two hours ago. What do we do?"
Your team should know:
- How to immediately revoke the compromised CI token
- How to unpublish or deprecate the malicious package
- How to notify downstream consumers
- How to identify which systems might be affected
The SAP ecosystem contained this attack to four packages. Your goal is to contain it to zero.
