$1,500 AI System Prompt Leak: Using this Burp Suite Configuration

Akwaaba! guys. I've finally got around to putting this one together. As usual, some of my good works $1,500 Email Verification Bypass and How to Leak OTP code to bypass 2FA. Let's goo!

‼️ Disclaimer: I've changed specific details about the application in this write-up for confidentiality. Even the screenshots shown are from a different, similar application that doesn't have a bug bounty program — they're only used for illustration. Also, all API endpoints mentioned have been altered to avoid revealing the actual program.

==Skip this==

I've had this draft sitting in my backlog for a while. I wasn't sure how to frame this finding in a flashy way; because, honestly, it isn't flashy. I didn't hack anything. I simply looked. With a bit of luck, I cashed out. It made me realize just how much I've been missing out on, all because of how I had my Burp Suite configured. This will be a short one, but I'll try to make it as interesting as possible.

The Program

This is your typical modern company that has fully embraced AI and rolled it out across all their assets. On one of their domains, app.target.com, there's an AI chatbot feature. And I'm not talking about a basic support bot. This is a full, interactive AI chatting system capable of handling complex conversations.

The Vulnerability

I discovered that a third-party domain was exposing all of the company's AI model system prompts. The same endpoint also leaked a complete list of internal employee emails and UUIDs.

Read decompiled code of Android App and Exploit Deep Links

A Common Burp Suite Mistake

Normally, when you have a target, the first instinct is to head straight to the Target¹ tab in Burp Suite to filter out the noise from all the other domains in your HTTP history.

Over there, we head to the Scope section. And if you're like me, you check the Use advanced scope control² checkbox, paste the target domain³ into the Host or IP⁴ range field, and hit OK⁵.

You probably get hit with that prompt: "Some items are out of scope. Stop showing them in the HTTP history?" And if you're like me, you instinctively hit "No". Why? There might be something useful hiding in those out-of-scope domains; an overlooked endpoint, a misconfigured service, a breadcrumb worth following. But to be honest: I never actually check those domains. They just sit there, quietly filling up my history, ignored and forgotten until I clear them out.

Finally, you go to the HTTP History. Filter Settings¹ → Show only in‑scope items². And once that's set, you can toggle it³ on and off with a single click without opening the Filter Settings again.

There's nothing really wrong with this setup. But there's a blind spot that comes with it. You're likely to miss discoveries happening in requests to third-party domains (the ones you filtered out). This write-up is a case study in how luck, rather than skill, helped me to realize it.

That time I got paid $500 for an OAuth Account Fusion problem (It was easy)

How I identified the Vulnerability

I was testing for Blind XSS in the AI chat box, that's what got me interacting with it in the first place. Through all this, my HTTP history only showed requests being made to *.target.com. I'd occasionally peek at the WebSocket history, but nothing out of the ordinary stood out.

Then I lost track of a request. I couldn't find it in the filtered view, so I decided to toggle the filter OFF to reveal everything, including the noise. Then I saw an API request being made to a third-party domain. The response looked like JSON, but the MIME type was SSE.

The request endpoint wasn't something any fuzzing tool could have spotted because no wordlist out there probably contains anything like it. It looked like an MD5 hash followed by what appeared to be an incomplete JWT. Something like: /eval/5d43bjskk3si2898sbjh33/eyJksgrlEilenslrUwNebs3iW9…

One thing I noticed immediately is the request URL always began with /eval/, and in some cases /sdk/evalx/. The response always started with something like event:put.

As I scrolled through the response, I saw four different system prompts. One belonged to the chat box, another to an internal AI reviewer for recruitment, and two more were for AI agents that assessed employee profiles. Alongside them was a comprehensive list of internal email addresses and URLs.

I quickly reported this and it didn't take them long to confirm this shouldn't be public.

So, what am I saying?

Watch for AI systems making requests to*.launchdarkly.com. Add it to scope. Toggle the filter off regularly because out-of-scope domains and WebSocket History can hold gold.

Now, I leave the HTTP History raw with all the noise until I am sure the application didn't rely on outside domains.

Yet another classic $500 UUID IDOR

Impact and Payment

The program team was surprised at how I came across this (and so was I honestly).

The leakage of internal employee emails and System Prompt was considered PII by their team due to the nature of their platform. This was rated HIGH and I was rewarded $1,500.

This all looks like one big lucky find except I've since discovered AI system prompt leaks of this exact nature in two more programs. So maybe it wasn't luck after all. Maybe it's a pattern worth paying attention to. Either way, I won. And on to the next one.

$2000 Web Cache Deception to Steal Access Tokens, I did that.

Hey…

Thanks for reading this, if you have any questions, you can DM me on X @tinopreter. Connect with me on LinkedIn Clement Osei-Somuah.