Protect Your Secrets: Understanding and Measuring Data Exposure in VSCode Extensions

Extension Isolation.  VSCode employs a unique isolation mechanism for its extensions, ensuring that each extension operates within a secure and confined environment. This isolation is achieved by running each extension in a separate Node.js process, known as the extension host. The extension host is limited to using only the official VSCode APIs, which offer a restricted set of functionalities and interactions with the VSCode platform, such as the user interface or system resources. This restriction ensures that extensions cannot access certain resources. For example, extensions cannot directly access the SecretStorage API or the webviews and input boxes belonging to other extensions. This isolation prevents malicious extensions from interfering with the core VS Code application or other extensions.

System Resource Access.  Unlike some popular software systems such as Android or web applications, VSCode does not employ a traditional permission system to regulate API access. Instead, it provides a series of APIs defined by VSCode itself. These APIs are designed to allow extensions to interact with system resources in a controlled manner.

Extension Vetting.  VSCode employs a rigorous vetting process for extensions published in its Marketplace in order to ensure strong security standards. Before publication, every extension undergoes a thorough examination to check code integrity, best practices, and vulnerability absence. With each new extension submission and update, the VSCode team performs a virus scan on the extension package. This scan serves to certify the extension is free of malware or other security risks. Through this comprehensive review process, VSCode aims to provide users access only to reliable and high-quality extensions that meet strict security criteria. By adhering to these standards, the VSCode Marketplace fosters an ecosystem of trust between publishers and users. The vetting process provides assurance to users that they can integrate VSCode extensions securely into their development environments without compromising security.

Stealing Data from Extension Configuration.  Configuration is a mechanism that allows VSCode extensions to store and retrieve user preferences and settings. However, it is not a secure storage, as all the installed extensions can access and modify the current configuration, which can lead to unintended exposure of sensitive data if not properly managed. Therefore, the extension developers should not store security- or privacy-critical data on configuration. However, some extensions do not follow this best practice and expose personal credentials such as API keys, passwords, or GitHub access tokens in their configuration. This poses a security risk, as an attacker can exploit this vulnerability to steal sensitive data. For instance, popular AI-driven extensions like ChatGPT - EasyCode [9] (331k installs) store the OpenAI API key in the extension configuration, as shown in Listing 1. An attacker, through a malicious extension, can easily retrieve this API key using the vscode.workspace.getConfiguration().get() method. This could lead to financial risks as they gain unauthorized access to OpenAI’s ChatGPT models.

Stealing Data from Global State.  VSCode allows extensions access to arbitrary files on the host system without explicit user permission. This enables malicious extensions to locate and extract sensitive data stored by other extensions. One such example is the global state, a memento object that stores key-value pairs that are persisted across VSCode sessions. The global state is independent of the current opened workspace and can be used to store extension-specific data that does not change frequently. However, the global state is not isolated from other extensions, as all the installed extensions store their global state values in a file named “state.vscdb”, which is a SQLite database. An attacker can exploit this vulnerability to read, write, or delete the global state of other extensions, potentially compromising their functionality, security, and performance. For example, an attacker can use the official API, ExtensionContext.globalStorageUri, to locate the global state file and read its contents. As shown in Listing 2, an attacker can access the global state of the popular Tabnine: AI Autocomplete & Chat extension [38] (more than 6.8M installs) and extract the chat history. The chat history is stored in the global state under the key “CHAT_CONVERSATIONS”, which contains the conversations between the user and the AI models. The attacker can send this chat history to a third-party server, potentially leaking sensitive information.

Manipulating Extension Storage.  In addition to extracting data, attackers can exploit the lack of isolation in extension storage to manipulate or overwrite an extension’s configuration and states. This can sabotage functionality or redirect behaviors for malicious objectives without the user’s knowledge. This can sabotage the extension’s functionality or redirect behaviors for malicious objectives, often without the user’s knowledge. For instance, an attacker can update the configuration using the vscode.workspace.getConfiguration() .update() method. The tldrdev.discord-code-share extension [39], which allows users to send their code to Discord with a few clicks, stores the webhook URL in the configuration. As shown in Listing 3, an attacker can update this URL to point to a malicious webhook. This could lead to unauthorized access to the user’s code, posing a significant security risk.

