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
Supply Chain Attack Targets Arch Linux Community Repository
Arch Linux has temporarily suspended package adoptions in the Arch User Repository after detecting accounts taking over abandoned projects to insert malicious code. The platform later expanded the restriction by blocking all new submissions to the AUR to contain ongoing supply chain attacks. Attackers were adopting packages without active maintainers and introducing harmful changes through subsequent commits that could bypass user scrutiny due to established project history. Newly created packages containing malicious build commands, including requests for elevated privileges, were also discovered. Affected accounts have been banned and identified projects removed from the repository. The incident does not impact official Arch Linux repositories, with risk limited to community-maintained AUR packages that require manual review of PKGBUILD files before installation or updates.
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.