# Miasma Supply Chain Attack Expands to 24+ npm Packages and GitHub Actions Infrastructure


Cybersecurity researchers have identified a significant new wave of supply chain attacks leveraging compromised npm packages and GitHub Actions infrastructure. The campaign, linked to the established Miasma/Mini Shai-Hulud malware family, has compromised at least 24 npm packages and a Go module, with the ultimate goal of harvesting developer credentials and establishing persistence in trusted CI/CD pipelines.


## The Threat


Security researchers at Socket detected malicious releases across a coordinated set of npm packages primarily targeting the LeoPlatform and RStreams ecosystems. The latest wave demonstrates an evolution in sophistication—combining traditional supply chain poisoning techniques with advanced GitHub Actions exploitation and OIDC token theft.


The affected npm packages include:


| Package Name | Version | Ecosystem |

|---|---|---|

| leo-auth | 4.0.6 | npm |

| leo-sdk | 6.0.19 | npm |

| leo-cli | 3.0.3 | npm |

| leo-connector-elasticsearch | 2.0.6 | npm |

| leo-connector-mongo | 3.0.8 | npm |

| rstreams-metrics | 2.0.2 | npm |

| serverless-leo | 3.0.14 | npm |

| github.com/verana-labs/verana-blockchain | v0.10.1-dev.20 | Go |


An additional 21 packages across both registries were compromised. Beyond npm, the attack has propagated to the Go ecosystem, indicating the threat actors' capability and intent to maintain cross-platform persistence.


## Background and Context


The Miasma malware family—also associated with the Mini Shai-Hulud and Hades variants—has been evolving since early 2024. This latest campaign represents a maturation of tactics previously documented in earlier supply chain attacks.


Initial Compromise Vector: Researchers believe the attack began with a compromised npm maintainer account associated with LeoPlatform. The account belonging to developer "czirker" was likely breached through leaked credentials, enabling attackers to gain direct access to the npm registry. Critically, the threat actors exploited a 6-second window to push malicious versions before detection—a window that suggests advance preparation and knowledge of publishing workflows.


This incident aligns with a broader pattern of targeting developer infrastructure at its weakest points: compromised credentials, unmonitored CI/CD systems, and the inherent trust placed in packages from established maintainers.


## Technical Details: Attack Chain and Methodology


Unlike typical npm supply chain attacks that rely on package.json lifecycle hooks, this campaign employs a more sophisticated evasion approach using the binding.gyp file—a native module compilation configuration file that many security tools overlook.


### Installation-Time Execution


