How I stumbled into my first “AI-powered” bug bounty target and found that an AI chatbot’s memory…

For years, my bug bounty muscle memory looked the same: pick a web app, poke the API, look for the usual suspects — broken auth, XSS , IDORs, SSRF, the greatest hits. Comfortable. Predictable.

Then AI features started showing up everywhere. Chatbots bolted onto e-commerce sites, "Ask AI" buttons on banking dashboards, trip-planning assistants on travel platforms. Everyone was racing to ship the shiny new chat box. And I had a hunch: when teams move fast to ship an AI feature, the access control around the boring, unglamorous parts — like "who's allowed to read this saved conversation?" — is exactly the kind of thing that gets rushed.

So for the first time, I picked a target specifically because it had an AI chatbot: a flight search and booking platform with a feature called AI Mode, which lets you type things like "flights to London this October" into a chat box and have an assistant build your itinerary. Every conversation you have with it gets saved server-side, tied to an ID, so you can come back and pick up where you left off.

That last sentence — "saved server-side, tied to an ID" — is where this story starts.

The Feature Nobody Thinks About

Most people testing an AI chat feature focus on the AI part: prompt injection, jailbreaks, getting the model to say something embarrassing. Fun, but crowded territory.

I went the other direction and asked a much less glamorous question: once my conversation is saved, what actually stops someone else from reading it back?

To find out, I opened the browser dev tools and just used the feature normally — typed a flight search into the AI box and watched the network traffic. Sure enough, a GraphQL request fired off to fetch my conversation history, referencing it by a UUID. Nothing unusual so far; that's how most stateful chat features work.

The interesting part was what wasn't there. I expected some kind of session or ownership check tying that UUID to me specifically. Instead, the request that fetched conversation history took exactly one input: the conversation ID itself. No embedded proof that the requester was the person who created it.

That's the shape of a classic IDOR — Insecure Direct Object Reference — and it's the same bug that's been quietly living in web apps for two decades, just wearing a new AI costume.

"Wait, There's a Token Though"

Before getting excited, I did what I always do: assume I'm missing a guardrail somewhere and go looking for it.

There was one: every request to this endpoint carried a custom validation header, clearly meant to act as a gate. My first assumption was that it was some kind of signed, server-issued proof — the kind of thing that would make this a dead end.

So I did what you do with any client-side JavaScript: read it. And what I found was the header wasn't a secret token issued by the server at all. It was a hash computed entirely from values the browser already had — a build identifier baked into every page load, a visitor cookie assigned to anyone who shows up, and the contents of the request itself.

In other words: the "lock" on the door was a padlock where the combination was printed on a sign next to it. Anyone could compute a valid token for any request, including one asking for someone else's conversation, as long as they had their own (freely issued, anonymous) visitor cookie.

That's the moment a "huh, interesting" bug turns into "wait, I think I can read a stranger's data."

Proving It, Carefully

Bug bounty rule number one: never touch anyone else's actual data. So I built the whole proof of concept using two identities that were both mine — one browser profile playing "the victim," a separate anonymous session playing "the attacker," and nothing in between but the vulnerability itself.

The victim profile used AI Mode normally: typed in a flight search, got a conversation saved on the server.

The attacker profile never talked to the victim profile at all. It didn't need to. All it needed was:

1. The victim's conversation ID (in a real attack, something that can leak through referrer headers, shared devices, logs, screenshots, or support tickets — UUIDs travel more than people assume)
2. Its own, completely unrelated visitor cookie
3. A locally computed version of that "validation" hash

With those three things, the attacker session asked the server for the victim's conversation — and the server handed it over. Full chat history. The victim's search: where they were flying from (often a strong signal for home city), where they were headed, exact travel dates, passenger count, and any free text they'd typed to the assistant.

The server never once asked "does this requester actually own this conversation?" It only asked "is this hash shaped correctly?" And since the hash was made of public ingredients, the answer was always yes.

I also tried to see if the same weakness let me write to someone else's conversation — inject messages, tamper with their itinerary. It didn't; that path was properly rejected. Small mercy: this was a read-only hole, not a read-write one. Still bad, but not catastrophic-bad.

Why This One Bugged Me More Than a Typical IDOR?

First, the "victim" doesn't need an account. This wasn't gated behind login. Every anonymous person who used the AI trip planner — which is presumably most of them, since it's a public marketing feature — had a conversation sitting there, readable by anyone who got hold of the ID. No password to guess, no session to hijack. The barrier to entry for the victim was simply "used the website."

Second, the data itself is unusually personal for a "just an API bug." A leaked order ID tells you someone bought something. A leaked AI travel conversation tells you where someone lives, when they're leaving town, and sometimes — because people talk to chatbots more casually than they fill out forms — why. "Visiting my parents," "business trip Monday," that kind of thing, typed straight into a text box that felt private because there was no reason to think otherwise.

That's the quiet danger of AI features: they invite people to type more candidly than a search bar ever did, while sitting on the exact same access-control plumbing as everything else on the site — plumbing that, in this case, had a hole in it.

What I Reported:

If you're moving into this space for the first time like I just did, here's the shift in mindset that actually paid off: don't just attack the model — attack the plumbing around it.

Everyone's staring at the chatbot, trying to make it say something it shouldn't. Fewer people are asking the unglamorous questions: How is this conversation stored? What ID points to it? What, if anything, actually checks who's asking? Those questions aren't AI-specific at all — they're the same access-control fundamentals we've always tested — but they're getting shipped inside AI features faster than teams are re-applying old lessons to new surfaces.

The novelty of the feature doesn't make the bug novel. It just makes it easier to miss.

This was my first vulnerability found on an AI-powered target, reported through a private bug bounty program $$$$.