The warning software supply chain: committed dYdX packages steal credentials and allow remote access

The security community has just identified a new incident that brings back a known but increasingly sophisticated threat: the software supply chain. Socket researchers detected that malicious versions of legitimate packages published in npm and PyPI were distributed to steal credentials from cryptomoneda wallets and, in the case of Python, even get remote access to the affected systems. You can read the technical analysis in Socket's original report here: Socket: Malicious dYdX packages published to npm and PyPI.

The compromised packages serve developers that integrate functionalities of the dYdX protocol, a decentralized platform for derivative exchange and cryptoactive operations. In npm the affected names are @ dydxprotocol / v4-client-js, with several malicious versions detected; in PyPI the package affected is dydx-v4-client in a post-published version. dYdX confirmed the incident in a series of public messages and recommended that users have downloaded these versions to isolate the equipment, move funds from a clean system and rotate keys and credentials. The original dYdX publication is available on X (before Twitter): dYdX: communicated.

According to the analysis, the attacker did not exploit a technical vulnerability of the repositories, but published new versions with legitimate publication credentials, which points to the commitment of maintenance accounts. The malicious actor introduced code into the package's central files (e.g., log and account files), so that the harmful load was run during the usual use of the bookstore. This shows a deep knowledge of the internal structure of the packages and how they are integrated into applications that manipulate funds and keys.

The payload in the JavaScript ecosystem is aimed at exfiltration: it collects seed phrases from portfolios and device data to send them to a server controlled by the attacker. The Python variant adds a more dangerous component: a remote access Trojan (RAT) that runs when importing the package and that consults an external server to receive commands. In particular, this component contacts an endpoint observed by researchers and uses operating system flags - for example, the flag CREATE _ NO _ WINDOW in Windows - to run without showing windows and passing unnoticed. Socket and other analysts have also highlighted a high degree of ofuscation in the PyPI version, suggesting intention to hide malicious and persistent activity.

This event was not born out of nowhere: dYdX had already been the target of attacks on the supply chain in the past. In 2022 it was reported that npm accounts linked to the team were compromised and packages were published that stole credentials, and in 2024 the web associated with its v3 platform was manipulated to redirect victims to a phishing site. The recurrence of these incidents shows that malicious actors see projects with financial components as high-value objectives and that reliable distribution channels - official repositories, maintenance accounts - are a very attractive vector to achieve a great impact with little noise. On the incident of 2022 you can see the thread in GitHub and media coverage: GitHub issue and Bleeping Computer.

In addition to attacks on existing packages, researchers warn about another worrying technique: the publication of "ghost" packages with names referred to in documentation or scripts but never officially published. Aikido did a study on this phenomenon and found that dozens of packages without prior registration accumulated hundreds of thousands of downloads in recent months, simply because users executed npx commands that attempted to invoke non-existing names and, therefore, the record allowed the creation of packages with those names. Aikido analysis details the risk of "npx confusion" and lists examples of packages that reached thousands of downloads; you can read your report here: Aikido: NPX confusion - unclaimed package names.

This vector takes advantage of a default configuration that seeks to be practical but opens the door to remote code execution without explicit user verification. As one of the researchers pointed out, the npm ecosystem has millions of packages and developers run npx commands very often; therefore, there is a gap between comfort and the real risk of running arbitrary code from the network.

In the face of these problems, there are both immediate measures for affected users and preventive practices for developers and organizations. dYdX recommended - and it is wise to repeat - that whoever installed the malicious versions isolate the computer, stop using the keys in that environment, move funds from a system that knows clean and rotate all the keys and API keys. At the operating level, Aikido and other experts recommend preventing npx from fallback to install packages from the unchecked registry: use the option npx --no-install prevents automatic installation and forces the command to fail if it does not exist locally. It is also appropriate to install explicitly the CLI tools that are often used and always verify the existence and reputation of the package that the documentation suggests to run.

For development teams and project managers, mitigation practices include requiring multi-factor authentication for publication accounts, auditing and minimising the rights of publication keys, closing sessions and rotating credentials to any suspicion of commitment, and monitoring the chain of dependencies with Software Composition Analysis (SCA) tools. Keep lock files (lockfiles) in the repositories, paint versions, review changes in transitional dependencies and validate signatures or package sums where possible are measures that reduce the risk surface. Also, recording obvious variants of package or alias names can be a barrier against opportunistic actors who try to publish packages with confusing names.

This incident is a call for attention: the trust we place in central repositories and maintenance accounts is an asset that must be taken care of with the same seriousness as private keys in the critical world. The attackers prefer to "move upstream" because compromising a single publishing identity can affect thousands or millions of users at one time, with very little noise in conventional detection systems. As a sectoral analysis summarizes, the trend is clear: both attacks directed at specific maintainers and large-scale campaigns that take advantage of default configurations are on the increase, and defence simultaneously requires technical controls, organizational processes and greater hygiene in account and key management. A good summary of the recent evolution of these threats is in Sygnia's report on supply chain: Sygnia: Supply chain attacks Q4 2025.

If you work on projects that interact with signatures, transactions, or store secrets related to cryptoactive, remember that the main exposure is not always in your code: sometimes it is in the chain that brings that code to your environments. Check critical dependencies, protect accounts with the ability to publish, and when tool onboarding includes running remote commands, stop a moment and check the source. The convenience is cost-effective if not accompanied by minimum security controls.

For more context and additional readings on the incident and the vectors involved, check the technical coverage in Socket, the dYdX release, the analysis of Aikido and the historical coverage in Bleeping Computer and GitHub linked to the above text.