In software development, a single action, such as an “install” click, can have significant security implications. In April, SDG issued a warning: as AI development and the ecosystem of coding tools expand, breaches are increasingly likely to originate from a developer’s plugin rather than a server-side vulnerability. This risk was not theoretical; the threat landscape was evolving.
Three months later, that risk was realized. A single malicious IDE plugin, disguised as a helpful tool, led to a significant developer-targeted theft in 2025: approximately $500,000 in crypto assets were stolen. The breach did not involve a complex, multi-stage attack. It resulted from a single oversight, installing a plugin from a public marketplace without verifying its authenticity.
This incident offers important lessons and highlights effective controls. Below, we connect our April advisory to this recent attack and outline concrete protective measures every engineering team can implement as technology stacks continue to evolve.
The April Threat Advisory
Our April Threat Advisory was built around a direct message: the developer supply chain is an increasingly targeted vector. The key points we emphasized were:
- IDE extensions are a growing vector for attackers. Malicious add-ons can bypass many endpoint protections because they operate with the developer’s privilege level.
- Poisoned open-source packages and “typosquatting” attacks are increasing. Threat actors upload counterfeit libraries or plugins with names nearly identical to trusted tools, relying on developers to overlook the difference.
- AI-generated code and tools are not inherently secure. Security best practices are not always integrated into new AI tools or LLM-based utilities as they enter the market.
- GitHub and public registries are being used as malware distribution channels, not just collaboration hubs.
- The expanding attack surface now includes commonly trusted development tools used
We outlined prevention strategies: validate plugins, use only trusted sources, enforce code signing and review, monitor for suspicious behavior, and foster a culture of security awareness within development teams.
As we often note, warnings are only effective when acted upon.
How the Attack Occurred: The Cursor AI “Solidity” Plugin Incident
In June, a developer working on blockchain projects downloaded what appeared to be a legitimate “Solidity Language” plugin for the Cursor AI IDE. The extension appeared trustworthy, as it was popular, showed recent updates, and listed a familiar author name.
The plugin was a counterfeit. The attack was executed as follows:
- Subtle Impersonation: The attacker uploaded a plugin with a name nearly identical to the legitimate “Solidity” tool and replaced a lowercase “l” with an uppercase “I” in the author’s handle (juanblanco → juanbIanco).
- Marketplace Algorithm Manipulation: The fake plugin was updated more frequently than the legitimate version, which manipulated the marketplace’s algorithm to rank it higher in search results, deceiving developers.
- A Concealed Payload: The plugin contained no legitimate functionality for syntax highlighting. Instead, it included a script that fetched and executed PowerShell commands from attacker-controlled servers (angelic[.]su, relay.lmfao[.]su), installing legitimate remote-support software (ScreenConnect), a remote access tool (Quasar RAT), and an information stealer (PureLogs).
- System Compromise and Fund Exfiltration: With full access to the developer’s machine, the attackers exfiltrated private keys and credentials for crypto wallets and transferred approximately $500,000 worth of assets.
This was not a nation-state operation but an opportunistic attack that was preventable. The attack exploited the developer’s trust in the marketplace and the extension itself.
From Advisory to Breach: A Direct Correlation
This table connects the risk areas from our April advisory to the events of this attack:
| April Advisory | Real-World Proof in This Attack |
|---|---|
| Malicious IDE extensions bypassing endpoint controls. | ScreenConnect is a signed, legitimate IT-support tool, so it was whitelisted by the EDR. |
| Supply-chain attacks moving into development tools. | The breach originated on the developer’s workstation before any code reached the repository. |
| Marketplace ranking can outweigh reputation. | The fake plugin received more downloads than the real one. |
| Developers are privileged targets. | One compromised workstation provided access to crypto wallets, cloud accounts, and codebases. |
This type of attack is actively occurring.
Additional Lessons from This Incident
The incident also highlights additional risks:
- Remote-IT tools like ScreenConnect are being used as malware payloads. They are signed, legitimate, and often not blocked. Any unexpected installation of a support tool should be investigated immediately.
- Typosquatting can deceive developers. Minor visual changes (e.g., l vs. I) can evade casual inspection and some marketplace verification methods.
- Marketplace search algorithms can be manipulated. Prioritizing “recently updated” or “popular” over “verified” or “signed” creates an environment conducive to social engineering.
- Plugins are dependencies and should be treated as such. They require the same level of scrutiny, including reviews and version pinning, as a production library.
Timeline of Events
- June 2025: A fake “Solidity Language” plugin was uploaded and gained over 50,000 downloads via the Cursor AI and Open VSX marketplaces.
- The plugin contained no syntax highlighting code, only a script to install malware.
- July 2025: Kaspersky’s Georgy Kucherín published an analysis, and Open VSX delisted the plugin. Hours later, a similar fake was uploaded with a download count of over 2 million.
- A similar campaign was identified on the VS Code Marketplace and npm (solaibot, among-eth, solsafe), demonstrating a repeatable attack pattern.
Key Indicators of Compromise (For SOC/IT Teams)
- angelic[.]su/files/1.txt
- angelic[.]su/files/2.txt
- relay.lmfao[.]su | 144.172.112[.]84
- ScreenConnect.ClientSetup.msi?e=Access&y=Guest
- Hashes: 2c471e26…, 404dd413…, 70309bf3… (full list available from Securelist/Kaspersky)
Behavioral Indicators:
- A new plugin with a sudden, high download count and a low number of contributors.
- A plugin that prompts for network or system access upon installation.
- IDE processes making outbound connections to unusual or non-corporate domains.
Mitigating the Risk: Practical Controls and Policy Alignment
The breach illustrates how targeted attacks on developer workflows can bypass conventional security layers and result in significant business impact. Preventing similar incidents requires shifting focus from reactive detection to proactive risk management through embedding effective controls, clear policies, and standardized processes into the development environment itself.
The following section outlines controls that address the specific attack vectors exploited in this breach, provides policy language for consistent enforcement, and maps each control to established security frameworks. These elements form a risk-based foundation for reducing the likelihood and potential impact of future plugin-related threats.
Controls That Could Have Prevented This Breach
- Enforce Signed-Only Plugins: Maintain an internal, whitelisted extension registry. Only allow plugins with valid digital signatures from verified authors. Block unsigned VSIX, .jar, .whl, and gem files at the network proxy.
- Automated Static Scanning: Scan every new plugin for high-risk function calls (e.g., Invoke-WebRequest, exec(), network requests). If a new or unapproved hash is detected, fail the build or block the installation.
- Use Sandboxed Development Environments: Utilize tools like Codespaces, Dev Containers, JetBrains Gateway, or lightweight local VMs. If a plugin is compromised, it cannot access sensitive credentials or files on the host machine.
- Egress Monitoring: Monitor traffic from IDEs. Alert if any plugin or extension process initiates a connection to non-corporate domains (especially high-risk TLDs like .su, .cn, etc.). Employ a “block first, triage later” policy for suspicious connections.
Example Policy Statement
“All IDE plugins, extensions, and language packs must be sourced from our approved internal registry. Any package that is unsigned or has a mismatched author is automatically blocked. Development containers will default to a non-privileged runtime. Outbound network traffic from IDE processes to non-corporate domains is denied by policy.”
Mapping to Security Frameworks
| Mapped Practice | ISO 27001:2022 | NIST SSDF v1.1 | SOC 2 | NIST CSF 2.0 | NIST AI RMF | ISO/IEC 42001:2023 |
|---|---|---|---|---|---|---|
| Enforce signed plugin registry; allow-lists | A.14.2.5, A.12.6.2 | PS.3.1, PO.2.2 | CC6.1 | PR.IP-1 | RM-GOV-1, MAP-1 | 6.3.3, 6.3.4 |
| Static/behavioral scanning for plugins | A.14.2.8 | PW.4.1 | MAP-1, MON-1 | 6.2.1, 8.2.2 | ||
| Egress monitoring; sandboxing dev environments | A.13.1.1, A.14.2.6 | PO.2.2 (process-level) | CC6.1 | PR.PT-4 | MON-1, GOV-2 | 8.2.2, 8.3.1, 8.3.2 |
| Sandboxed environments; plugin policy | A.14.2.6 | PO.2.2 (process-level) | PR.IP-1 | GOV-1 | 6.3.3, 8.2.2 | |
| Restrict unsigned plugins; internal approval | A.12.6.2 | PS.3.1 | CC6.1 | GOV-1, MAP-1 | 6.3.3, 6.3.4, 8.2.1 |
These controls are not just for audit compliance; they are critical for preventing a breach.
Next Steps for Security Teams
- Harden the Developer Environment
- Apply production-grade controls to developer systems. Enforce signed-only plugin installation, block unsigned extension packages at the proxy, and monitor IDE processes for abnormal network activity.
- Establish an Internal Plugin Repository
- Maintain a private repository of vetted, approved plugins. Enforce plugin allow-lists and validate digital signatures before use. Block access to public plugin marketplaces from development environments unless explicitly authorized.
- Test Security Readiness Through Simulation
- Conduct an IDE-focused red team simulation, targeting plugin behavior and developer workflows. Assess whether developers can identify and report suspicious behavior. Use results to improve both awareness and response workflows.
- Coordinate Threat Intelligence Sharing
- Disseminate indicators of compromise (IOCs) across security, IT, and engineering teams. Share relevant plugin-based threat activity with trusted peers or industry ISACs to strengthen collective defense
Conclusion
The “Solidity” plugin incident is not an isolated event but an example of a growing trend. Supply-chain attacks have “shifted left,” targeting developers, plugins, and IDEs before code reaches a central repository.
Practices once considered optional security hygiene are now essential. Signed plugins, internal mirrors, sandboxed development environments, continuous scanning, and strong human vigilance are controls that protect assets and reputation.
The warning signs were present, and this attack confirmed the risk. These measures can help ensure your organization avoids becoming the subject of a similar incident report.
