The rise of DeepSeek has led to malicious actors attempting to exploit its prominence. Positive Technologies researchers have discovered two information-stealing packages on the Python Package Index (PyPI), mimicking developer tools for DeepSeek. These information-stealers are designed to take the data of the developers that utilize them. When executed on the device, the payload will steal target data, system data, and environment variables (such as database credentials, API keys, and infrastructure access tokens). 

Below, security leaders discuss the implications of these findings. 

Security leaders weigh in 

Jason Soroko, Senior Fellow at Sectigo:

Positive Technologies’ report details a threat where malicious actors injected infostealer malware into the PyPI repository by disguising it as DeepSeek. The findings confirm that attackers exploit trusted naming conventions and the open-source ecosystem’s reliance on authentic package sources. Although the report was published from a Russian domain, which may limit accessibility, the technical evidence underscores a growing risk in software supply chains. Organizations should enforce strict package verification and monitor repository activity to mitigate potential breaches.

Mike McGuire, Senior Security Solutions Manager at Black Duck:

In the early days of open source software, we were taught to treat the packages we used with inherent trust. We’re now in the era of having to treat every package that we download or use with a reasonable level of scrutiny. While this attack involved the name DeepSeek, it’s important to note that this had nothing to do with the company, or with AI at all. Rather, it has everything to do with attackers seeing opportunity in the popularity of AI tools in the development community. 

In their eagerness to leverage DeepSeek in their tasks, many developers missed the “red flag” that they were downloading packages from an account with a limited, poor reputation, and had their environment variables and secrets compromised as a result. This emphasizes the importance of leveraging all of the metrics made available for open source packages before including them into projects. While it seems obvious by now that dependencies with security vulnerabilities should be excluded, component provenance, health, and operational factors should also serve as inclusion criteria; those with little to no history, concerning changes from one version to the next, questionable owners, poor community support, etc… should be flagged for further review and scrutiny. 

While this sounds like a time consuming task, there is no shortage of tools on the market that do this automatically and build directly into the software development lifecycle.