Monitoring the InputBox Clipboard.  VSCode provides an InputBox interface for extension developers to collect user input. The InputBox interface is a simple dialog box that prompts the user to enter some text, such as a file name, a search query, or a configuration option. Although the InputBox interface is not directly accessible by other extensions, the attacker can still monitor the clipboard for complex but sensitive credentials that the user may copy and paste. One example of an extension that uses the InputBox interface to collect credentials from users is zhang-renyang.chat-gpt [48], which is the most popular ChatGPT-related extension in VSCode, with more than 667k installs. This extension allows users to chat with various AI models, such as GPT-4 and GPT-3.5, for various purposes, such as code generation. To use this extension, users need to enter their own OpenAI API key, which is a long and complex string that consists of 32 alphanumeric characters and a prefix of “sk-” (see Figure 1). Users usually copy-paste them from sources like the OpenAI dashboard into the InputBox, rather than typing them by keyboard. This behavior enables attackers to continuously monitor the clipboard using env.clipboard.readText() and steal any pasted credentials. As shown in Listing 4, the vulnerable extension uses the InputBox to collect the user’s OpenAI key, which the attacker can then access and steal by using env.clipboard.readText() when the user copies and pastes the key into the InputBox.

Stealth Command Listening and Binding.  VSCode extensions are activated by certain activation events, such as when a specific language file is opened or a particular command is invoked. It means that an extension can listen to the commands of other extensions and activate itself when they are triggered. This allows a malicious extension to stealthily bind itself to a legitimate command and perform unauthorized actions in the background, such as displaying a fake input box to collect user credentials, sending the captured data to a remote server, or interfering with the expected behavior of the original command. For instance, we exploited this vulnerability to successfully attack Github Copilot Chat [2], a popular AI programming extension developed by the GitHub Team. Our malicious extension listens for the command “github.copilot.generate”, as shown in Listing 5. When this command is invoked, our extension activates and displays an input box, tricking the user into re-entering their Github password to re-login to Github Copilot. Unwitting users, believing they are re-authenticating their session, inadvertently divulge their credentials.

Manipulating Commands for Secret Exfiltration.  Extensions can define commands to control various operations, including handling sensitive information. Other extensions can execute these operations using the official API commands.executeCommand. This can potentially lead to unauthorized access to sensitive information. For example, the CodeGPT extension [13], another AI programming assistant that supports popular models like OpenAI GPT-4 [3] and Anthropic Claude [5], has a command “codegpt.removeApiKeyCodeGPT” to let the user remove the API key. As shown in Listing 6, Attackers can execute this command, prompting the user to re-enter the API key for GPT-4 of OpenAI. The attacker can then automatically display an identical input box to collect the API key.

Extension Command Confusion.  Commands are defined based on text strings, which are used as identifiers and labels for the commands. Although VSCode does not allow extensions to register commands with the same identifier, it does not prevent extensions from using similar or confusing labels for their commands. An attacker can exploit this vulnerability by creating a command with a label that resembles a command of another extension, such as GitHub Copilot, and registering it with a different identifier. For example, an attacker can register a command with a label “GitHub CopiIot: Fix This”, where the lowercase L is replaced by an uppercase i, and use an identifier such as “attacker.fix”. As shown in Figure 2, this label looks almost identical to the original command of GitHub Copilot, which is “GitHub Copilot: Fix This”. This can create ambiguity or deception for the users, who may not be able to distinguish the commands of different extensions or may be misled to run a malicious command instead of a legitimate one. This may trick the user into running the attacker’s command, which could perform malicious actions such as stealing the user’s code, modifying the code, or redirecting the user to a phishing site.

