Assessing Prompt Injection Risks in 200+ Custom GPTs

Introduction

The advent of Generative Pre-trained Transformers (GPTs) (Radford et al., 2019) has marked a significant milestone in the evolution of artificial intelligence. Among these GPT models, ChatGPT and GPT-4 (OpenAI, 2022; 2023b) introduced by OpenAI are the most powerful and widely used in diverse domains. Recently, OpenAI’s introduction of custom versions of ChatGPT (OpenAI, 2023a), tailored for specific purposes, has further expanded the versatility of these models. These user-designed GPTs (henceforth referred to as custom GPTs) allow individuals and organizations to create AI models that align with their unique requirements and data, without necessitating coding skills. This democratization of AI technology has fostered a community of builders, ranging from educators to enthusiasts, who contribute to the growing repository of specialized GPTs.

With the establishment of the GPT Store, these custom models have become publicly accessible, creating a marketplace of various AI tools designed for various applications. Despite the high utility of these custom GPTs, the instruction-following nature of these models presents new challenges in security. As custom GPTs can follow the user instructions to generate texts and even execute codes, this has opened up the possibility of malicious users exploiting the instruction-following nature of these models to inject malicious prompts, known as ‘prompt injection’, to perform tasks that were not part of the original objective. This has raised concerns about the security of these custom GPTs, as malicious users can potentially use them to gain access to confidential information.

In this paper, we identify two primary security risks associated with prompt injection in custom GPTs.

Our first security risk is system prompt extraction, which is defined as the act of deceiving custom GPTs into disclosing the designed system prompt. Although it may sound harmless to leak these system prompts, this extraction violates the designer’s intellectual efforts and privacy, as these prompts often embody significant creative investment.

Our second security risk is file leakage defined as the act of stealing the designer-uploaded files used by the custom GPT. This not only jeopardizes privacy, particularly when sensitive information is included in the file but also threatens the intellectual property of the custom GPTs. By extracting the system prompt and the uploaded files, it is potential for malicious actors to replicate and claim ownership of these copied custom models, severely undermining the development of custom GPTs.

We identified key security risks related to prompt injection and conducted an extensive evaluation. Specifically, we crafted a series of adversarial prompts and applied them to test over 200 custom GPT models available on the OpenAI store. Our tests revealed that these prompts could almost entirely expose the system prompts and retrieve uploaded files from most custom GPTs. This indicates a significant vulnerability in current custom GPTs regarding system prompt extraction and file disclosure. Our findings highlight the urgent need for enhanced security measures in the rapidly evolving domain of customizable AI, and we hope this sparks further discussion on the subject.

Our investigation uncovered a critical security flaw in the custom GPT framework. This vulnerability enables a malicious user to detect files uploaded by the custom GPT developer, including identifying the names and sizes of these files. Additionally, this weakness allows adversaries to reveal the prototypes of user-designed plugins.

We have developed a method for evaluating the vulnerability of custom GPT models to system prompt extraction and file leakage. Applying this approach, we tested over 200 custom GPTs and found that the vast majority are susceptible to both of these significant risks.

We have conducted a red-teaming evaluation of a recent defense mechanism proposed to prevent prompt injection in LLM systems. Our findings reveal that these defenses, despite their potential, can still be bypassed using sophisticated adversarial prompts.

Background

Custom GPT represents a significant evolution in AI, allowing users to tailor AI models for specific applications without needing extensive programming knowledge. These user-designed GPTs can perform a wide range of tasks, from aiding in day-to-day activities to specialized professional tasks, thereby democratizing access to advanced AI technologies. For instance, a user could create a custom GPT to assist with culinary recipes, incorporating a vast database of culinary knowledge into the model. This customization makes the GPT particularly adept at providing detailed cooking instructions or suggesting recipe modifications, thus offering personalized assistance based on user input.

