Last week, security researchers found that an attacker published malicious npm packages to the official @asyncapi namespace without stealing any credentials. They hijacked the project's GitHub Actions workflow to push malware with valid SLSA provenance attestations. The packages passed automated checks because they were technically built and signed by the legitimate pipeline.
This incident isn't isolated. It's a glimpse into the future of supply chain attacks, raising critical questions for every DevOps team about their CI/CD security posture.
The Source of These Questions
These questions have been coming up from teams after discussing the AsyncAPI incident. Whether from Slack channels or security review meetings, they all share the same concern: if provenance attestations and OIDC tokens aren't enough, what truly protects our pipelines?
How Did They Publish to the Official Namespace?
The attacker compromised the project's GitHub Actions workflow configuration, not the npm credentials. They altered the workflow to build and publish their malicious packages using the project's legitimate release pipeline. GitHub's OIDC integration allows workflows to authenticate to npm without long-lived tokens, so the malicious packages were published with valid provenance attestations from the official repository.
This is the security model working as designed, which is the problem. The workflow had permission to publish, it was compromised, and the malware got published with a stamp of legitimacy.
Is SLSA Provenance Useless?
Not useless, but insufficient alone. Provenance attestations show where a package was built and what workflow produced it. They don't confirm if the workflow was doing what you expected.
In the AsyncAPI attack, the provenance was accurate: these packages were built by the official GitHub Actions workflow. The attestation just couldn't reveal that the workflow had been modified to include malicious steps.
Think of provenance like a shipping label. It tells you which warehouse sent the package, but it doesn't verify what's inside the box.
Are Your GitHub Actions Workflows Vulnerable?
Start by checking workflow file permissions. See if your workflows use permissions: write-all or have overly broad contents: write and packages: write scopes. The attacker needs write access to modify workflow files and publish artifacts.
Look for workflows that:
- Run on pull requests from forks without approval gates
- Use
workflow_dispatchtriggers without authentication checks - Install dependencies from untrusted sources during the build
- Execute code from PR branches before review
Review your branch protection rules. If your main branch allows direct commits or doesn't require pull request reviews, an attacker who compromises a single maintainer account can modify workflows directly.
Do Required Reviews for PRs Protect Us?
They help, but aren't enough. Developers often review workflow changes like code changes: quickly, focusing on functionality rather than security. A malicious workflow modification disguised as a build optimization might get approved.
Consider who can approve workflow changes. If your CODEOWNERS file doesn't specifically protect .github/workflows/* with a separate security-focused review team, any maintainer with write access can approve changes to the pipeline itself.
Set up a separate review requirement for workflow files. Treat changes to .github/workflows/ like changes to your production deployment scripts, because that's exactly what they are.
What Does the Miasma Malware Do?
The compromised packages deploy a multi-stage payload. The first stage is obfuscated JavaScript that downloads an encrypted second-stage payload from IPFS. That second stage is Miasma, a botnet framework that establishes persistence and awaits commands.
The sophistication matters. This isn't a cryptocurrency miner or a credential stealer that you might detect quickly through resource usage or network traffic patterns. It's a framework designed for long-term access, capable of receiving and executing arbitrary commands later. The attacker decides what the malware does after it's deployed across your infrastructure.
How to Detect Installed Malicious Packages
Check your dependency trees for packages in the @asyncapi namespace published during the attack window. But detection after installation is your backup plan, not your primary defense.
For runtime detection, look for:
- Unexpected IPFS connections in your network logs
- Node processes with unusual persistence mechanisms
- New scheduled tasks or systemd services you didn't create
- Outbound connections to command-and-control infrastructure
Set up dependency scanning that alerts on new package versions before they're installed, not after. Tools like Dependabot or Renovate can flag updates for manual review, letting you verify legitimacy before the package enters your environment.
What Should You Implement Immediately?
Here are three changes you can make this week:
First, enable GitHub's required workflows feature for security-critical repositories. Create a centralized security workflow that runs on every PR and can't be bypassed by repository-level workflow changes.
Second, implement workflow approval gates. Require manual approval before workflows can run on pull requests from forks or on workflow_dispatch triggers. GitHub lets you configure this under repository settings.
Third, audit your OIDC trust relationships. If you're using GitHub Actions to publish to npm, PyPI, or container registries, verify that your trust policies restrict which workflows and which branches can authenticate. Don't trust every workflow in the repository equally.
Where to Go for More
GitHub's security hardening guide for Actions covers workflow permissions and approval gates in detail. The SLSA framework documentation explains provenance levels and their limitations. For npm-specific guidance, review npm's documentation on provenance attestations and what they actually verify.
The AsyncAPI incident report from OX Security includes indicators of compromise and technical details about the malware's behavior. If you're running AsyncAPI packages, start there.
The broader lesson isn't about AsyncAPI specifically. It's about recognizing that your CI/CD pipeline is now a primary attack target, and the security controls you've built around it need to assume that workflow files themselves are untrusted input.
