npm Package Hijack Drains Crypto Wallets

On December 20, 2024, attackers compromised the GitHub repository for Injective Labs' SDK and published a malicious npm package designed to steal cryptocurrency wallet private keys. The malicious version (v1.14.1-alpha.11) was downloaded 310 times before security researchers flagged it and npm deprecated the package. Any developer who pulled this version during the active window potentially exposed their users' wallet credentials to the attackers.

Attack Timeline

The attack window was brief but effective:

• December 20, 2024: Attackers gained access to Injective Labs' GitHub repository.
• Same day: Malicious package v1.14.1-alpha.11 published to npm.
• Within hours: Socket's automated scanning detected the malicious payload.
• Shortly after: Ox Security confirmed the findings.
• Same day: npm deprecated the package.

The 310 downloads occurred before deprecation. Given that the @injectivelabs/sdk package has 87 direct dependencies and over 112,000 cumulative downloads, the downstream exposure risk extended far beyond those 310 direct installations.

Failed Controls

This breach succeeded because multiple defensive layers either didn't exist or weren't enforced:

Repository Access Controls: The attackers obtained credentials sufficient to push code to the main repository. This suggests missing or inadequate controls around:

• Enforcing multi-factor authentication on maintainer accounts.
• Implementing branch protection rules requiring review before merge.
• Verifying commit signing.

Package Publishing Controls: Once the malicious code reached GitHub, it flowed directly to npm without human review. The automated publish pipeline lacked:

• A secondary approval gate before npm publication.
• Automated security scanning as a blocking step in CI/CD.
• Anomaly detection for unusual package versions (the "-alpha.11" suffix should have triggered review).

Runtime Integrity Verification: Downstream consumers had no mechanism to verify package integrity before execution. Most developers trust npm's namespace authentication implicitly.

Compliance Standards

PCI DSS v4.0.1 Requirement 6.3.2 mandates that custom software be developed securely according to industry standards. For organizations processing payment data, this includes:

• Code reviews before production deployment.
• Separation of duties between development and deployment.
• Automated security testing in the build pipeline.

NIST 800-53 Rev 5 Control SA-10 (Developer Configuration Management) requires organizations to perform configuration management during system development, including tracking security flaws and verifying the integrity of software before deployment.

ISO/IEC 27001:2022 Control 8.31 (Separation of Development, Test and Production Environments) requires controls to separate and protect different environments. Publishing directly from repository push to production npm violates this separation.

OWASP ASVS v4.0.3 Section 14.2 (Dependency) requires verification that components come from trusted sources using trusted channels, and that you maintain an inventory of all components. The automated trust relationship between GitHub and npm created a single point of failure.

Lessons and Action Items

1. Treat Your Repository as Production Infrastructure

Your GitHub organization needs the same access controls you apply to production systems:

• Enable mandatory MFA for all maintainers.
• Require signed commits using GPG keys.
• Set branch protection to require at least two approvals for main branch merges.
• Audit repository access quarterly and remove stale credentials.

If you're using GitHub Actions to publish packages, store npm tokens in GitHub Secrets with environment protection rules. Configure your workflow to require manual approval before publishing to npm.

2. Break the Automated Publishing Chain

Insert a human checkpoint between code merge and package publication:

• Separate your CI (continuous integration) from your CD (continuous deployment).
• Require a manual approval step before npm publish runs.
• Use a dedicated service account for npm publishing with minimal permissions.
• Implement a waiting period (even 15 minutes) between merge and publish to allow automated scanning to complete.

Socket detected this package within hours. If Injective Labs had configured their pipeline to wait for scan results before publishing, the malicious package might never have reached npm.

3. Deploy Supply Chain Scanning as a Blocker

Tools like Socket, Snyk, or GitHub's Dependabot can detect suspicious package behavior. Configure them as required checks:

# Example: GitHub Actions workflow
- name: Security scan
  run: npx socket security check
  # Don't use continue-on-error
  # Let the build fail if threats are detected

Set up alerts to page your security team when new packages appear in your dependency tree, especially for packages with:

• Newly created maintainer accounts.
• Pre-release or alpha versions.
• Network access in install scripts.
• Obfuscated code.

4. Verify Package Integrity in Your Environment

Even if you don't maintain packages, you consume them. Add verification steps:

• Pin exact versions in package.json (not version ranges).
• Use lock files (package-lock.json, yarn.lock) and commit them.
• Run npm audit in your CI pipeline and fail builds on high-severity findings.
• Consider using a private npm registry that mirrors and scans public packages before making them available internally.

For critical dependencies like cryptocurrency wallet libraries, verify checksums against known-good values before deployment.

5. Build an Incident Response Runbook for Supply Chain Compromises

When a dependency is compromised, you need to move fast:

• Document which teams own which dependencies.
• Maintain a current inventory of all direct and transitive dependencies (OWASP ASVS 14.2.1).
• Create a process to identify which systems pulled a compromised package version.
• Establish a communication plan to notify affected users.

In this incident, the 310 downloads represent 310 potential wallet compromises. If you were one of those downloaders, your response time determines whether credentials get rotated before attackers use them.

The Injective Labs breach shows that supply chain security isn't just about scanning for known vulnerabilities. It's about controlling the entire path from source code to production deployment, with verification at each step. The attackers didn't exploit a zero-day. They exploited the trust relationship between GitHub and npm, and the assumption that published packages are safe because they come from a legitimate namespace.