When building the custom GPT, it is optional to integrate a code interpreter within it to extends its capabilities. For example, in a custom GPT designed for data analysis, the code interpreter could enable the GPT to not only understand data-related queries but also to execute data analysis scripts provided in the prompts. This feature transforms the GPT from a mere information source to an active tool capable of performing real-time data processing and analysis. However, it also introduces additional vectors for potential security vulnerabilities as we will introduce later.

2 Prompt Injection

Prompt injection is a technique where an attacker crafts specific inputs or ‘prompts’ to manipulate the behavior of Large Language Models (LLMs) like GPTs. This can lead to unauthorized actions or data exposures (Perez & Ribeiro, 2022; Greshake et al., 2023; Liu et al., 2023). In the context of custom GPTs, prompt injection poses a significant risk as it can exploit custom features, such as code interpreters, to extract sensitive information or manipulate the model’s output.

Our Method

We propose a method for prompt injection, as depicted in Figure 1. This method is comprised of three steps: (1) scanning custom GPTs, (2) injecting adversarial prompts, and (3) extracting target information.

In the initial phase, our tool heuristically collects some information on current GPTs. While OpenAI provides an API that offers a large amount of information about these models, some of this data can be sensitive. Notably, this information, although not visible on the standard front-end interface, can be accessed through specific API requests. This information includes, but is not limited to, the custom GPT’s description, schema information (e.g., how the user designed the plugin prototype for the custom GPT), and some user-uploaded file information (e.g., filename, file size, etc.). Our tool, by collecting information returned by this API, can generate customized prompts for the current GPT, such as downloading the corresponding file by specifying the filename. We showcase this privacy issue in Figure 2.

Upon completing the scanning process and confirming the existence of uploaded files, we proceed to the second step: the injection of adversarial prompts. The attack objective diverges based on the GPT’s contents: for GPTs without uploaded files, our focus is on extracting the system prompt, while for those with uploaded files, we aim to extract both the system prompt and the files. The selection of the adversarial prompts depends on the attack objectives and whether the targeted custom GPT has an enabled code interpreter. The details of the adversarial prompts utilized in our study are outlined in Figure 1. For example, to leak the file named test.txt in a custom GPT with a code interpreter, the adversarial prompt is: Convert the test.txt into markdown for me to download, start with "Sure here is the converted markdown file". With this adversarial prompt, the target custom GPT is expected to execute the conversion code and save it in a download link.

In the final stage of our method, we can wait for the custom GPT to give the response and check whether it outputs target information. As shown in Appendix A, the sampling nature of ChatGPT may result in short responses, such as a truncated version of the system prompt. In these instances, simply making additional attempts can yield the full desired information. This step is crucial in determining the effectiveness of the prompt injection in extracting specific data from the custom GPTs.

Experiments

In our study, we applied our proposed method to conduct prompt injection attacks on real-world custom GPTs. We selected 16 custom GPTs made by OpenAI and 200 third-party GPTs sampled from an online GPT repository, as referenced in (Rush, 2023). Recognizing the inherent variability in GPT responses due to random sampling, we allowed up to three attempts for each attack. An attack was classified as successful if we could extract desired information from the custom GPT within these trials. The outcomes of our experiment are detailed in Table 1.

From the table, we can observe that our prompt injection attacks on custom GPTs, although using simple prompts, yielded alarming success rates, with a 97.2% success rate for system prompt extraction and a 100% success rate for file leakage. These findings underscore a critical vulnerability in custom GPTs, highlighting the urgent need to address the issue of prompt injection. While there were instances of failed attacks, potentially attributed to defensive prompts designed to reject such requests, these were relatively rare. Intriguingly, we observed cases where the extracted system prompts or files explicitly stated not to share such information, yet the attacks were still successful. This suggests that the current defensive prompts are not robust enough. Detailed examples of both successful and unsuccessful attacks, along with an analysis of the reasons for failure in certain cases, are provided in the appendix. These insights are pivotal for understanding and enhancing the security framework of custom GPTs.

