# dYdX v4-client npm + PyPI compromise (wallet stealer + RAT)

> Maintainer credentials for the dYdX decentralized exchange were compromised; malicious versions of the official v4 client were pushed to npm and PyPI in a coordinated release. The npm payload exfiltrates wallet seed phrases through a malicious `createRegistry()` function. The PyPI variant additionally drops a Python RAT executed on import.

- Published: 2026-01-27
- Severity: critical
- Kind: Compromise - A legitimate, already-used package, maintainer account, CI pipeline, or release tag was hijacked and a malicious version was published under a name people already depend on.
- Ecosystems: npm, PyPI
- Scope: 2 packages, 6 compromised versions
- Tags: maintainer-takeover, crypto-wallet-drain, credential-theft, account-takeover
- Detected by: Socket
- Incident ID: multi-2026-01-27-dydx-compromise

## Affected packages (2)

Only the exact versions listed were named by the source advisories. Other versions are not implicated.

| Package | Ecosystem | Compromised versions |
|---|---|---|
| [@dydxprotocol/v4-client-js](https://dependencywatch.io/package/npm/@dydxprotocol/v4-client-js) | npm | 1.0.31, 1.15.2, 1.22.1, 3.4.1 |
| [dydx-v4-client](https://dependencywatch.io/package/pypi/dydx-v4-client) | PyPI | 1.1.5.post1, 1.1.5post1 |

## What happened

On January 27, 2026, maintainer credentials for the official dYdX v4 client libraries were compromised. The attacker pushed coordinated malicious releases to both npm (`@dydxprotocol/v4-client-js`) and PyPI (`dydx-v4-client`) within a short window - the kind of cross-ecosystem timing that only works if the attacker is sitting on real publishing rights, not running a typosquat.

The npm payload is centred on a malicious `createRegistry()` helper that hooks the wallet flow and exfiltrates any seed phrase passed through dYdX SDK calls. The PyPI variant carries the same wallet-stealing logic plus a Python RAT triggered at import time, so simply running `pip install` on a dependency tree that resolves the bad version is enough.

Obfuscation density on both payloads is significantly higher than typical typosquat malware, which matches the publishing-account-takeover hypothesis. Socket linked the deobfuscated control flow back to the same operator infrastructure observed in earlier 2025 wallet-drainer campaigns.

If you maintain a downstream dYdX integration, treat any host that built against the malicious versions as compromised for crypto assets: transfer funds from a clean device first, then rotate API keys handled on that workstation.

## Impact

- Cryptocurrency wallet seed-phrase theft from any downstream dYdX integrator
- Remote command execution on Python hosts importing the package
- High-iteration obfuscation suggests publishing-infrastructure access, not typosquat

## What to do

1. Isolate any machine that installed the malicious versions; transfer crypto from a clean device
2. Rotate API keys and credentials handled on the affected developer workstation
3. Reinstall only from versions verified against the official dYdX GitHub repository

## Check your own dependencies

- Check a package-lock.json against this incident: https://dependencywatch.io/check/package-lock-json
- Check a requirements.txt against this incident: https://dependencywatch.io/check/requirements-txt

The scan runs entirely in the browser; lockfile contents are never uploaded.

## References

- [Socket: Malicious dYdX packages on npm + PyPI](https://socket.dev/blog/malicious-dydx-packages-published-to-npm-and-pypi) - Socket

---

Canonical page: https://dependencywatch.io/incident/multi-2026-01-27-dydx-compromise
Markdown version: https://dependencywatch.io/incident/multi-2026-01-27-dydx-compromise.md
Site index for agents: https://dependencywatch.io/llms.txt
DependencyWatch.io is operated by Precursor Security (https://precursorsecurity.com).