How I Found My First LLM Vulnerability and Escalated it to Admin Access

I started accessing this site as part of a Vulnerability Disclosure Program and there are multiple AI chatbots which is the sole purpose of this application. There are multiple chatbots deployed with the different available tools provided by the application. So, I started creating a session for a chatbot that got already deployed with one of the tools called file read tool which is selected for this specific chatbot.

So before I even thought of try for revealing system prompt it's already there during the session creation. The file read tool is the important part here. So I Immediately started chatting with this bot to read files as the file read tool is present. I started to ask the bot to read for application configuration files for which it said it cannot read due to security guard rails.

So I went to Claude and I gave it all the context and asked it what files I could try to read initially which won't be blocked by LLM if there are any misconfigurations in the file read tool so it gave me to try reading requirements.txt file and so I did and it's my first hit!!!

Now I got an idea, previously when I tried to read the app configuration file it rejected but what if I try to read one acceptable file and one non-acceptable file maybe I could confuse the AI into reading both the files and to my prediction it did! and hit a Goldmine!!!

I got an Azure API Key , Private key ID, Google service account and it's associated secret access key and key ID.

This goes on for few more files until I hit the real jackpot which is k8s Kubernetes configuration file, when I read it I got secret API key which is LITE LLM service API Key where they manage all the LLM's hosted on that application.

I got AWS Bedrock token, and multiple other sensitive things and out of all LLM gateway service made me curious about because I got the Secret API key and usually in configuration files it'll be admin access keys so I quickly checked the URL with the secret key I got and boom I got proxy admin access over that LLM gateway service.

So I Immediately checked everything that I could access and digging further more I got all endpoint mapping from openapi.json endpoint.

I got to know I can create or delete any LLM connection in the application across different tenants and to prove this instead of deleting any existing LLM I created one myself and deleted it for Proof Of Concept.

Since I have admin access I can create or delete which ever LLM connection I want and I can delete every LLM connection in the application across multiple tenants.

I wanted to test and Push further to get something more interesting as there are endpoint /health/connection which is potential SSRF endpoints to test for. When I tested it with burp colloborator payload it says api_base is not allowed which is a patch for CVE-2024–6587.

But this patch can be bypassed. Checkout more about this bypass from here: https://www.google.com/amp/s/escape.tech/blog/how-escape-exploited-ssrf-in-litellm/amp/ and I followed similar technique to bypass it as follows.

It made an Out Of Band connection to my burp proving SSRF. I never thought I'd find a simple misconfiguration which could lead to this far.

After all this I wanted to know the root cause so that I can report this for my bug bounty and it's nothing but classic excessive agency which led to overly permissive file read tool access for LLM on /app root directory.

As per August 2026 this issue is no longer replicable and published only after fixing the issue.