Hello everyone, I'm Sherlok, and today I'd like to share how I discovered an exposed .env file that led to leaked API credentials and real financial impact.
Twitter: https://x.com/sherl8k
Let's begin:
Let me quickly mention a browser extension I regularly use that helps identify vulnerabilities with zero interaction:
It runs in the background and alerts you when it detects:
.git/.svn/.hg folders
.env files
.DS_Store
It was precisely because of this that I was able to find the vulnerability we'll be discussing today
Open /.env
While browsing some websites, I saw a notification about an open .env file and immediately decided to check it out. I was very pleased with what I saw, as I noticed the following API keys there:
At this point, it was clear that these credentials could potentially be used to interact with external services.
The next step was to verify whether they were valid.
Well then, let's see if they work:
I used the following curl commands:
1. Successful authenticated request:
This confirmed that the credentials were active and usable.
2. Access to account balance
I then tested whether I could access account-related data:
At this point, it became clear that the exposed credentials were not only valid -but also tied to a billing account.
Impact
This kind of issue might look simple, but it has serious implications.
An attacker could:
- Consume the company's API balance (financial loss)
- Automate large-scale API usage
- Exhaust quota and cause denial of service
- Use the API for unauthorized data enrichment
- Integrate the stolen API into their own tools or services
And the most important part - no authentication to the application itself was required.
Everything was possible using only the leaked .env file.
Why Exposing .env Is Dangerous
The .env file is one of the most sensitive files in any application.
It usually contains:
- API keys
- Secrets
- Database credentials
- Internal service endpoints
- Tokens and private configuration
Exposing it is essentially the same as giving an attacker direct access to the application's internal secrets.
Unlike typical vulnerabilities, this does not require exploitation- the data is simply handed over.
Root Cause (in plain terms)
This was not a complex vulnerability - just a classic misconfiguration:
- Sensitive
.envfile exposed publicly - No server-side restriction on access
- Secrets stored in plaintext
- No additional protection (IP restriction, rotation, etc.)
Basically, the server allowed direct access to a file that should never be public.
Fix / Recommendation
To properly address this issue, the backend should:
- Block access to
.envfiles at the web server level - Store secrets outside of the web root
- Rotate all leaked credentials immediately
- Monitor usage for abuse
Issues like this are a good reminder that security doesn't always fail in complex ways — sometimes it's just one exposed file.
The issue was responsibly disclosed to the company. All credentials were rotated after the report.