Exposed .env File (Config Disclosure)
The .env file is downloadable from the web, leaking database passwords, API keys and application secrets to anyone who asks.
What is Exposed .env File (Config Disclosure)?
Modern applications (Laravel, Symfony, Node, Rails) keep their secrets in a .env file: database credentials, mail server passwords, third-party API keys, cloud provider keys, and the application encryption key. When that file ends up inside the web root and the server serves dotfiles, a single GET request to /.env returns the entire credential set as plain text. This is not a theoretical issue — automated botnets probe /.env on every discovered host continuously, around the clock, because the payoff is so reliable. It remains one of the most common causes of full application compromise.
Why It Matters to Your Business
An exposed .env is an instant, total compromise. Database credentials let attackers connect directly if the database is reachable; AWS/GCP/SMTP keys are sold or abused within minutes; the Laravel APP_KEY lets attackers decrypt cookies and serialized payloads, which on older versions escalates to remote code execution. Publicly documented incidents have shown cloud bills drained and mailing domains blacklisted within hours of an .env leak. If this file was ever exposed, every secret inside it must be treated as stolen and rotated.
How to Fix It
1. Block dotfiles at the server level — for EVERY vhost, not just the main one:
Nginx:
location ~ /\. { deny all; return 404; }
Apache:
<FilesMatch "^\.">
Require all denied
</FilesMatch>
2. Move the application (and its .env) so the web root contains ONLY public assets — Laravel/Symfony already structure this correctly; never point the vhost at the project root.
3. ROTATE EVERYTHING if the file was ever exposed: database password, APP_KEY (php artisan key:generate — note this invalidates encrypted data), all API keys, mail and cloud credentials. Assume bots downloaded it.
4. Keep .env out of git (.gitignore is default — verify), and use secret managers (Vault, AWS Secrets Manager) for team access.
Verify: https://yoursite.com/.env must return 404.
Frequently Asked Questions
Bots downloaded my .env — what do I do right now?
Assume every secret inside is compromised. Rotate the database password, regenerate the application key, and revoke and reissue all API, mail, and cloud credentials — in that order, as fast as possible. Blocking the file now does not undo the leak.
How do attackers find my .env file?
They do not need to find it — they already know the exact URL. Botnets request /.env on every IPv4 web host continuously. If the file is served, it is found within hours, usually minutes.
Is renaming .env enough to hide it?
No. Rename-based "protection" fails the moment anyone learns the new name (error messages, logs, git history). Block dotfiles at the server level and keep the web root clean — that fixes the class, not one filename.
Technical Classification
| OWASP Category | A05:2021 — Security Misconfiguration |
| CWE ID | CWE-200: Exposure of Sensitive Information |
| Detected By | sensitive_paths, credential_exposure scanner(s) |
| Severity Level | critical |
How 2MNY Security Can Help
Check if your website has this vulnerability
Our sensitive_paths, credential_exposure scanner checks for this issue automatically.
Scan My Website FreeRelated Vulnerabilities
Exposed .git Directory
The .git directory is publicly accessible, allowing attackers to download your entire source code repository.
Server Version Disclosure
The Server and X-Powered-By headers disclose the server software and version, helping attackers target known vulnerabilities.
Directory Listing Enabled on Web Server
The web server lists directory contents to anyone, exposing unlinked files such as backups, archives and internal documents.
Exposed Backup Files (.bak, .sql, .zip)
Backup archives and .sql dumps left inside the web root can be downloaded by anyone — including your entire database.