What Happened
On July 8, 2026, a threat actor published version 1.20.21 of @injectivelabs/sdk-ts to npm. The package contained code to steal cryptocurrency wallet private keys. Within 24 hours, the attacker pushed identical malicious payloads to 17 more @injectivelabs scoped packages.
The attack didn't exploit a vulnerability in npm's infrastructure. Instead, the threat actor used a compromised developer account with publish permissions. Because Injective Labs used GitHub's trusted publisher workflow, the malicious commits triggered automatic package publication to npm without additional human review.
Socket's analysis identified the exfiltration mechanism: the malicious code intercepted wallet initialization functions and transmitted private keys to an attacker-controlled endpoint.
Timeline
July 8, 2026, ~00:00 UTC: Threat actor gains access to developer account with npm publish permissions.
July 8, 2026, morning: Version 1.20.21 of @injectivelabs/sdk-ts published to npm via trusted publisher pipeline.
July 8, 2026, afternoon: Attacker publishes malicious versions across 17 additional @injectivelabs packages.
July 8, 2026, evening: Socket detects anomalous package behavior and alerts Injective Labs.
July 9, 2026: Injective Labs confirms compromise, revokes affected versions, rotates credentials.
Which Controls Failed
Access control: The compromised account had direct publish permissions to production package registries. There was no separation between development access and production release authority.
Change validation: Trusted publisher pipelines automated the path from commit to npm publication. No human reviewed the changes before packages reached end users.
Behavioral monitoring: The attack published 18 package versions in rapid succession, a pattern that should have triggered rate-limiting or manual review.
Dependency pinning: Downstream consumers using caret (^) or tilde (~) version ranges automatically pulled the malicious release during their next install.
Secrets management: The developer account used static credentials rather than short-lived tokens with scope restrictions.
What the Standards Require
PCI DSS v4.0.1 Requirement 6.3.2 mandates that software engineering personnel don't have access to production environments. If your packages handle payment data or cryptographic keys, publish permissions constitute production access. Your CI/CD pipeline should enforce separation: developers commit code, automated systems with restricted service accounts publish packages after validation.
NIST 800-53 Rev 5 CM-3 (Configuration Change Control) requires documented approval for changes to information systems. Trusted publisher workflows satisfy the "documented" requirement through Git history, but they skip the approval gate. You need a human checkpoint between merge and release for packages that handle sensitive operations.
ISO/IEC 27001:2022 Annex A.8.32 (Change Management) requires controls to ensure changes don't introduce vulnerabilities. Automated publishing without code review fails this control. Your change management process must include security review for supply chain components, not just application code.
SOC 2 Type II CC6.1 (logical and physical access controls) applies to your package registry accounts. Using persistent credentials for publish operations violates the principle of least privilege. You need time-bound tokens with explicit scopes.
Lessons and Action Items
Separate publish authority from development access. Create dedicated service accounts for package publication. Developers get read access to npm and write access to your repository. Only your CI/CD pipeline gets publish permissions, and only after passing automated and manual gates.
Implementation: In GitHub Actions, use permissions: contents: read for most workflows. Reserve id-token: write for your release workflow, and require that workflow to run only on protected branches with required reviewers.
Add a human checkpoint to trusted publisher flows. GitHub's trusted publisher feature eliminates manual credential management, but it shouldn't eliminate human judgment. Before your release workflow publishes to npm, require manual approval from someone who didn't write the code.
Implementation: Use GitHub's environment protection rules. Create a "production" environment, require reviewers, and configure your publish job to target that environment. The workflow pauses until an approver confirms the release.
Monitor for anomalous publish patterns. Eighteen packages in 24 hours isn't normal developer behavior. Your monitoring should alert when:
- Multiple packages publish within a short time window
- Publish events occur outside business hours
- A single commit triggers releases across many packages
- Package code includes new network calls or cryptographic operations
Implementation: Socket, Snyk, or GitHub's dependency graph can detect suspicious patterns. If you're building in-house monitoring, parse npm audit logs and GitHub webhook events. Alert on statistical outliers.
Pin your dependencies with lock files. Projects that used package-lock.json or yarn.lock didn't automatically pull version 1.20.21. They stayed on their previously locked version until a developer explicitly updated.
Implementation: Commit your lock files. Configure your CI to fail if package-lock.json is missing or out of sync. Use npm ci instead of npm install in production builds.
Rotate to short-lived tokens. If you're still using npm automation tokens that don't expire, replace them with provenance-based publishing. GitHub's OIDC tokens last minutes, not years.
Implementation: In your npm account settings, revoke legacy automation tokens. In your GitHub workflow, use npm publish --provenance with the id-token: write permission. This creates a cryptographically signed link between your Git commit and the npm package.
Audit your transitive dependencies. The 17 additional compromised packages likely appeared in your dependency tree even if you didn't directly require them. You need visibility into what you're actually running.
Implementation: Run npm list @injectivelabs/sdk-ts to see if any of your dependencies pull in the compromised package. Use npm audit and third-party tools like Snyk or Socket to identify indirect dependencies with known issues.
The Injective Labs incident shows that trusted publisher pipelines solve the credential management problem but introduce a new risk: they make insider compromise more efficient. Your controls need to account for the possibility that a legitimate account is acting maliciously. Separation of duties, human review gates, and behavioral monitoring aren't optional extras. They're the difference between detecting an attack in hours versus days.