Design.  To analyze the VSCode extensions, we need to extract all the relevant metadata and source code blocks that may contain security risks that described in Section III. We first unpack each extension into a directory, which includes the package.json file and the source code files. As described in Section II-A, the package.json file is a manifest file that describes the metadata and dependencies of the extension, while the source code files include all the necessary logic and functionality of the extension, such as how it interacts with commands, configuration, and storage. To comprehend how each extension handles credential-related data (as described in Section III), we extract the configuration and commands requested in the package.json file, and the relevant usage of commands, configuration, input box, and global state in the source code. To systematically find all the vulnerable blocks in each VSCode extension, our methodology consists of three steps: (S1) unpacking extensions and extracting metadata like requested commands and requested configuration from the package.json file, (S2) building a program dependency graph (PDG) for each source code file and tracking system API calls related to used commands, global state, input box, and used configuration, and (S3) tracking the data flow from the system API calls to the parameters and variables in the PDG.

Step S1: Unpacking Extensions & Extracting Metadata.  The analysis begins with the unpacking of the VSCode extension’s .vsix file. This file format is a packaging standard for VSCode extensions and contains all necessary files for the extension. The first step involves extracting two critical components: the package.json file and the source code files. The package.json file is essential as it holds vital metadata about the extension, including commands, configuration details, and dependencies. This metadata provides a high-level overview of the extension’s functionality and potential areas for security risks. Specifically, we extract the declared commands and configurations along with their descriptions. This allows us to catalog the requested commands and configurations that the extension can access. Simultaneously, the source code files are extracted for a detailed analysis of the implementation and internal workings of the extension.

Step S2: Building PDG.  To further enhance our understanding of the source code of an extension, we abstract it with semantic information and model the interactions within and outside of the extension. This approach enables us to perform a data flow analysis to identify potential security risks. For each extension, we construct an Abstract Syntax Tree (AST) from its source code files. The AST, representing the syntactic structure of the code in a tree format, facilitates programmatic code analysis. From the AST, we enhance it with control and data flows to construct a Program Dependency Graph (PDG). The PDG illustrates how data moves through the code, showing the dependencies and interactions between different variables and functions. This step is crucial for identifying how the extension interacts with the VSCode API. Part of this process involves locating API nodes within the PDG, which are points in the code where the extension interacts with the VSCode API. These nodes are critical in understanding how the extension uses VSCode’s features and where potential vulnerabilities might exist.

Step S3: Tracking Data Flow from System API Calls.  In this step, we utilize the PDG to trace data flows from sensitive system API calls to downstream variables and parameters. As discussed in Section III, certain VSCode APIs can expose security risks if they are used improperly for credential management. To do that, we conduct an intra-procedural data flow analysis. We identify key API nodes in the PDG corresponding to calls such as accessing configurations, global state, user input, and commands. Table I summarizes the examined API calls that are prone to exploitation described in Section III. To systematically pinpoint risks, we execute a depth-first search on the PDG rooted at each identified API node. We recursively traverse data dependencies from API call nodes to extract associated parameter values. This process reveals the specific variables and data dependencies that receive data from sensitive API calls. Through this rigorous tracking of data provenance, we obtain fine-grained insights into how extensions propagate and store data obtained from privileged VSCode APIs. This approach equips the system to precisely locate open attack vectors that exist due to improper handling of command parameters, user input, configurations, global state, and other sensitive sources.

Step D1: Feature Extraction.  In fact, commands, configuration, and input box are types of UI elements that can be used to collect user input or display information. The labels and descriptions of these UI elements can provide semantic clues about the type of data that is being handled by the extension. For example, a label like “Enter your API key” indicates that the extension expects the user to provide a credential. Similarly, the values stored in the global state can also reveal the type of data that is being persisted by the extension. For instance, a key like “CHAT_CONVERSATIONS” suggests that the extension stores chat history. We obtain these textual features from two sources: the metadata and the PDG. From the metadata, we extract the requested commands and requested configurations along with their descriptions. From the PDG, we extract the used commands, used configuration, global state, and inputbox along with their labels and parameters. These features form the input for our data classification model.

