OX Security researchers uncover how easy it is for malicious extensions to bypass trust checks and execute code on developer machines.
TLDR
- Investigated IDEs: Visual Studio Code (VSCode), Visual Studio, IntelliJ IDEA, and Cursor
- Flaw: Ability to create files that maintain verified symbols while adding malicious functionality
- Exploit: Allows malicious extensions to appear verified while containing code capable of executing operating system commands
- Reported to: Microsoft, JetBrains, Cursor
Integrated Development Environments (IDEs) play a major role in today’s programming landscape. They provide comprehensive environments in which programmers can write, test, and debug code efficiently. However, OX’s research, conducted in May and June 2025, reveals critical security vulnerabilities in how popular IDEs handle extension verification.
IDEs typically include basic built-in functionality, but their capabilities extend through a wide range of third-party extensions available on marketplaces and external websites. This means that any risk in the IDE could result in far-reaching consequences.
To test our theory, the OX research team created malicious extensions on three of the most popular IDEs: Visual Studio Code, Visual Studio, and IntelliJ IDEA. At the start of our test, all three extensions appeared to be verified and trustworthy, presented with the original packaging, including the number of downloads, user ratings, and the blue “verified” symbol.
Technical Investigation
To start our research, we first analyzed the potential risks associated with Visual Studio Code, a free, open-source code editor developed by Microsoft. It’s one of the most popular tools used by software developers worldwide.
Visual Studio Code allows community members to publish extensions to the Marketplace. Extensions from verified publishers, indicated by a blue checkmark icon, have undergone Microsoft’s publisher verification process, which confirms the legitimacy of both the publisher and the extension.
We discovered that flawed verification checks in Visual Studio Code allow publishers to add functionality to extensions while maintaining the verified icon. This results in the potential for malicious extensions to appear verified and approved, creating a false sense of trust.
Verification Process
We analyzed the traffic performed by Visual Studio Code (VSCode) and discovered a request to marketplace.visualstudio.com that allows the server to determine whether an extension is verified.
Valid Extension Request:
POST /_apis/public/gallery/extensionquery HTTP/2
Host: marketplace.visualstudio.com
Content-Length: 83
Accept: application/json;api-version=3.0-preview.1
Content-Type: application/json
{"filters":[{"criteria":[{"filterType":7,"value":"ms-vscode-remote.remote-ssh"}]}]}
Response for Verified Extension:
HTTP/2 200 OK
Cache-Control: no-cache, no-store, must-revalidate
Pragma: no-cache
Content-Length: 753
Content-Type: application/json; charset=utf-8; api-version=3.0-preview.1
<HEADERS>
{"results":[{"extensions":[{"publisher":{"publisherId":"ac9410a2-0d75-40ec-90de-b59bb705801d","publisherName":"ms-vscode-remote","displayName":"Microsoft","flags":"verified","domain": "https://microsoft.com", "isDomainVerified":true},"extensionId":"607fd052-be03-4363-b657-2bd62b83d28a","extensionName":"remote-ssh","displayName":"Remote - SSH","flags":"validated, public","lastUpdated":"2025-05-09T15:20:15.967Z","publishedDate":"2019-05-02T18:40:34.66Z","releaseDate":"2019-05-02T18:40:34.66Z","shortDescription":"Open any folder on a remote machine using SSH and take advantage of VS Code's full feature set.","deploymentType":0}],"pagingToken":null,"resultMetadata":[{"metadataType":"ResultCount","metadataItems":[{"name":"TotalCount","count":1}]}]}]}
When an extension is invalid, VSCode sends the following request to marketplace.visualstudio.com:
POST /_apis/public/gallery/extensionquery HTTP/2
Host: marketplace.visualstudio.com
Content-Length: 89
Accept: application/json;api-version=3.0-preview.1
Content-Type: application/json
{"filters":[{"criteria":[{"filterType":7,"value":"ms-vscode-remote.remote-ssh-nirza"}]}]}
Invalid Extension Response:
HTTP/2 200 OK
Cache-Control: no-cache, no-store, must-revalidate
Pragma: no-cache
Content-Length: 150
Content-Type: application/json; charset=utf-8; api-version=3.0-preview.1
<HEADERS>
{"results":[{"extensions":[],"pagingToken":null,"resultMetadata":[{"metadataType":"ResultCount","metadataItems":[{"name":"TotalCount","count":0}]}]}]}
Exploitation Method
Based on this information, we began investigating how to modify the values involved in the server request that determines whether an extension is verified.
We examined the files bundled within extensions and identified where the values used in verification requests are stored and successfully modified them.
We developed our “malicious” extension with the same verifiable values as an already verified extension. These included a command to open the calculator as proof of concept, demonstrating our ability to execute commands on the client workstation.
We added the following command entry to the package.json file:
And implemented its functionality within the extension.js file:
Using the files and values identified earlier in the extension verification process, we were able to create a VSIX file that packaged our malicious extension to appear legitimate:
The VSIX extension file can be uploaded to platforms like GitHub, where developers may download and install extensions locally.
Extension to Other Platforms
After confirming this behavior on VSCode, we extended our investigation to other platforms:
- Visual Studio
- IntelliJ IDEA
- Cursor
Despite differences in file structures and verification mechanisms across these platforms, we identified the requests used for verification and located the relevant values within the extensions. We successfully created extensions that maintained their verified status by modifying these values.
Visual Studio Code:
Visual Studio:
IntelliJ IDEA:
Cursor:
Consequences: Widespread, Heightened Risk
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. This vulnerability particularly impacts developers who install extensions from online resources such as GitHub.
This can result in arbitrary code execution on developers’ workstations without their knowledge, as the extension appears trusted. Therefore, relying solely on the verified symbol of extensions is inadvisable.
Our research demonstrates that attackers can bypass current verification mechanisms across major development platforms. Carefully crafted malicious extensions can be packaged into VSIX/ZIP files and, once installed by developers, may lead to severe consequences while maintaining the verified symbol.
Security Recommendations
What should your development team do to prevent this?
- Do not rely solely on a “verified” badge as a measure of trust.
- Install extensions directly from official marketplaces rather than through VSIX extension files shared online.
What should IDE developers do?
- Implement multi-step verification for extension signing.
- Validate the installation source and only approve market-signed installed extensions.
- Validate per-file hash for each of the extension’s files.
What should extension developers do?
- Validate code signing integrity.
- Implement certificate verification to prevent man-in-the-middle attacks.
- Add protections to prevent tampering.
Microsoft, Cursor, and JetBrains Responses
Microsoft, which operates both VSCode and Visual Studio, responded to our findings: “After careful investigation, this case has been assessed as by design and does not meet Microsoft’s bar for immediate servicing. This is as designed. Furthermore, the changes will be prevented by extension signature verification, now enabled by default across all platforms. The attacker will be unable to publish this to the Marketplace, so only side-loading is possible. However, we have shared the report with the team responsible for maintaining the product or service. They will take appropriate action as needed to help keep customers protected. MSRC prioritizes vulnerabilities that are assessed as an Important or Critical severity. Since the case was assessed as low or moderate severity, no CVE will be issues. MSRC will not be tracking this issue further, and no additional updates will be provided.”
Despite the above response, our teams have checked and found that the vulnerability was still very much exploitable on June 29, 2025.
JetBrains (IntelliJ IDEA) was also informed and replied, “Installing a plugin manually from a .zip file is an intentional action made by the user. In this case, the plugin did not come from the JetBrains Marketplace, and therefore it is treated as a third-party, unverified plugin. When such a plugin is installed, the IDE clearly displays a warning. This message informs the user that they are accepting full responsibility for installing code from an untrusted source.”
Cursor’s response: “Per our security page cursor.com/security, we do not verify extension signatures. Also please note that even upstream VSCode only verifies extension signatures at install time, not continuously.”
)
