← back to writing

My Therapist Said Tiny Problems Don’t Matter. These Vulnerability Chains Proved Me Wrong.

7 min read
chainingidorbacbug-bountyweb

I was invited to a bug bounty target with this scope:

target.tld
api-*.target.tld

The program packs a punch with features like AI-powered resume analysis, fine-grained RBAC for wrangling admins and users, and collaborative documentation tools that actually make teamwork less painful.

Now here’s where things get fun: I stumbled upon a bunch of tiny, seemingly harmless IDORs — basically the digital equivalent of paper cuts. Individually, they were useless. But with a bit of creativity (and a dash of information disclosure), I chained them together into something far more impactful.

Bug 1 — Reading Other People’s Documentation

The first vulnerability showed up in the document handling feature. When you uploaded a file, the system assigned it a UUID — smart move, since that makes filenames hard to guess. But then came the “Summarize with AI” option, which sounded helpful… until it wasn’t. Turns out, the “Summarize with AI” feature had a little secret. Instead of just summarizing your doc and calling it a day, it quietly created a new file — stored in a slightly different location. Here’s the breakdown:

  • target.tld/storage/uploads/UUID-FOR-UPLOADEDFILE/ — The Original File
  • target.tld/storage/uploads/summaries/7700231234/FILESUMMARY.pdf

Here’s where things got fun (or concerning, depending on your role):

  • The 770023 part was the same for everyone — basically the system’s way of saying “we’re all in this together.”
  • The 1234 was your user ID, just sitting there incrementing away like a friendly counter of poor security decisions.
  • And FILESUMMARY.pdf was your original filename, now politely converted to PDF no matter if you uploaded a .docx, .doc, .tex, or .pdf.

To confirm the vulnerability, I created a second account on the platform (acting as the attacker). I uploaded and summarized a document to observe the storage pattern and retrieve my user docs (The Victim which is 1234). Using this information, I basically sent a request to the URL below (note that my attacker ID is 1235):

curl -s target.tld/storage/uploads/summaries/7700231235/FILESUMMARY.pdf -o victim.pdf

Problem 1 — We Don’t Know the Victim Filename

At this point, I was able to retrieve document summaries from other users — as long as they had used the AI summarize feature. The catch? I had no idea what the actual filenames were. That left me with two options:

  1. Fuzz the filenames
  2. Look for a filename leak somewhere else in the application

Fuzzing was off the table due to a strict rate limit on the target, and spraying guesses would only get me rate-limited (or worse, blocked). Technically, I could’ve reported this as a classic IDOR — it was an IDOR after all. But for the first time in my bug bounty journey, I decided not to rush.

Instead, I went all in and started a proper deep dive, hunting for anything that could give me an edge.

Bug 2 — BAC Problem to Activate the ‘Auto AI Summarize’

Now, I know this part isn’t directly tied to the IDOR, but it’s worth mentioning. There was a user setting that, when enabled, would automatically summarize all your documents — both existing and newly uploaded ones — without any further action. Sounds convenient, right? Well, convenient for attackers too.

The real issue here wasn’t just the business logic flaw (like unintentionally burning AI tokens or whatever buzzword the AI folks are using this week). The real danger was that this setting essentially handed over every file summary on a silver platter — as long as an attacker knew (or could guess) your user ID. With summaries being auto-generated and stored in predictable paths, the attack surface quietly exploded.

Look at this HTTP request:

POST /api/user/settings/auto-summarize
Host: target.tld
Content-Type: application/json
Authorization: Bearer <your_auth_token>

{
  "userId": 1234,
  "overwrite": true,
  "setEnable": 1,
  "autoSummarizeEnabled": true
}

The attacker could easily change the userId and enable the auto summarize for you, then it would be available at:

target.tld/storage/uploads/summaries/7700231234/FILESUMMARY.pdf

Bug 3 — Filename Leakage Through Exhausting AI Tokens

When you click the Summarize button manually, it sends a request like this (just a rough example since I don’t remember the exact one):

POST /api/user/action/summarize/modelaction/getSummary
Host: target.tld
Content-Type: application/json
Authorization: Bearer <your_auth_token>

{
  "userId": 1234,
  "summary": "active",
  "filename": FILENAME.pdf
}

Each request consumes a small amount of tokens. So I wondered — what happens if I burn through all my tokens?

I sent this request repeatedly using Burp Intruder to see how the app would behave. My goal was to drain most of the tokens, leaving just a little bit left, and then try to exploit a race condition.

And guess what? I totally forgot to stop the Intruder — and I was painfully slow about it. Naturally, I ended up burning through all my tokens.

Then the app threw back an error that looked like this:

HTTP/1.1 200 OK
Content-Type: application/json
Content-Length: 250

{
  "error": "TokenLimitExceeded",
  "message": "You have used up all your available tokens for AI summarization.",
  "errorMessage": [
    "Cannot continue using AI for following files:",
       "project_proposal.pdf",
       "financial_report.docx",
       "meeting_notes.tex",
       "user_manual.pdf"
  ]
}

Wait a minute… if I burned through all a user’s tokens, I could actually get a full list of their filenames. Then, combining that with Bug 1, I could swap in those filenames and download all their files?

Curious, I sent the Summarize request through Repeater, changed the userId, and — surprisingly — I was able to summarize other people’s files. Turns out, there was another broken access control issue here.

The Full Exploit Chain

  1. Activate Auto-Summarize for All Users via Brute Force — Exploit weak access controls to enable the auto-summarize feature on accounts you target.
  2. Send Millions of Summarize Requests to Exhaust Tokens — Flood the system with requests on behalf of these users to consume all their AI summarization tokens.
  3. Retrieve File Names from Token Exhaustion Error Responses — Once tokens are depleted, the system leaks users’ document filenames in the error messages.
  4. Use Filenames to Exploit Initial IDOR (Bug 1) — Substitute these leaked filenames into the IDOR URL pattern to access and download the users’ documents.

Problem 2 — We Still Don’t Have the Initial Filename

We have the exploit chain mapped out, but there’s one big hurdle: we don’t have an initial filename to actually launch the attack. The summarization endpoint requires a filename to consume tokens, so without one, the whole chain stalls.

Here’s the catch: when users sign up, the app is supposed to provide them with a PDF — let’s call it userguide.pdf — to teach them how files should be named. But surprisingly, not all users actually get this file.

  • If you go through the tutorial window (that little onboarding popup in the app), you don’t get the file.
  • However, if you simply click “Skip” on the tutorial, the application assigns the userguide.pdf file for you.

So, in this case, only the “Skip” users are vulnerable to launching this exploit chain. We’re basically targeting the “Skip” gurus here :)

Although this limitation lowers the overall impact — since the attack requires some user-specific conditions and extra steps — it’s still definitely worth the time and effort given the potential data exposure.

Report

I wrote a detailed report outlining the entire exploit chain, provided a working proof of concept (PoC), recorded a demonstration video, and included extra explanations to clarify the impact and attack steps. After careful triage, the team acknowledged the severity and rewarded me with an “acceptable” bounty.

This bug was a great learning experience — it showed how chaining smaller issues together can lead to significant security risks, even when each individual flaw seems minor. I hope you found this write-up insightful and useful.

If you’re interested in following more of my bug bounty journeys and security research, feel free to connect with me on X (formerly Twitter).