Critical VS Code Evil Twin Extensions Expose Git and CI Data

Key Takeaways

• A campaign deployed 77 “evil twin” extensions to the Open VSX marketplace, mimicking legitimate VS Code tools.
• These malicious extensions, active between July 26 and August 1, 2026, collected sensitive Git and CI/CD data from developer workstations and build environments.
• Nineteen of the packages contained advanced reconnaissance capabilities, posing significant supply chain risks.
• The packages have been removed from Open VSX, but organizations must actively scan for and remove any installed instances.

A sophisticated campaign has leveraged counterfeit Open VSX extensions to exfiltrate sensitive development data, highlighting a critical vulnerability in the software supply chain. Researchers identified 77 malicious packages that mimicked popular VS Code extensions, using identical names, namespaces, and descriptions to deceive developers. These “evil twin” extensions were designed to collect information from developer machines and continuous integration (CI) environments, with some variants performing extensive reconnaissance.

The operation unfolded between July 26 and August 1, 2026. While the majority of the packages gathered basic device information, 19 of them deployed a much more aggressive reconnaissance routine. This advanced variant was capable of harvesting detailed repository and CI data from developer workstations and build systems.

Security researchers at Manifold said in a report that these packages were published by accounts unrelated to the original extension authors. The malicious activity was often disguised as “telemetry” within the extension listings, a tactic designed to mask the true scope of data collection.

Deep Dive into Data Exfiltration

The stolen information included private repository names, project paths, branch details, and CI identifiers. Such data can be invaluable to attackers, enabling targeted phishing campaigns, facilitating follow-on intrusions, or allowing for comprehensive mapping of an organization’s software supply chain. The ease with which these familiar developer tools were repurposed into data exfiltration channels underscores a significant security gap.

The rogue extensions employed a straightforward but effective impersonation strategy. They reused the identities of well-known extensions, often at an initial version number like 0.0.1, while replacing the legitimate extension.js file with their own malicious code. This technique mirrors risks previously observed with malicious extensions in the official VS Code Marketplace, where trusted tools can conceal harmful functionalities.

Fifty-eight of the identified packages acted as lightweight beacons, reporting only a hostname and, occasionally, a workspace folder or editor version. However, the 19 reconnaissance variants were far more intrusive. They activated within seconds of installation and began collecting a wide array of data, including the hostname, operating system username, editor details, device identifiers, location settings, workspace name, and the full local path.

The more advanced variants also delved into Git metadata. They extracted the host and organization from origin and upstream remote URLs, the domain portion of the configured commit email, the current branch, and the latest commit identifier. For environments running build runners, CI variables could expose the full name or path of private repositories. The malicious code specifically checked for variables related to popular CI/CD platforms such as GitHub Actions, GitLab CI, Azure DevOps, Buildkite, CircleCI, Codespaces, and Gitpod.

Additionally, the extensions listed other installed extensions and read the editor’s telemetry preference. Crucially, they transmitted the collected information even if the user had opted out of telemetry, directly contradicting claims made on their marketplace pages that CI values would remain local to the machine. The researchers confirmed that both CI marker names and their corresponding values were exfiltrated.

Persistence and Supply Chain Risk

The attackers designed the infrastructure with persistence in mind. The malicious packages utilized multiple hosts under the same domain, attempted to re-establish connections for up to seven days, and treated any HTTP response as a successful data delivery. Should hardcoded endpoints fail, the code was capable of querying DNS TXT records to retrieve alternative collection addresses.

This persistence mechanism is particularly concerning given the increasing automation of extension installations. Many development environments rely on devcontainer configurations, editor setup scripts, and provisioning workflows that install extensions by name without verifying publisher ownership, download history, or project lineage. This vulnerability is similar to recent “sleeper” extensions found in Open VSX, which demonstrated how malicious packages can lie dormant within development ecosystems before activating.

As of August 3, the malicious packages have been removed from Open VSX. However, their removal does not guarantee that they have been purged from developer workstation images, build systems, or repository configurations where they may have already been installed.

What You Should Do

• Scan for Installed Extensions: Immediately search developer and CI images for matching entries in .vscode/extensions.json, .devcontainer/devcontainer.json, and .devcontainer.json. Verify the legitimacy of all installed extensions.
• Block Malicious Domains: Block the identified primary campaign domain, mangorbit[.]com, and its associated hosts (pulse.mangorbit[.]com, pulse2.mangorbit[.]com, api.mangorbit[.]com, and the host pattern *.cb.mangorbit[.]com) at your network perimeter.
• Pin Packages by Publisher and Version: For internally mirrored packages, pin them by both publisher and specific version to prevent automated updates to malicious versions.
• Heed Publisher Warnings: Treat unverified publisher warnings as a critical stopping point for any automated installation processes. Manual verification should be mandatory.
• Monitor Network Traffic: Implement alerts for editor processes attempting to contact newly registered domains shortly after startup. Also, monitor for DNS TXT lookups using _beacon labels.
• Review Runtime Behavior: Treat code editor extensions with the same scrutiny as any other software dependency. Regularly review their runtime behavior and network activity.
• Validate Publisher Identity: Always validate the identity of extension publishers before installation, especially for automated setups.

Disclaimer: HackersRadar reports on cybersecurity threats and incidents for informational and awareness purposes only. We do not engage in hacking activities, data exfiltration, or the hosting or distribution of stolen or leaked information. All content is based on publicly available sources.