Post cover image

September 28, 2026

I Found a LiteLLM API Key in a Publicly Accessible .env File on a NASA Subdomain

Sometimes you don’t need a complicated exploit to find something interesting.

By Hangga Aji Sayekti

4 min read

While doing routine web reconnaissance against a NASA-hosted application, I was checking for some common files and endpoints that occasionally get exposed by misconfigured web servers.

One of them was:

https://[REDACTED]/.env

And it worked.

The server returned the .env file directly, without authentication or any special request.

At first, finding an exposed .env file is already enough to raise an eyebrow. But then I looked at what was actually inside it.

Among the configuration variables was a LiteLLM API credential.

That made the finding considerably more interesting.

What's inside the .env file?

The response contained configuration related to a LiteLLM proxy, including:

None

The important detail is that this wasn't simply an application setting such as:

APP_ENV=production
DEBUG=false

It included a credential used for communication with another service.

And that's where things get interesting.

A quick introduction to LiteLLM

If you're not familiar with LiteLLM, think of it as a gateway or proxy for LLM APIs.

An application doesn't necessarily have to communicate directly with OpenAI, Anthropic, or another LLM provider. Instead, it can send requests to a LiteLLM proxy, which handles the communication with the underlying provider.

A simplified setup looks like this:

Application
     |
     | API request
     | + API key
     v
LiteLLM Proxy
     |
     +----> LLM Provider A
     |
     +----> LLM Provider B
     |
     +----> LLM Provider C

Depending on the deployment, the proxy can provide centralized authentication, model routing, usage tracking, budgets, and access control.

So a variable like:

LITELLM_PROXY_API_KEY=...

is not something you would normally want sitting in a file that anyone on the internet can download.

How should the API key be used?

The key is generally meant to be used by the application's backend.

For example, the backend can load it from an environment variable:

LITELLM_PROXY_API_KEY=...

and then use it when communicating with the LiteLLM proxy:

Application Backend
       |
       | Authorization: Bearer <API_KEY>
       v
LiteLLM Proxy

The important part is that the secret stays on the server.

Using an environment variable for a secret is normal.

Making the environment file itself available through the web server is the problem.

This is why .env files are normally kept outside the public document root, or otherwise explicitly blocked by the web server.

Verifying the exposure

The issue was straightforward to reproduce.

A normal request to the endpoint was enough:

curl -s https://[REDACTED]/.env

The response returned the environment configuration containing the LiteLLM-related variables.

There was no authentication flow to bypass and no special header required.

I stopped at confirming the exposure.

I did not attempt to use the API key against the LiteLLM service, make LLM requests, access other resources, or consume any associated quota.

For this type of finding, exposing the credential is already enough to demonstrate the security issue.

Why does an exposed API key matter?

The answer depends on how the key is configured.

If the credential is still valid, an unauthorized party who obtains it may be able to authenticate to the associated LiteLLM proxy.

Depending on its permissions, that could potentially allow things such as:

  • Sending requests to permitted LLM models
  • Consuming API or LLM quota
  • Generating usage that is billed to the associated account
  • Accessing functionality exposed through the proxy

That doesn't automatically mean the key provides unrestricted access to the entire AI infrastructure.

The actual impact depends on the key's permissions, restrictions, expiration, proxy configuration, and the services behind it.

But once a credential has been publicly exposed, it should be treated as compromised.

Why .env files are dangerous

This is also why .env exposure can be more serious than it initially looks.

A typical environment file might contain:

DATABASE_URL=...
API_KEY=...
SECRET_KEY=...
JWT_SECRET=...
LITELLM_PROXY_API_KEY=...

Not every variable is necessarily sensitive.

The problem is that you don't know what a deployment team has put inside the file until you see it.

One accidental web-server configuration can turn:

Application
├── public/
├── src/
└── .env

into:

Internet
   |
   v
Web Server
   |
   v
.env

And now the application's runtime configuration has become part of the public attack surface.

What should be done?

The remediation is fairly straightforward.

The exposed .env should be removed from public access, and the exposed API key should be revoked and replaced.

The deployment should also be reviewed to make sure sensitive configuration files cannot be served by the web server.

For this particular type of exposure, I would recommend:

  1. Remove .env from the web-accessible document root.
  2. Revoke the exposed LITELLM_PROXY_API_KEY.
  3. Generate a new credential.
  4. Review LiteLLM and related API logs for unexpected usage.
  5. Store secrets outside publicly served directories.
  6. Explicitly deny access to .env and similar configuration files at the web-server level.
  7. Review the deployment pipeline so the same file cannot be exposed again.

Deleting the file is only part of the fix.

If the credential inside it is still valid, the secret itself remains compromised.

And then came the funny part

The report went through a rather interesting journey.

It was initially classified as P1.

Later, it was downgraded to P3.

None

And then, somewhat unexpectedly…

None

Duplicate.

Wkwkwk.

I guess that's how bug hunting goes sometimes.

And this happened around the same time an Indonesian sixth-grade student, Ibrahim Al Abrar from Boyolali, was making the news after finding and responsibly reporting a vulnerability affecting a NASA domain.

He even received an acknowledgement from NASA.

So while an elementary school student was getting NASA recognition for finding a vulnerability, I was apparently finding a .env file and eventually getting a duplicate.

I lost to a sixth grader. 😂

None

To be fair, he didn't exactly "hack NASA" in the Hollywood sense. He found a vulnerability and reported it responsibly through NASA's vulnerability disclosure program.

Still…

I'll take the L.

Final thoughts

There's nothing particularly exotic about this vulnerability.

No complicated exploit chain.

No authentication bypass.

No fancy payload.

Just a configuration file that shouldn't have been publicly accessible, containing a credential that was intended to remain server-side.

That's probably the most useful lesson here.

Security testing isn't always about finding the most sophisticated vulnerability possible. Sometimes, a simple check for accidentally exposed files can reveal something much more valuable than expected.

And if that file happens to contain an API key for an LLM gateway, it's probably worth paying attention to.

Even if the report eventually says:

Duplicate.

😅