When developers install the malicious packages, the binding.gyp file triggers arbitrary code execution during the npm install phase, before any application code runs. This is particularly dangerous because:


  • Installation occurs in CI/CD pipelines with access to environment secrets
  • It executes with the same privileges as the developer or runner
  • Many static analysis tools do not inspect binding.gyp files for malicious code

    • ### Payload Delivery: Bun Runtime and JavaScript Stealer


    The injected code performs the following actions:


    1. Downloads and installs the Bun JavaScript runtime (if not already present)

    2. Executes a JavaScript malware loader embedded within the package

    3. Activates a credential harvesting stealer targeting:

    - GitHub Personal Access Tokens (PATs)

    - GitHub OIDC tokens from CI/CD environment memory

    - AWS credentials

    - API keys and secrets exposed in environment variables

    - IDE and AI assistant authentication tokens (e.g., GitHub Copilot credentials)


    ### Anti-Detection Features


    The malware includes defensive mechanisms:

  • Russian locale killswitch (disables payload if system locale is Russian)
  • Endpoint detection and response (EDR) checks to avoid execution in monitored environments
  • Encrypted exfiltration using AES-128-GCM for credential transmission
  • GitHub dead-drop infrastructure for command & control

    • ### GitHub Actions Exploitation


    A particularly insidious tactic involves injecting a malicious workflow file named "Run Copilot" into compromised repositories. This workflow:


  • Captures secrets from the GitHub Actions runner memory
  • Exfiltrates them to a public GitHub repository with the description "Alright Lets See If This Works" (559 repositories matched this pattern at time of discovery)
  • Uses token relay markers like "RevokeAndItGoesKaboom" to coordinate with command & control infrastructure

    • ### Connection to semantic-release-action Compromise


    Researchers at StepSecurity linked this campaign to a recent compromise of the popular codfish/semantic-release-action GitHub Action. On June 24, 2026, at 15:39:06 UTC, an attacker force-pushed malicious commits and redirected version tags to the malicious code. Any workflow referencing those tags after that timestamp executed the attacker's payload directly in the GitHub Actions runner. The use of identical token relay markers ("RevokeAndItGoesKaboom") across both attacks confirms they are operated by the same threat actor or tooling lineage.


    ## Implications: The Scale and Severity


    ### Developer and Enterprise Risk


    The scope of this attack extends far beyond the immediate package consumers. Because LeoPlatform and RStreams packages are dependencies in larger applications, the blast radius is potentially massive:


  • Development environments are compromised, exposing developer credentials
  • CI/CD pipelines leak GitHub tokens, AWS credentials, and deploy keys
  • Stolen credentials are weaponized to propagate the malware to additional repositories
  • Compromised OIDC tokens can be used to impersonate actions and push code to other repositories

    • The attackers achieve persistent, authenticated access to developer infrastructure—the holy grail of supply chain attacks.


    ### Cross-Ecosystem Propagation


    The presence of compromised Go modules (Verana Blockchain) alongside npm packages indicates the threat actors are intentionally expanding across ecosystems, suggesting this is a campaign with significant resources and operational capability.


    ## Recommendations for Defenders


    ### For Developers and Teams


  • Audit installed dependencies immediately against the list of affected packages
  • Rotate all credentials that may have been exposed (GitHub PATs, AWS keys, npm tokens)
  • Review GitHub Actions workflows for suspicious "Run Copilot" jobs or other unexpected workflows
  • Check git logs for unexpected commits or force-pushes in the past 72 hours
  • Verify GitHub Action versions used in your workflows; ensure they reference specific commit SHAs, not tags that may have been redirected

    • ### For npm and Go Module Maintainers


  • Enable two-factor authentication on all registry accounts
  • Use npm publish tokens scoped to specific packages, not global tokens
  • Monitor publishing activity via webhook alerts and audit logs
  • Configure branch protection rules to require reviews and enforce signed commits
  • Implement SBOM (Software Bill of Materials) generation and monitoring for supply chain visibility

    • ### For Organizations


  • Implement package pinning in production: lock dependencies to specific, verified versions rather than floating tags
  • Use software composition analysis (SCA) tools configured to detect behavioral anomalies in packages (unusual network calls, credential access)
  • Monitor GitHub OIDC token usage in workflows and correlate with unexpected code deployments
  • Establish a supply chain security program that includes:

    • - Regular audits of critical dependencies

    - Vendor assessments based on security maturity

    - Incident response playbooks for compromised dependencies

  • Consider namespace isolation in CI/CD: run install steps with minimal environment variable exposure

    • ---


    ## HackWire Analysis


    This attack represents a watershed moment in supply chain security: the threat actors have evolved from simple credential theft to full operational infrastructure compromise. Previous campaigns relied on stealing credentials, but this iteration demonstrates that owning the developer's credentials is just the entry point—the real payload is automated propagation and CI/CD infiltration.


    The use of binding.gyp and Bun runtime evasion is particularly alarming because it shows attackers are actively circumventing the detection strategies that worked against earlier campaigns. Five months ago, security teams learned to hunt for package.json hooks; now the malware has moved to compilation-phase execution that bypasses those detections entirely.


    What's also notable: the 6-second deployment window. This wasn't opportunistic—the attackers had prior knowledge of the maintainer's publishing workflow, suggesting either a long-term reconnaissance phase or compromised credentials obtained weeks or months earlier. This implies organizations may already be running versions of these packages without knowing it, as the poisoned versions were live before detection.


    The most underreported risk is OIDC token abuse. GitHub Actions now defaults to issuing OIDC tokens that can be exchanged for credentials in AWS, Google Cloud, and other platforms. A stolen OIDC token from a compromised CI/CD runner isn't just a "GitHub token"—it's a key to your entire infrastructure. The fact that this attack specifically targets OIDC harvesting suggests attackers are no longer interested in just github.com access; they're weaponizing CI/CD to reach cloud platforms.


    The connection to semantic-release-action shows this isn't isolated to any single compromised package—the operational cluster is actively hunting for and compromising popular, trusted GitHub Actions used by thousands of enterprises. If you're using GitHub Actions for deployment, assume your supply chain is in scope.


    What defenders are missing: Most incident response teams are taught to "rotate credentials after a breach." But in supply chain attacks, rotation is insufficient. The attacker still owns the npm account, the GitHub repository, or the Action. Defenders need to assume that *any package downloaded in the last 72 hours from these registries is potentially malicious* and should be quarantined, analyzed, and replaced with builds from source.


    — HackWire Editorial


    ---


    ## Related Coverage


  • Read more in our [Breaches](https://www.hackwire.news/category/breaches) coverage
  • Cross-reference with [Vulnerabilities](https://www.hackwire.news/category/vulnerabilities) and [Malware](https://www.hackwire.news/category/malware)
  • Stay current via the [HackWire homepage](https://www.hackwire.news/)