Miasma Worm Leak: When GitHub Became the Distribution Channel

What Happened

The Miasma worm's source code was deliberately distributed on GitHub through compromised developer accounts. Unlike accidental exposures or proof-of-concept leaks, this was a targeted attempt to infiltrate open-source supply chains with production malware.

Miasma is an evolution of the Shai-Hulud worm, designed to steal credentials while using GitHub as its infrastructure. It avoids detection by eliminating command-and-control servers and suspicious network traffic. The build pipeline employs AES-256-GCM encryption and randomized obfuscation, complicating static analysis. SafeDep reported the leak and analyzed the code before GitHub removed the repositories.

The implications are significant: threat actors now have a template for supply-chain attacks that bypass traditional network-based detection.

Timeline

While details are limited, the sequence of events is clear:

1. Initial compromise: Attackers accessed multiple legitimate developer accounts on GitHub.
2. Source code publication: Miasma code appeared across these compromised accounts.
3. Detection: SafeDep identified and reported the leak.
4. Removal: GitHub took down the repositories.
5. Current state: The code is now in the wild, available to anyone who accessed it during the exposure window.

Unknowns include how long the code was accessible, how many actors downloaded it, and whether any forks survived the takedown.

Which Controls Failed or Were Missing

This incident highlights failures across several control areas:

Access Control Failures

The attackers compromised multiple developer accounts, indicating:

• Weak or reused passwords
• Missing or bypassable multi-factor authentication
• Lack of anomalous activity detection
• Insufficient session management

Code Review and Approval Gaps

The malware appeared without triggering reviews:

• No mandatory code review for new repositories or significant commits
• Missing automated security scanning at commit time
• No peer review requirement for publishing packages
• Ineffective branch protection rules

Dependency Management Weaknesses

Organizations consuming packages from these accounts lacked:

• Dependency pinning to specific, verified versions
• Automated scanning of new dependencies before integration
• Allowlisting of trusted package sources
• Delayed adoption policies for new packages or major version bumps

Detection and Response Delays

The leak persisted long enough for external discovery:

• No real-time monitoring of package publications
• Missing anomaly detection for unusual repository creation patterns
• Slow incident response to flagged suspicious activity
• No automated takedown procedures for compromised accounts

What the Standards Require

ISO/IEC 27001:2022 addresses several of these failures:

Annex A 5.15 (Access Control) requires organizations to control access based on business needs. For developer accounts with package publishing rights:

• Multi-factor authentication must be mandatory
• Apply the principle of least privilege for publishing permissions
• Conduct regular access reviews to remove unnecessary privileges

Annex A 8.23 (Web Filtering) and 8.16 (Monitoring Activities) require monitoring and logging:

• Log all package publications with author, timestamp, and change delta
• Alert on first-time package publications from an account
• Monitor for unusual commit patterns or repository creation spikes

NIST CSF v2.0 provides a framework for supply-chain risk:

PR.DS-6 addresses integrity checking mechanisms:

• Verify package signatures before installation
• Use hash verification for all downloaded dependencies
• Implement Software Bill of Materials (SBOM) tracking

DE.CM-4 requires detecting malicious code in your dependency pipeline:

• Scan every new package version with multiple engines
• Block packages with known malware signatures
• Quarantine dependencies that fail behavioral analysis

PCI DSS v4.0.1 (for organizations handling payment data) includes:

Requirement 6.3.2 mandates that custom code be reviewed before release. Extended to dependencies:

• Review source code of critical dependencies when feasible
• Require security assessments for packages with elevated privileges
• Document the security posture of each third-party component

Requirement 11.6.1 requires detecting changes to HTTP headers and payment pages. Applied to your build pipeline:

• Detect unauthorized changes to build configurations
• Alert on new dependencies introduced without approval
• Monitor for modifications to package-lock files

Lessons and Action Items for Your Team

Immediate Actions (This Week)

1. Audit your GitHub organization settings

   • Enforce MFA for all members with write access
   • Enable branch protection on all repositories
   • Require signed commits for package publishing
   • Review and revoke unused personal access tokens

2. Implement dependency pinning

   • Lock all dependencies to specific versions with hash verification
   • Document why each dependency is necessary
   • Remove unused dependencies from your package manifests

3. Deploy automated scanning

   • Add pre-commit hooks that scan for secrets and malware signatures
   • Configure your CI/CD to fail builds with unapproved dependencies
   • Enable GitHub's Dependabot alerts (or equivalent for your platform)

Short-Term Improvements (This Month)

4. Establish a delayed adoption policy

   • Wait 7-14 days before adopting new package versions
   • Monitor security advisories during the waiting period
   • Require security team approval for major version bumps

5. Create an allowlist of trusted sources

   • Identify which package registries your team uses
   • Block installations from unverified sources
   • Document the security review process for adding new sources

6. Implement behavioral monitoring

   • Log all package installations with timestamps and requestors
   • Alert on installations from new or recently created packages
   • Track changes to your dependency graph over time

Long-Term Strategy (This Quarter)

7. Build internal package mirroring

   • Host a private registry for vetted packages
   • Scan packages before adding them to your mirror
   • Control exactly which versions your teams can access

8. Develop an SBOM practice

   • Generate SBOMs for all applications
   • Track dependency relationships and update patterns
   • Use SBOMs to identify blast radius when vulnerabilities emerge

9. Train developers on supply-chain risks

   • Explain how Miasma-style attacks work
   • Show them how to verify package authenticity
   • Make security part of your code review culture

The Miasma leak demonstrates that GitHub is infrastructure—not just a collaboration tool. Treat access to your organization's repositories with the same rigor you apply to production systems. The next supply-chain attack won't announce itself. It'll look like a normal dependency update until credentials start flowing to an attacker's repository.