When a trusted npm package becomes a delivery mechanism for credential-stealing malware, the blast radius extends far beyond the developer's laptop. Recent analysis of the Miasma campaign demonstrates a sophisticated approach to npm package compromise that should concern anyone operating production infrastructure, particularly those running containerised workloads or complex CI/CD pipelines.
How the Attack Chain Works
The Miasma campaign targeted @redhat-cloud-services packages, leveraging the install-time execution window that npm provides. Rather than hiding malicious logic in obfuscated runtime code, the attack executes during package installation—a moment when developers and CI/CD systems typically trust the process implicitly.
The payload performs credential harvesting, scanning for secrets stored in environment variables, shell configuration files, and SSH keys. On systems running continuous integration pipelines, this means access to database credentials, API tokens, cloud provider access keys, and deployment certificates. A self-propagating worm component then attempts to replicate itself across other packages or systems within the same network.
What distinguishes this approach is its explicit targeting of CI/CD infrastructure. Build systems often run with elevated privileges and store secrets in environment variables for legitimate build and deployment tasks. Compromising a single npm package can thus grant an attacker access to your entire deployment pipeline.
The Broader Supply Chain Risk
npm's dependency model means that compromising a single package can affect thousands of dependent projects immediately. The Red Hat packages in question are infrastructure-focused, suggesting the attackers were specifically hunting credentials used in enterprise deployments. A worm component escalates the threat: once installed, it can attempt lateral movement through shared network resources or propagate to other dependency resolution tools.
This attack pattern differs from straightforward code injection because it operates at the installation phase rather than runtime. Many security scanning tools focus on analysing executed code; they may miss or deprioritise install-time scripts, particularly if those scripts appear to perform innocuous setup tasks.
Defensive Measures for Infrastructure Teams
Organisations running Node-based services should consider several mitigations:
- Isolate CI/CD environments. Run build processes in containers or virtual machines without network access to production systems. Credential compromise in an isolated build environment has limited blast radius.
- Minimise secret exposure. Rather than storing credentials in environment variables that scripts can read, use temporary credential injection or short-lived tokens. Vault systems (HashiCorp Vault, AWS Secrets Manager, cloud-native equivalents) reduce the window of exposure.
- Audit npm install scripts. Review and audit the
postinstallandpreinstallscripts in your dependency tree. Tools likenpm audithave improved, but manual inspection of high-risk dependencies remains valuable. - Use lock files and vendoring. Pin exact versions and commit lock files to version control. Consider vendoring dependencies in critical infrastructure to reduce runtime package resolution.
- Monitor installation activity. Log all npm installations in CI/CD pipelines. Unexpected network connections, file access patterns, or credential references during install-time execution warrant investigation.
- Scan packages before deployment. Use Software Composition Analysis (SCA) tools that inspect install scripts, not just runtime code.
The Broader Picture
Supply chain attacks like Miasma reveal a fundamental asymmetry: developers use open-source packages for efficiency, but defending against malicious packages requires active, continuous effort. The attack surface isn't limited to npm; similar risks exist across PyPI, RubyGems, Maven, and container registries.
For organisations hosting critical infrastructure or running complex CI/CD pipelines, the lesson is clear: trust in external packages must be paired with strict isolation, credential management, and monitoring. A single compromised dependency should not grant unfettered access to your deployment secrets or production systems. Treating your build pipeline as a high-security perimeter—rather than an internal-only system where shortcuts are acceptable—has become essential practice.