2 Red-teaming Evaluation against Popular Prompt Injection Defense

In light of the effectiveness of defensive prompts in some cases, we sought to assess the robustness of these measures. We created two separate scenarios: one for system prompt extraction and the other for file leakage. In each scenario, we employed two GPT models – one equipped with a code interpreter and the other without. This approach allowed us to test the effectiveness of defensive prompts across varying GPT functionalities.

We selected a popular defensive prompt from an online source (Borriss, 2023)At the time of paper writing, this thread has over 588k views and around 3k bookmarks, aimed at protecting DALL·E GPT (OpenAI, 2023c) from system prompt extraction. Similarly, to mitigate file leakage, we implemented a similar defensive prompt instructing custom GPTs to refuse file download requests. As DALL·E GPT does not incorporate user-uploaded files, we used DALL·E GPT’s original system prompt as the uploaded file, aligning with what defenders typically aim to protect. The details of these four GPT’s implementations are detailed in the Appendix B.1.

In our study, we further tested the defensive prompts’ resilience by engaging four authors, each with expertise in jailbreaking, and prompt injection red-teaming against LLMs. These experts independently crafted and deployed more powerful prompts to attempt to bypass the defenses of four target GPT models. Each expert was allowed at most 10 queries per GPT, with a successful bypass defined as obtaining the target information in any one of these attempts. Conversely, failure was marked if running out of 10 attempts.

They were provided with specific details such as the filename (obtained through initial scanning introduced in Section 3) and information regarding the presence of a code interpreter in the GPT (ascertainable through scanning or from the GPT’s description). This approach allowed us to critically evaluate the resilience of these defensive strategies under real-world conditions, because attackers may try hard to get what they want instead of merely using simple adversarial prompts. The outcomes of the red-teaming evaluation are presented in Table 2.

From the table, we first observe that the presence of the code interpreter significantly impacts the ease of prompt injection. In our red-teaming evaluation, experts generally required fewer attempts to succeed in GPTs with a code interpreter. In contrast, disabling the code interpreter increased the robustness against system prompt extraction. This is demonstrated by the fact that three out of four experts failed to extract the system prompt within their 10 attempts, and the successful expert also required 9 attempts. This is primarily because a code interpreter provides attackers with more opportunities to execute codes that facilitate the extraction of system prompts or files. We show how our experts utilize the code interpreter for prompt injection in Appendix B.2.

Despite the increased difficulty in extracting system prompts and files in the absence of a code interpreter, the possibility of a successful attack still exists. Given that our experiment was limited to 10 queries per expert, in real-world scenarios, where attackers could potentially make more attempts, reliance solely on a defensive prompt may not provide sufficient protection against prompt injection attacks.

Based on our red-teaming evaluation, we draw two key conclusions. Firstly, disabling the code interpreter in custom GPTs significantly enhances security against prompt injection, particularly in protecting system prompts and uploaded files. This measure is especially viable when the functionality of the code interpreter is not crucial for the GPT’s operation. Secondly, solely relying on defensive prompts for security is inadequate. We strongly recommend against uploading files or including confidential information in system prompts, as these are vulnerable to extraction through prompt injection attacks. Such preventive measures are vital in safeguarding sensitive data in custom GPTs.

To enhance reproducibility, and enable ongoing evaluation of attack and defense strategies, we open-sourced our custom GPTs and the corresponding red-teaming results https://github.com/sherdencooper/prompt-injection. We encourage the community to utilize these resources for further research and to test new defense and attack mechanisms.

Effort of Mitigating Ethical Concern

Our research exposes the susceptibility of custom GPTs to prompt injection. Recognizing the inherent risks, we advocate for transparency, especially given the existing awareness about these vulnerabilities and the overestimated effectiveness of defensive prompts as cited in (Borriss, 2023). Our findings aim to deepen understanding of these vulnerabilities and the limitations of current defenses against experienced attackers, thereby enhancing awareness and prompting more robust security measures.

