The Risks of Misguided Research in Supply Chain Security

On January 8, 2025, it came to light that Snyk, a well-known security tool—frequently used to protect against supply chain attacks—was implicated in a troubling event. Several malicious packages targeting the popular AI coding platform Cursor were deployed to the public npm registry. These packages, named “cursor-retrieval,” “cursor-always-local,” and “cursor-shadow-workspace,” collected sensitive environment variables from systems where they were installed and exfiltrated the data to their own servers.

This type of attack is commonly referred to as “dependency confusion,” where malicious packages masquerade as legitimate internal dependencies to exploit misconfigurations.

What made this incident particularly striking was the source of the packages. Metadata revealed that they were published using an email address linked to the research team of a prominent security company. The use of a verified Snyk corporate email address made it clear that this was not an impersonation but rather an action originating from within the organization itself.

In a statement given to Security Week, Snyk explained that the packages were released as part of a research project focusing on dependency confusion. One particularly concerning aspect of this incident, among several ethically dubious choices in the experiment, was that a Cursor developer said that the company had not hired Snyk to perform a security audit:

The Snyk packages are just the names of our bundled extensions, which we never package nor upload to any registry. (We do it just like how VS Code does it: https://github.com/microsoft/vscode/tree/main/extensions)

We did not hire snyk, but we reached out to them after seeing this and they apologized. we did not get any confirmation of what exactly they were trying to do here (but i think your explanation that someone there suspected a dependency confusion vulnerability is plausible. Though it's pretty irresponsible imo to do that on public npm and actually sending up the env variables.)

In 2021, security researcher Alex Birsan demonstrated a similar dependency confusion attack by hacking into Apple, Microsoft, Yelp, Shopify, and dozens of other companies, but did so with prior permission from the targeted organizations.

“I feel that it is important to make it clear that every single organization targeted during this research has provided permission to have its security tested, either through public bug bounty programs or through private agreements,” Birsan said in his research post. “Please do not attempt this kind of test without authorization.”

His research originated the concept of dependency confusion, highlighting vulnerabilities in package management systems by ethically probing for weaknesses without exposing sensitive data.

Why Ethical Boundaries Matter#

While the stated intent behind deploying these packages might have been to research a potential vulnerability—dependency confusion in Cursor's VS code extensions—the execution was deeply flawed.

• Public Deployment is Reckless: Publishing malicious packages to the public npm registry creates unnecessary risk. Even if the packages are intended as proof-of-concept (PoC), they can be inadvertently installed by unrelated developers or automated systems, leading to broader impacts than the researcher anticipated.
• Exfiltration of Sensitive Data: The packages collected and transmitted environment variables, which often include sensitive information like API keys, tokens, and configuration details. A PoC does not require actual data exfiltration to prove its point. Safer alternatives exist, such as logging non-sensitive data locally or simulating exfiltration without transmitting real information.
• Unsolicited Testing Breaches Trust: Cursor’s development team confirmed they neither authorized nor requested this activity. Conducting unsolicited testing on a live environment or public ecosystem crosses an ethical line and may also violate legal boundaries. Security research should prioritize collaboration and consent.
• Violation of npm’s Terms of Service: This incident may also be a direct violation of npm’s open-source terms of use. npm’s acceptable content policy explicitly prohibits submission of "[c]ontent containing malicious computer code, such as computer viruses, computer worms, rootkits, back doors, or spyware. This includes content submitted for research purposes." While tools designed and documented to assist in security research are considered acceptable content, intentional deployment of packages with malicious behavior like phoning home with user data, even if done for research purposes, likely violates these terms and undermines trust in the ecosystem.

Preventing Dependency Confusion Attacks#

Helping developers navigate snares like dependency confusion and manifest confusion are some of the reasons Socket was founded. As prolific open source maintainers, our team is deeply experienced in understanding the dynamics of package ecosystems, including the security challenges that routinely burden maintainers. We are invested in helping developers use this ecosystem safely.

In an ideal world, security researchers would prioritize collaboration with software creators over assumption, especially when targeting a top AI company with malicious packages and exposing the open source ecosystem at large. Transparency and clear accountability structures can prevent these issues from escalating when performing this kind of research.

For organizations looking to protect themselves from dependency confusion attacks (and from unethical researchers publishing malicious packages targeting them without their consent), proactive steps include:

• Use Scoped Packages: Adopting scoped package naming conventions (e.g., @company/package-name) can significantly reduce the risk of namespace collisions.
• Private Registries: Maintain a private npm registry and configure package managers to prioritize it over public registries.
• Endpoint Protection: Employ endpoint security tools to monitor and block unauthorized package installations.
• Prevent Access to Public Registries: Restrict access to public registries for environments using private registries to ensure all dependencies are sourced securely.
• Tooling for Threat Detection: Employ tools that can detect anomalous package behavior, such as those exfiltrating data and environment variables.
• Automated Dependency Management: Implement automation to vet and lock dependencies, ensuring that only trusted packages are used in production.
• Pre-Installation Checks: Use package managers or installers that proactively analyze packages for threats before downloading or installing them. The timing of detection is critical, ensuring potential risks are identified and mitigated at the earliest possible stage.

Building a Better Supply Chain Security Ecosystem#

The software supply chain remains one of the most vulnerable points in modern development. Events like this—where the line between research and recklessness is blurred—harm trust and divert attention from genuine threats. The lesson here is clear: good intentions cannot excuse irresponsible actions.

At Socket, our mission is to address these challenges with tools that prevent entire classes of supply chain attacks before they happen. By analyzing package behavior and prioritizing proactive security, we aim to make software development safer for everyone. Together, let’s work towards a security culture that protects the open source ecosystem, where ethical standards are as robust as the tools we build.