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
Malicious npm Packages Deploy Multi-Stage Trojan with Embedded GitLab Keys
Positive Technologies researchers uncovered a campaign in which an attacker published multiple trojanized packages to the npm registry under the accounts alex05255, mdrafiqulislamrabby, b.w1001, abdev8773 and mollspotwood54400. The affected packages include svg-fetcher, tradepilot, polytrade, polymarket-kit, react-svg-chunk, gamified-trading-system, font-huge, font-hub, mdb-vite, router-processor and route-processor. Each package concatenates several constants to build a C2 URL, downloads the next stage identified as token versions 106, 107, 108 and 116, and sends the hardcoded value logo in the bearrtoken header. Later stages contain heavily obfuscated JavaScript that collects username, hostname and operating-system information before establishing a WebSocket channel for command execution. Releases 106 and 116 also embed a public-private key pair belonging to a private GitLab instance operated by the threat actor, suggesting the use of CI/CD pipelines for code obfuscation and stage generation. The findings highlight the continued risk of supply-chain attacks through popular open-source repositories and the value of automated package monitoring.
How to Audit All Python Virtual Environments for Compromised Packages Without Executing Python
The article describes a practical workflow for discovering whether any Python virtual environments contain known malicious package versions. The author maintains a registry of all .venv directories across local disks and external volumes using find commands and shell hooks. A Bash script then iterates through the registry and runs uv pip freeze against each environment to list installed dependencies without invoking the Python interpreter. This approach avoids risks highlighted by recent supply-chain attacks on packages such as LiteLLM, where even python -V or pip freeze could trigger malicious .pth files. The method also supports locating outdated packages, identifying usage of deprecated libraries, and searching project code for specific functions. Configuration settings like PIP_REQUIRE_VIRTUALENV=true and the uv tool further prevent accidental global installations.
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.