No Hacker Genius Needed: One Login and 49 Minutes Suffice in Injective Supply Chain Attack
A seemingly ordinary update to a cryptocurrency wallet library became a sophisticated supply-chain attack that handed attackers full control over user funds in just 49 minutes. The malicious code was inserted into the official @injectivelabs/sdk-ts package for the Injective blockchain, allowing it to silently harvest recovery phrases and private keys whenever users created or imported wallets.
The compromised version 1.20.21 appeared on npm on July 8, 2026. This library, maintained by Injective Labs, is downloaded approximately 175,000 times per month and is used by decentralized applications to generate wallets, sign transactions, and interact with the Injective network. Attackers did not need to steal a publishing token; they simply gained access to the account of a long-standing trusted contributor and pushed the backdoor directly into the main branch, after which the project's automated CI/CD pipeline built and published the tainted release.
The malicious module was cleverly disguised as an anonymous statistics collector that measured key-generation speed and methods. In reality, it intercepted sensitive data inside the functions PrivateKey.fromMnemonic() and PrivateKey.fromHex(), encoded the stolen recovery phrases or private keys, and transmitted them in the X-Request-Id HTTP header to a server that mimicked a legitimate Injective infrastructure node. The code remained dormant until an application actually created or loaded a wallet, reducing the chance of early detection while ensuring high-value data was captured.
The attack did not stop at the core SDK. The same day, 17 additional Injective Labs packages were released at version 1.20.21, all depending on the compromised library. Although these packages contained no malicious code themselves, they automatically pulled in the dangerous dependency. Security firm OX Security identified 87 third-party packages that transitively depended on the affected components.
Developers detected the intrusion and published a clean version 1.20.23 within 49 minutes. Nevertheless, Socket recorded at least 310 downloads of the malicious release, and cached copies may still exist in intermediate registries, CI caches, or developer environments. Researchers from Datadog Security Labs, Socket, StepSecurity, and OX Security emphasize that any recovery phrase or private key processed by the tainted code must be considered fully compromised.
Users who installed any @injectivelabs package at version 1.20.21 are strongly advised to upgrade immediately to 1.20.23, audit both direct and transitive dependencies, generate fresh keys, and transfer all assets to newly created wallets that have never interacted with the compromised library.
Related articles
GitHub and PyPI Add Time-Based Defenses Against Supply Chain Attacks
GitHub and PyPI have introduced new time-based barriers to slow down supply chain attacks. Dependabot now waits a default of 72 hours before proposing version updates, while PyPI rejects new files added to releases older than 14 days. The changes target non-security version updates and attempts to poison older stable releases. Security updates remain immediate, and the cooldown can be adjusted via dependabot.yml. PyPI's restriction addresses risks from compromised tokens or CI/CD pipelines that allow malicious artifacts on past versions. The measures were implemented in July 2026 following incidents involving projects like LiteLLM and Telnyx.
GitHub and PyPI Introduce Time-Based Defenses Against Supply Chain Attacks
GitHub and PyPI have activated new time-based barriers to slow down supply chain attacks. Dependabot now waits a default of 72 hours before proposing version updates, while PyPI rejects new files added to releases older than 14 days. The changes target non-security version updates and attempts to poison older stable releases. Security updates remain immediate, and the cooldown can be adjusted via dependabot.yml. The PyPI restriction, effective since July 8 2026, addresses risks from compromised tokens or CI/CD pipelines. Both platforms aim to give the community time to detect malicious packages before widespread adoption.
Container Image Risks: Why Skipping Verification Today Breaks Your Service Tomorrow
Technical leader Nikita from Cloud.ru details four recurring container security failures observed across client environments. The article examines untracked vulnerabilities in high-privilege components such as the NVIDIA GPU operator, supply-chain compromises affecting even trusted tools like Trivy, persistent secret leakage patterns, and CI/CD pipeline exposure. Real incidents include a 2025 NVIDIA container toolkit exploit that enabled lateral movement to worker nodes and a 2026 Trivy GitHub compromise that poisoned over seventy image tags. The author stresses that pinning to image tags is insufficient and recommends full SHA256 hashes, private registries with caching, Cosign signatures validated by Kyverno or Connaisseur, and pre-commit secret scanning. Practical recommendations include automated CVE notifications and immediate patching of privileged components rather than waiting for sprint cycles.
Should Python Libraries Raise Minimum Dependency Versions to Block Vulnerable Releases?
Seth Larson of the Python Software Foundation argues that library maintainers should not automatically raise the minimum allowed version of a dependency after a vulnerability is disclosed. He states that dependency metadata exists to declare compatibility, while security decisions belong to the application owner who controls the final build. The recommendation has sparked debate in the Python community, with some maintainers supporting the separation of concerns and others viewing security constraints as part of library support obligations. CodeScoring’s analysis examines the practical impact on the ecosystem, noting that over 10,000 packages depend on urllib3 and tens of thousands more rely on numpy, requests, and pandas. The piece concludes that version bounds may incorporate security considerations only after evaluating real usage, affected versions, and downstream compatibility, but they cannot replace application-level vulnerability management with lockfiles and tools such as pip-audit.