Step D2: Training Data.  To train our data classification model, we need a labeled dataset of VSCode extensions and their exposed data types. However, such a dataset does not exist, so we manually create one by sampling 500 extensions from the official marketplace (see Section V). We inspect the source code and metadata of each extension and label them with one of the following two categories: (1) credentials-related, such as API keys, passwords, access tokens, etc., (2) others that are not sensitive, such as code snippets, configuration options, etc. We use the text features extracted from the UI elements and global state keys as the input for each extension, and the corresponding label as the output.

Step D3: Text Classifcation.  Finally, we use a text classification model to learn the semantic patterns and associations between the text features and the data types. We use a pre-trained BERT model [15] as the backbone of our classifier, as it has shown state-of-the-art performance on various natural language understanding tasks. We fine-tune the BERT model on our labeled dataset, using a linear layer on top of the BERT output to predict the data type label.

False Positives and False Negatives.  The false positive rate is 6.98% (39/444), where the model failed to identify a data point as credential-related when it actually was. Most false negatives had unusual credential formats that did not match the learned patterns. For instance, “haasStudio.wifiSsidPwd” was one such case where the credential format was not recognized by the model. Additionally, credentials in languages other than English, such as Chinese, posed challenges for the model. The false negative rate is 0.24% (39/16,512), where the model misclassified normal data points as credential-related. We found two main reasons for these errors: (1) some contain vague keywords like “token” and “key” which are not necessarily credential-related. (2) some data points contained credential-related words but were used for non-sensitive purposes, such as “toolsHeavenChatGPT.authenticationType” or “cloudcode.secrets.createVersionWithText”. Such false positives could be reduced by incorporating more contextual information or using a more fine-grained classification scheme. Nonetheless, the false positive rate is sufficiently low to demonstrate strong performance.

Landscape.  Our study reveals that the issue of potential credential leakage is widespread across the VSCode extension landscape. Out of the 27,261 extensions analyzed, we identified 2,325 extensions that could potentially leak credentials. This represents approximately 8.5% of the total extensions analyzed, indicating a significant prevalence of this issue. Furthermore, each of these extensions was found to have an average of 2.11 data items that could potentially lead to credential leakage. This suggests that the risk is not confined to a single data item within an extension, but rather, multiple data items within an extension could potentially contribute to this risk. These results underscore the critical need for effective measures to detect and mitigate the risk of credential leakage in VSCode extensions. They also highlight the importance of our approach in providing a systematic and efficient means of identifying potential data exposures in a large-scale and diverse dataset of VSCode extensions. This can significantly aid in enhancing the security and privacy of these extensions, thereby protecting the sensitive data of their users.

Exposed Types.  Table II presents the analysis of different vectors causing credential exposure in VSCode extensions. Firstly, potential storage access leaks were identified in 1,599 extensions through global state and configuration. Specifically, 316 extensions (18% of those using global state) leaked credentials via the globalstate API, with each exposing 1.38 unique data items on average. This indicates global state is a common vector for storing and propagating sensitive credentials. Additionally, requested and used configurations revealed credentials in 1,205 (9.6%) and 295 (2.7%) extensions respectively. While lower than globalstate, these configuration leaks still pose worrying risks considering the large user base. Lastly, in the category of credential control by commands, there are 724 extensions that potentially leak credentials. Within this category, 2.7% of extensions requested commands and used them to control credential-related data. These results demonstrate the various ways in which VSCode extensions can expose sensitive data, highlighting the need for effective security mechanisms to prevent such exposures.

