dYdX Hit by Third Supply-Chain Attack: Compromised npm and PyPI…

DeFi protocol with $1.5T cumulative volume compromised on npm and PyPI. Wallet stealer and remote access trojan distributed via maintainer account. Incident reignites debate over mandatory MFA for package publishing.

The official @dydxprotocol/v4-client-js packages on npm and dydx-v4-client on PyPI have been compromised to distribute malware: a wallet stealer on both ecosystems, with a Remote Access Trojan added to the PyPI payload. Socket, an open-source supply-chain security vendor, detected the anomaly on January 27, 2026 and notified dYdX the following day at 12:19 UTC. This is the third incident targeting the protocol's distribution infrastructure since 2022, this time featuring cross-ecosystem escalation and remote persistence.

Key Takeaways

Compromised npm versions: 3.4.1, 1.22.1, 1.15.2, 1.0.31; payload exfiltrates seed phrase and device fingerprint during normal package usage
PyPI payload includes wallet stealer + RAT with C2 at dydx.priceoracle[.]site, 100-iteration reverse→base64→zlib obfuscation, and hardcoded token for command authentication
Attacker injected malicious code into core registry.ts/registry.js files (npm) and account.py/config.py/_bootstrap.py (PyPI), demonstrating intimate knowledge of package internals
dYdX confirmed the incident on X and recommended isolating machines, moving funds, rotating API keys; versions on the official GitHub repository do not contain malware

The Mechanism: Malware in the Package Core, Not in Dependencies

The attack did not exploit technical vulnerabilities in the npm or PyPI registries. Instead, it originated from a legitimate maintainer account, according to Socket and The Hacker News. The exact compromise vector — phishing, credential stuffing, MFA bypass, or insider — remains unconfirmed by dYdX at time of publication.

Socket security researcher Kush Pandya noted that the attacker "demonstrated detailed knowledge of the package internals, inserting malicious code into core registry files (registry.ts, registry.js, account.py) that would execute during normal package usage." The malware activates in the standard operational flow: when a developer calls createRegistry() passing a seed phrase, it is exfiltrated along with a device fingerprint.

On PyPI the complexity is higher. The RAT payload is protected by 100 iterations of deobfuscation: string reversal, base64 decoding, zlib decompression with wbits=47. The encoded blob measures 5,527 characters. Once deobfuscated, the RAT contacts the domain dydx.priceoracle[.]site — a typosquat of dydx.xyz — to receive commands for execution in an isolated subprocess. The hardcoded authentication token is 490CD9DAD3FAE1F59521C27A96B32F5D677DD41BF1F706A0BF85E69CA6EBFE75. An exposed API key, dydx1gh6fj28w37rykqu6szgp9q0rzejslmj0umk55c, directly links the attack infrastructure to the dYdX brand.

The cross-device fingerprinting computes a SHA-256 hash concatenating the MAC address and /etc/machine-id, allowing the attacker to track the same victim across multiple installations.

"The 100-iteration obfuscation in the PyPI version and the coordinated cross-ecosystem deployment suggest the threat actor had direct access to publishing infrastructure rather than exploiting a technical vulnerability in the registries themselves" — Kush Pandya, Socket

Cross-Ecosystem Differentiation: Same Actor, Adaptive Strategy

Socket's analysis highlights deliberate design: "The nearly identical credential theft implementations across languages indicate deliberate planning. The threat actor maintained consistent exfiltration endpoints, API keys, and device fingerprinting logic while deploying ecosystem-specific attack vectors."

On npm the objective is immediate seed-phrase theft — critical data for non-custodial crypto wallets. On PyPI, remote persistence is added: the RAT enables arbitrary code execution post-infiltration, opening scenarios for lateral movement, modification of trading strategies, or compromise of backend infrastructure. Socket's threat research team specified that "Applications that use these packages in custodial contexts such as trading bots, automated strategies, or backend services that directly handle mnemonics or private keys for signing, are high-value targets for credential theft."

dYdX's cumulative lifetime trading volume is approximately $1.5 trillion, with a daily average of $200–540 million, open interest of roughly $175 million, and over 70,700 token holders. Every downstream integrator — market makers, trading bots, DeFi aggregators — represents an attack surface with direct financial exposure.

The Recurring Pattern: 2022, 2024, 2026

This is not the first episode. In September 2022, dYdX npm staff accounts were hijacked to compromise the @dydxprotocol/solo and @dydxprotocol/perpetual packages, as documented by BleepingComputer. In July 2024, a DNS hijacking hit the v3 exchange. Now, in January 2026, the escalation moves from a single npm ecosystem to coordinated npm + PyPI, with the addition of a RAT.

The triennial recurrence with different mechanisms — account hijack in 2022, DNS in 2024, cross-ecosystem maintainer account in 2026 — suggests systematic targeting of the dYdX ecosystem rather than generic opportunistic attacks. The striking datum: despite three incidents, publishing to npm and PyPI still occurs without verified mandatory MFA or automated consistency checks between the GitHub repository and published artifacts. Socket detected the malicious package within "minutes" of publication, but the takedown time is not quantified in the dossier.

Immediate Actions

Isolate machines that installed the compromised versions: dYdX explicitly recommended this step on X, given the PyPI RAT's remote execution capability
Move funds from wallets whose seed phrases were passed to createRegistry(): direct seed exposure equals total wallet compromise, not mitigable by rotation
Rotate API keys potentially entered in configurations that used the infected packages, given the cross-device tracking implemented by the attacker
Verify installation integrity by comparing hashes of registry.ts, registry.js, account.py, config.py, and _bootstrap.py files against versions on the official dydxprotocol GitHub — explicitly confirmed uncompromised

Why This Case Exposes a Structural Gap

The problem is not dYdX-specific, but dYdX embodies it brutally: a protocol with billions in volume manages its open-source supply chain with controls that a single compromised maintainer account can bypass. The absence of mandatory MFA on publishing infrastructure, automated artifact signing, and pre-publication scanning of core files — not just dependencies — is a design vulnerability, not an implementation flaw.

The use of 100-iteration obfuscation and typosquatting of known domains indicates the attacker invested in anti-analysis and visual credibility, not just delivery. The payload is not crude: it is built to resist rapid static scanning and to blend into legitimate traffic toward dydx-branded endpoints. This level of craft, combined with intimate package knowledge, separates the incident from a generic opportunistic credential compromise.

dYdX has not reported quantified losses or identified victims, but does not rule out individual compromises. The dossier does not specify whether the C2 domain has been seized or remains active. The attacker's identity and the exact download count of the infected packages remain unknown.

FAQ

Is the malware in the official GitHub repositories?
No. dYdX and Socket have explicitly confirmed that the source code on GitHub does not contain the malicious payload; the compromise occurred at the npm/PyPI publishing level.

Is it the same attacker as 2022?
No infrastructure overlaps link the 2026 actor to the 2022 incident; they are separate events with distinct techniques and timelines.

Could I have installed the package unknowingly?
Only if you explicitly updated or installed @dydxprotocol/v4-client-js versions 3.4.1, 1.22.1, 1.15.2, 1.0.31, or dydx-v4-client from PyPI during the exposure window. It is not an automatic transitive dependency of generic systems.

Information verified against cited sources and current as of publication.

Sources

Sources and references