Software developers often install extensions to make coding easier. A programming editor that supports a language may need extra tools for syntax highlighting, debugging, database connections, code formatting or artificial intelligence help.
These extensions become part of a developers workflow. Once installed a malicious extension can run alongside the editor talk to project files and give features that would otherwise need applications.
However the same access that makes these extensions useful can also create a security weakness.
A malicious extension can use its permissions to read files watch development activity talk to servers or run extra processes. If a developer works with company repositories, cloud credentials, API keys or authentication tokens the compromised software could expose information far beyond one computer.
The risk is no longer theoretical. Several cybersecurity incidents in 2026 have shown how attackers can exploit developer extensions and trusted software distribution platforms to reach systems.
In May 2026 the US Cybersecurity and Infrastructure Security Agency or CISA warned about a software supply‑chain compromise involving the Nx Console Visual Studio Code extension. The incident was linked to the compromise of a GitHub employees device and the unauthorised exfiltration of GitHub repositories.
The incident highlights a weakness in modern software development: a tool installed to improve productivity can become an entry point into the systems that developers are responsible for protecting.
Why Coding Extensions Can Become a Gateway for Cyberattacks
Developer extensions differ from desktop applications because they often run directly inside an environment that holds valuable technical information.
Visual Studio Code for example runs extensions through an extension host that has the permissions as the editor itself. According to Microsofts documentation an extension can. Write files make network requests, run external processes and modify workspace settings.
That access is necessary for functionality. A database extension must talk to databases while a debugging tool may need to run processes and inspect application files.
The security problem arises when an attacker gains control of an extension or publishes software designed to collect information without the developers knowledge.
A compromised extension could look for source code, environment configuration files, authentication credentials, SSH keys, cloud access tokens and other sensitive information that belong to the user account.
The consequences can extend beyond the developers machine. Stolen credentials may give access to repositories, cloud infrastructure, development environments and automated deployment pipelines.
For software companies this creates a risk. A single compromised developer account or workstation could expose information and systems that connect to business projects.
The concern is especially significant in organisations where developers can access production environments, customer databases or cloud infrastructure.
The Nx Console Incident Shows How a Trusted Extension Can Become a Threat
One of the significant examples emerged in May 2026 through a compromise involving Nx Console, a widely used development extension associated with the Nx and Lerna software ecosystems.
On May 19 a malicious version identified as Nx Console 18.95.0 was published through the Visual Studio Marketplace. It was also distributed through Open VSX, an alternative extension registry used by VS Code‑compatible development environments.
The malicious version stayed available for 18 minutes in Microsofts marketplace and about 36 minutes in Open VSX before it was removed.
The incident was particularly concerning because it involved an established extension, than an entirely unfamiliar application that imitates a popular tool.
CISA reported that attackers had used a compromise of Nx developer systems to compromise a GitHub employees device through the poisoned third‑party extension. This caused access and the exfiltration of internal GitHub repositories.
The malicious release was also distributed through the editors automatic update mechanism. Developers who had installed Nx Console before could therefore have received the compromised version without searching for or installing a new extension.
The incident received the vulnerability identifier CVE‑2026‑48027. Was added to CISAs Known Exploited Vulnerabilities catalogue.
GitHubs security advisory identified version 18.95.0 as affected and recommended upgrading to version 18.100.0 or later. Users who may have been exposed were advised to terminate processes remove persistence files rotate accessible credentials and review account activity.
The wider lesson is important: a familiar extension and an established publisher history do not guarantee that every future update will stay safe.
AI Coding Extensions Have Become Another Target for Data Theft
The growing popularity of AI‑powered development tools has created another opportunity for attackers.
AI coding assistants may need to examine project files understand code structures and analyse changes to provide suggestions. This means developers often give these tools access to information that could be commercially sensitive.
In January 2026 cybersecurity researchers at Koi Security identified two Visual Studio Code extensions promoted as AI coding assistants.
The extensions, named ChatGPT. 中文版 and ChatGPT. ChatMoss had accumulated 1.5 million combined installs according to reporting by The Hacker News.
Although the extensions provided advertised coding functionality researchers said they also contained functionality that captured files being opened and source‑code modifications and transmitted the information to servers without users knowledge.
The campaign was named MaliciousCorgi.
This example demonstrates why an extension does not need to behave on the surface to create a security problem. A tool can provide suggestions explain programming errors and appear to function normally while performing additional activities in the background.
For software companies the potential consequences include the exposure of source code, internal development processes and information that could help competitors understand commercially valuable products.
The growing integration of AI into development environments makes it particularly important to understand what information coding tools can access and where that information is transmitted.
Source: The Hacker News, January 26 2026: Malicious VS Code AI Extensions With 1.5 Million Installs Steal Developer Source Code.
GlassWorm Demonstrates How Legitimate Extensions Can Be Hijacked
Another campaign involved GlassWorm malware, which targeted the Open VSX extension marketplace.
In January 2026 security researchers at Socket identified versions of four established extensions published under the developer account oorzc. Before the releases the four extensions had accumulated more than 22,000 downloads.
The affected tools included an FTP/SFTP/SSH synchronisation utility, an internationalisation tool, a mind‑mapping extension and a stylesheet compilation extension.
The attack was particularly concerning because the extensions had previously appeared to be developer utilities. Researchers assessed that the publishers publishing credentials may have been compromised, allowing attackers to release versions under an established account.
The malware used a staged execution process to retrieve and run payloads. The investigated payloads targeted macOS systems. Attempted to collect browser information, authentication data, cryptocurrency wallet files and other sensitive information.
The campaign also evolved. In March 2026 researchers reported that least 72 additional malicious Open VSX extensions were linked to a later GlassWorm operation.
Of placing all malicious functionality directly inside an extension attackers abused extension‑pack and dependency relationships. An harmless‑looking extension could later pull in another malicious component through an update.
This makes the threat more difficult to detect through an examination of the original installation package.
It also demonstrates that security reviews must consider an extensions dependencies and subsequent updates, not its initial appearance or download history.
Sources: Sockets January 31 2026 GlassWorm investigation and CSO Onlines March 16 2026 GlassWorm report.
What Happens When a Developer Installs an Extension?
The potential impact depends on the extensions capabilities the permissions available to it and the information accessible through the developers account.
One of the targets may be source code. Developers working on software can have access to unreleased product features, internal algorithms, proprietary business logic and customer‑specific integrations.
An attacker who obtains these files may attempt to sell the information use it for attacks or identify weaknesses in the organisations software.
Credentials represent another risk. Development environments frequently contain API keys, cloud access tokens, database passwords and SSH credentials used to connect with services.
If these are stolen attackers may attempt to access repositories, cloud accounts or automated software deployment systems.
The risk can become more serious when development environments connect directly to company infrastructure.
Modern software teams commonly use integration and continuous deployment pipelines to test and release code automatically. These systems may contain access tokens and permissions that allow software to be built, tested or deployed.
A compromised developer environment could therefore become an entry point into a larger software supply‑chain attack.
There is also a privacy dimension. Extensions may have access to information, about projects, user activity and local development environments. Unauthorised collection can expose business information even when no direct financial theft occurs.
For businesses the potential financial impact includes incident‑response expenses, service disruption, intellectual property exposure, security investigations and regulatory complications.
Why Automatic Updates Can Increase the Risk
Automatic updates are a part of modern software. They let developers get security fixes, performance boosts and new features without having to download each version by hand.
However an automatic update can also bring code when a real publishing account or release process has been broken.
The Nx Console incident shows this danger. Its bad version reached users who had already installed it through the update path.
So developers cannot trust only that an extension was safe when they first installed it. A trusted tool can later become unsafe if someone steals publishing credentials, gains access to a maintainer’s account or changes its software dependencies.
The same problem is true for more than coding extensions. Package managers, build tools, continuous‑integration workflows and other developer services can also bring pieces into a software project.
The European Union Agency for Cybersecurity or ENISA warned about these risks in a March 2026 advisory on secure package‑manager use. The agency explained how bad maintainers and harmful dependencies can spread code through connected software ecosystems.
For development teams this means extension security must be a job, not a one‑time approval.
Why Marketplace Security Checks Cannot Guarantee Complete Protection
Big developer platforms already have systems that try to spot extensions.
Microsoft’s Visual Studio Marketplace uses malware scanning, dynamic detection, unusual‑usage monitoring, publisher verification and a blocklist for confirmed extensions.
The marketplace also signs published extension packages allowing Visual Studio Code to check package integrity during installation. Microsoft says the marketplace automatically scans extensions and updates and can remove extensions that are confirmed to be malicious.
These safeguards are good. They cannot guarantee that every bad release will be caught before it spreads.
Threat actors can use stolen publisher credentials change an extension or add harmful code through dependencies. A package may look normal at first. Later download extra code.
Publisher verification must also be understood correctly. Microsoft’s blue verified‑publisher indicator confirms domain ownership and some marketplace standing requirements. It is a trust signal, not a promise that an extension is completely safe or immune to future compromise.
Workspace Trust adds another layer by limiting actions when developers open unfamiliar projects.. Microsoft’s documentation specifically warns that Workspace Trust cannot stop a bad extension from running code and ignoring Restricted Mode.
So security checks do not remove the need for developers and organisations to manage their extension risks.
How Developers and Software Companies Can Reduce the Risk
Protecting a development environment starts with the idea that every installed extension adds a new part to the software supply chain.
Developers should install the extensions they really need and prefer tools published by established verifiable developers. Publisher identity, repository information, update history, documentation and user feedback help gauge reliability.
Popularity and download counts are not proof of safety. The Nx Console and GlassWorm incidents show that well‑known tools and publisher accounts can also be broken.
Organisations should keep approved‑extension lists so employees cannot install software in sensitive development environments. This cuts exposure to plugins and makes it easier for security teams to spot odd behaviour.
Access to credentials should also be limited. Developers should avoid putting production credentials in local development environments. Use managed secrets, temporary access tokens and least‑privilege permissions whenever possible.
Software teams should watch extension updates review dependency changes and use endpoint security tools to spot file access or unexpected network connections.
For businesses that use cloud infrastructure, regular credential rotation and strong multi‑factor authentication can reduce damage, from stolen access information.
Organisations should also keep an incident‑response plan that covers checking installed extension versions removing components rotating credentials and reviewing repository and cloud‑account logs.
These steps cannot remove every threat. They can stop an attack from spreading too far when a developer tool gets compromised.
The Growing Role of AI Is Making Developer Security More Important
AI‑assisted development is changing how software is made. Coding assistants can read project files generate code, spot bugs, call tools and run development tasks through automated workflows.
This boosts productivity. It also brings new security concerns.
An AI coding environment may have access to source code, internal documentation, terminal commands and external services. If an extension or connected tool is compromised that access could provide an attacker with information that would otherwise require separate steps to obtain.
Microsofts guidance on VS Code security also highlights the possibility of injection through untrusted project content when AI-powered agents are used. Malicious instructions contained in project files can attempt to influence an AI agent into performing actions.
This is a threat from a malicious extension but the two risks can overlap when AI tools operate inside an extension-enabled development environment.
Software companies will therefore need security policies that cover both plugins and newer AI integrations.
The objective should be to retain the productivity benefits of AI coding while ensuring that access to files, credentials and infrastructure remains controlled.
What Happens Next?
The recent campaigns are likely to encourage scrutiny of extension marketplaces, developer identities and software distribution processes.
Marketplace operators will face pressure to improve detection monitor publisher‑account activity and identify suspicious dependency changes. Enterprise software teams may increasingly adopt approved‑extension policies and stronger controls over development environments.
Developers will also need to become more attentive to extension updates and the permissions granted to their tools.
The important developments to watch will include new marketplace security controls, disclosures of compromised developer accounts, improved software provenance systems and wider adoption of tools that monitor dependencies before they enter production environments.
For software companies the cost of securing developer tools will become an important part of broader cybersecurity and supply‑chain management.
Coding extensions have become essential to software development but their convenience can conceal significant cybersecurity risks. By operating inside developer environments malicious extensions may gain access, to source code, credentials, project files and connected business systems.
The Nx Console compromise, MaliciousCorgi campaign and GlassWorm incidents demonstrate that attackers can exploit both published malicious tools and previously trusted extensions that have been compromised.
Marketplace security checks provide protection but they cannot remove every risk. Developers and organisations must also verify publishers, control extension access, monitor updates and protect credentials.
As AI coding assistants and automated development environments become widely used the importance of securing these tools will continue to increase.
The security of a software company does not depend on the applications it builds. It also depends on the tools its developers trust to build them.
Nexuswild welcomes factual corrections. Email contact@nexuswild.com with evidence and the article URL.
