A new study of integrated development environments (IDEs) like Microsoft Visual Studio Code, Visual Studio, IntelliJ IDEA, and Cursor has revealed weaknesses in how they handle the extension verification process, ultimately enabling attackers to execute malicious code on developer machines.
“We discovered that flawed verification checks in Visual Studio Code allow publishers to add functionality to extensions while maintaining the verified icon,” OX Security researchers Nir Zadok and Moshe Siman Tov Bustan said in a report shared with The Hacker News. “This results in the potential for malicious extensions to appear verified and approved, creating a false sense of trust.”
Specifically, the analysis found that Visual Studio Code sends an HTTP POST request to the domain “marketplace.visualstudio[.]com” to determine if an extension is verified or otherwise.
Protect your privacy by Mullvad VPN. Mullvad VPN is one of the famous brands in the security and privacy world. With Mullvad VPN you will not even be asked for your email address. No log policy, no data from you will be saved. Get your license key now from the official distributor of Mullvad with discount: SerialCart® (Limited Offer).
➤ Get Mullvad VPN with 12% Discount
The exploitation method essentially involves creating a malicious extension with the same verifiable values as an already verified extension, such as that of Microsoft, and bypassing trust checks.
As a result, it allows rogue extensions to appear verified to unsuspecting developers, while also containing code capable of executing operating system commands.
From a security standpoint, this is a classic case of extension sideloading abuse, where bad actors distribute plugins outside the official marketplace. Without proper code signing enforcement or trusted publisher verification, even legitimate-looking extensions can hide dangerous scripts.
For attackers, this opens up a low-barrier entry point to achieve remote code execution—a risk that’s especially serious in development environments where sensitive credentials and source code are often accessible.
In a proof-of-concept (PoC) demonstrated by the cybersecurity company, the extension was configured to open the Calculator app on a Windows machine, thereby highlighting its ability to execute commands on the underlying host.
By identifying the values used in verification requests and modifying them, it was found that it’s possible to create a VSIX package file such that it causes the malicious extension to appear legitimate.
OX Security said it was able to reproduce the flaw across other IDEs like IntelliJ IDEA and Cursor by modifying the values used for verification without making them lose their verified status.
In response to responsible disclosures, Microsoft said the behavior is by design and that the changes will prevent the VSIX extension from being published to the Marketplace owing to extension signature verification that’s enabled by default across all platforms.
However, the cybersecurity company found the flaw to be exploitable as recently as June 29, 2025. The Hacker News has reached out to Microsoft for comment, and we will update the story if we hear back.
The findings once again show that relying solely on the verified symbol of extensions can be risky, as attackers can trick developers into running malicious code without their knowledge. To mitigate such risks, it’s advised to install extensions directly from official marketplaces as opposed to using VSIX extension files shared online.
“The ability to inject malicious code into extensions, package them as VSIX/ZIP files, and install them while maintaining the verified symbols across multiple major development platforms poses a serious risk,” the researchers said. “This vulnerability particularly impacts developers who install extensions from online resources such as GitHub.”
Found this article interesting? Follow us on Twitter and LinkedIn to read more exclusive content we post.
Some parts of this article are sourced from:
thehackernews.com
A New Maturity Model for Browser Security: Closing the Last-Mile Risk