On July 14, a misconfigured GitHub Actions workflow turned AsyncAPI's npm packages into a distribution channel for credential-stealing malware. The attack lasted just over four hours, but the packages were downloaded more than 2.25 million times per week before the compromise.
This wasn't a sophisticated zero-day exploit. It was a CI/CD configuration error that let an attacker publish malicious code with legitimate provenance attestations, making the packages appear trustworthy to automated security checks.
What Happened
An attacker exploited a misconfigured GitHub Actions workflow in AsyncAPI's repository to publish five malicious versions of their npm packages. These packages contained a remote access trojan designed to steal credentials and sensitive information from developer environments.
The attacker used GitHub's OIDC trusted-publisher integration to push packages that included legitimate SLSA provenance attestations. To most security tools and developers, these packages looked properly signed and verified through AsyncAPI's official publishing pipeline.
Timeline
July 14, approximately 4 hours and 7 minutes:
- Attacker exploits misconfigured GitHub Actions workflow
- Five malicious package versions published to npm with valid provenance attestations
- Packages begin distributing credential-stealing malware to downstream users
- AsyncAPI team detects the compromise and removes malicious versions
The exposure window was brief, but the weekly download volume meant thousands of development environments potentially received the malicious code before the team could respond.
Which Controls Failed
Pipeline access controls: The GitHub Actions workflow allowed unauthorized package publication. This suggests either overly permissive workflow triggers or inadequate authentication requirements for publishing operations.
Change approval process: No human review occurred before the malicious packages reached npm. Automated publishing workflows bypassed any manual verification step.
Anomaly detection: The publishing system didn't flag unusual package releases. Five versions published in rapid succession during a brief window should have triggered alerts.
Provenance verification: While SLSA attestations were present, they only proved the packages came through AsyncAPI's pipeline, not that the pipeline itself was operating correctly. The attestations became a false signal of trustworthiness.
What the Standards Require
NIST 800-53 Rev 5, Control SA-10 (Developer Configuration Management) requires organizations to "employ configuration management during system and component development, implementation, and operation." This includes controlling changes to development and build environments.
For CI/CD pipelines specifically, this means:
- Document who can trigger publishing workflows
- Require approval for changes to workflow configurations
- Log all publishing operations with actor attribution
- Review workflow permissions at least quarterly
ISO/IEC 27001:2022, Control 8.32 (Change Management) requires that "changes to information processing facilities and systems shall be subject to change management procedures." Your publishing pipeline is an information processing facility. Treat workflow configuration changes like production code changes.
SOC 2 Type II, Common Criteria CC6.1 requires that "the entity implements logical access security software, infrastructure, and architectures over protected information assets to protect them from security events." Your package publishing credentials are protected information assets. They need the same access controls as your production database credentials.
Lessons and Action Items
Implement workflow approval for package publishing. Configure your GitHub Actions workflows to require manual approval before publishing to package registries. GitHub's environment protection rules let you designate specific users who must approve deployments. Set this up for any workflow that publishes to npm, PyPI, or similar registries.
Separate publishing credentials from general CI credentials. Don't use the same GitHub token for running tests and publishing packages. Create a dedicated publishing token with minimal permissions, store it as an environment secret, and only make it available to explicitly approved workflows.
Add anomaly detection to your publishing pipeline. Track your normal publishing cadence and flag deviations. If you typically publish once per week and suddenly see five releases in four hours, that's an alert. This doesn't require expensive tooling -- a simple script that checks your release history and sends a Slack message works.
Verify workflow integrity before trusting provenance. SLSA attestations prove a package came through your pipeline, but they don't prove your pipeline wasn't compromised. Before you trust provenance from any package, verify:
- The workflow configuration hasn't changed recently
- The publishing actor matches expected users or service accounts
- The release timing aligns with your normal patterns
Review your OIDC trusted publisher configuration. If you use GitHub's OIDC integration for package publishing, audit which workflows have publishing permissions. Remove any workflows that don't need them. Document why each remaining workflow needs those permissions.
Implement pre-publish scanning. Run security scans on packages before they reach the registry, not after. Tools like npm audit, Snyk, or Socket can detect suspicious patterns in package contents. Configure these as required checks in your publishing workflow.
Create a rollback procedure. Document how to quickly unpublish compromised packages and notify users. AsyncAPI's four-hour response suggests they had this process ready. You need the same capability, including pre-written communication templates and a list of notification channels.
The AsyncAPI incident shows that supply-chain attacks don't require sophisticated techniques when CI/CD pipelines have basic configuration errors. Your GitHub Actions workflows are publishing infrastructure. Secure them accordingly.