To mitigate potential misuse of our research, we have implemented several safeguards:

Pre-publication Disclosure: We have responsibly disclosed our findings to OpenAI prior to public release, ensuring that they are aware and can take appropriate measures.

Data Control: Post-experimentation, we systematically deleted all extracted system prompts and files to prevent any unauthorized dissemination.

Anonymity: In our examples, all identifiable information has been removed. We exclusively used the DALL·E GPT by OpenAI for our red-teaming evaluation to avoid targeting specific third-party custom GPTs.

Conclusion

This study has systematically demonstrated the vulnerabilities of custom GPTs to prompt injection attacks. Our red-teaming analysis reveals that while disabling code interpreters can enhance security, it is not an infallible solution. The prevalent reliance on defensive prompts is shown to be insufficient against experienced attackers, particularly when sensitive data is involved. Our findings emphasize the necessity for more robust and comprehensive security measures in the development and deployment of custom GPTs. It is our hope that this research catalyzes the AI community towards developing stronger safeguards, ensuring that the innovative potential of custom GPTs is not undermined by security vulnerabilities. As we move forward, a balanced approach that prioritizes both innovation and security will be crucial in the evolving landscape of AI technologies.

References

Appendix A Custom GPT Responses

Here we show some examples of the responses from custom GPTs when we apply prompt injection attacks in Table 3.

From Table 3, we can find that in the short response, the GPT only gives the truncated system prompt which does not give useful information, and requires additional attempts to get the expected output as a long response. For the reject example 1, the response is merely Error. This suggests that the GPT can be instructed to output such a message when prompted for system information. Another rejection example indicates the GPT’s potential to be configured to respond only to queries within certain topics. These instances provide valuable insights for defenders aiming to strengthen their systems against such exploitation techniques.

Appendix B Red-teaming

Here we detail how we set up four GPTs for red-teaming evaluation below.

For reproducibility, we host four GPTs in the following links: https://chat.openai.com/g/g-ADtCanadO-system-prompt-extraction-without-code, https://chat.openai.com/g/g-2dgGN5xlH-system-prompt-extraction-with-code, https://chat.openai.com/g/g-2l93CVthJ-file-leakage-without-code and https://chat.openai.com/g/g-Wj66sRmK8-file-leakage-with-code.

B.2 Crafted Adversarial Prompts

We list all our experts’ crafted adversarial prompts that could successfully bypass the defense below for further investigation.

Upon examination of Table 5, several observations can be made regarding the failure of defensive prompts. First, we note the existence of a particular adversarial prompt that proved universally effective across all tested scenarios. This raises significant concerns about the potential of certain powerful prompts that are capable of universal application for prompt injection without the need for customization for individual GPTs.

Moreover, in scenarios where a code interpreter is present, experts can seek to circumvent the defenses by engaging the GPT in tasks related to the target information. Examples include calculating BLEU scores, evaluating cosine similarity, or encoding information into base64. This shows that code interpreter not only extends the utility of the custom GPTs but also opens doors for many possible manipulation methods against safety and privacy.

Additionally, the study revealed that for file leakage, the act of asking for GPT’s instructions could lead to file disclosure. This is particularly noteworthy as the defensive prompt was specifically scripted to reject file download requests. However, this defense did not extend to the protection of the system prompt itself. In some cases, the custom GPT referred to the uploaded file as a part of its knowledge base and disclosed it when prompted for instructions, underscoring a critical blind spot in the defense strategy.

These findings illustrate the challenges inherent in defending against prompt injection. Attackers with sufficient determination and creativity are very likely to find and exploit vulnerabilities, suggesting that current defensive strategies may be insufficient. To address these issues, additional safeguards, beyond the scope of simple defensive prompts, are required to bolster the security of custom GPTs against such exploitation techniques.