Exposed Contents.  Figure 4 presents the word cloud of exposed data items. It is evident that “password” and “apikey” are the most frequent words among the credential-related data, indicating that these are the most common types of credentials that could be leaked by VSCode extensions. Interestingly, AI-related keywords like “openai” and “chatgpt” also appear in the word cloud. This suggests that as AI-driven extensions like GitHub Copilot [2] and Microsoft IntelliCode [29] become increasingly popular, the risk of exposing AI-related credentials also rises. This trend underscores the need for heightened security measures in AI-driven extensions, particularly those that require sensitive credentials for operation. The word cloud also reveals a variety of other potential credential leaks, demonstrating the diversity of data that can be exposed in VSCode extensions.

Data Exposure based on Extension Categories.  To further understand the distribution of data exposure risks across different types of extensions, we grouped the identified 2,325 extensions based on the categories used in the VSCode marketplace. Table III shows the number and percentage of extensions that potentially leak credentials in each category. Our findings are surprising, as the percentage of exposed extensions varies significantly between categories. For example, common categories such as “Keymaps”, “Formatters”, and “Themes” had much lower rates than the overall average of 8.5%. On the other hand, Machine Learning extensions had the highest rate of 40.84% - almost five times the average. Similarly, Data Science and Education extensions also had high rates of 37.95% and 23.44%, respectively. The high exposure rate in AI/ML domains likely originates from their dependence on external services like OpenAI, Anthropic, and Google, which necessitate authentication. This is particularly alarming considering the growing popularity of AI-based tools. Moreover, we observed that categories related to security and infrastructure, such as Testing (23.78%), SCM Providers (28.03%), and Azure (18.48%), also had higher-than-average vulnerability rates. This is likely due to the frequent use of credentials to authorize access to repositories and cloud services. In conclusion, our results show that data exposure risks are strongly associated with certain VSCode extension categories that involve emerging technologies and security features. As the IDE evolves to support specialized domains like ML and cloud engineering, it is essential to protect credentials and secrets from leakage and prevent serious privacy and infrastructure threats.

Data Exposure based on Extension Popularity.  Figure 5 illustrates the distribution of extensions exposing credentials relative to the number of installations. Out of the 2,325 extensions detected, more than half (1,441 extensions) have fewer than 1k installations. As the number of installations increases, the number of impacted extensions decreases. However, the percentage of affected extensions gradually increases. Interestingly, despite only detecting 25 affected extensions with more than 1M installations, the percentage of these extensions is the highest at 10.73%. This suggests that popular extensions are not immune to data exposure risks, emphasizing the need for robust security measures regardless of an extension’s popularity.

Data Exposure in AI Coding Assistants.  AI coding assistants are a new trend in the IDE ecosystem, as they aim to help developers write code faster, smarter, and easier. These tools leverage powerful AI models like GPT-4 [3], Claude-2 [5], and Gemini Ultra [8] to generate code snippets, suggest code completions, answer coding questions, and even chat with developers [14]. As we described before, however, these AI coding assistants also pose potential data exposure risks, as they may require or leak sensitive credentials for accessing AI services, APIs, or repositories. Therefore, in this section, we focus on these AI coding assistants in the VSCode ecosystem. We used common keywords (i.e., “ai code”, “code completion”, “gpt”, “openai”, “intellicode”, “autocomplete”, “language model”, and “chatbot”) to search the descriptions and tags of the extensions in our crawled dataset $D_{t}$. We found 179 extensions that fall into the category of AI coding assistants and detected 97 extensions that potentially leak credentials. This represents 54.2% of the AI coding extensions, which is much higher than the overall average of 8.5%. Figure 6 shows the published year of the AI coding assistants and their exposed rate. It is obvious that AI coding is increasingly popular, especially from 2022, and only in 2023, there were more than 100 new AI coding assistants published in the marketplace. Also, the rate of exposed credentials also increased. For instance, the rate for newly published extensions in 2023 increased to 70%. Among the AI coding assistants that could expose credentials, we found that 24 extensions store credentials in GlobalState, including 11 extensions with “chatgpt-gpt3-apiKey” and “chatgpt-session-token”. Furthermore, 71 AI coding assistants store the credential data in the configuration. This highlights the need for careful handling and secure storage of credentials in these extensions.