Exposed .env File
An exposed .env file is a dotenv configuration file (such as .env, .env.local, or .env.production) that a web server returns as plain text instead of keeping it private, handing attackers the database credentials, cloud access keys, and signing secrets your application loads at boot.
A single GET request to https://yoursite.com/.env should return a 404. When it instead returns a wall of KEY=value lines, the request that took an attacker two seconds just handed them the keys to your database, your AWS account, and the secret that signs your session tokens. This is not an exotic exploit chain; it is a static file being served when it should never leave the server, and automated crawlers find it the same afternoon you deploy it.
Reviewed by Aakash Harish
Security Research Contributor, Legba
Reviewed 2026-05-28 · Updated 2026-05-28
What it is
A dotenv (.env) file stores environment-specific configuration as KEY=value pairs that frameworks like Laravel, Django, Rails, and Node.js read at startup. It is meant to live on the server filesystem and be excluded from version control and from the public web. An 'exposed .env file' exists when that file sits inside the web document root (or a path the server maps to it) and the server delivers it verbatim over HTTP, typically because a build or deploy step copied it into the published directory and no rule blocks requests for dotfiles. Because .env files routinely hold database connection strings, cloud provider access keys (for example AWS_SECRET_ACCESS_KEY), third-party API tokens, SMTP credentials, and application signing secrets (such as Laravel's APP_KEY or a JWT secret), serving one as static content discloses the application's entire trust foundation in a single response.
If your .env is publicly readable, you have not lost a configuration file; you have lost everything it protects. Leaked database credentials let an attacker read, alter, or delete your records directly. Leaked cloud keys let them pivot into your AWS, GCP, or Azure account and run up compute, exfiltrate storage buckets, and destroy backups. Unit 42 documented a real extortion campaign that scanned over 230 million targets, harvested .env files from roughly 110,000 domains, extracted more than 90,000 unique variables, and used the AWS IAM keys inside them to exfiltrate and delete data from victims' S3 buckets before leaving ransom notes. None of those victims were breached through a vendor vulnerability; they were breached because a credential file was reachable from a browser. The job your security team actually needs done is not 'know that .env exposure is bad' but 'have a confirmed, evidenced instance you can hand to the owning team today' before a crawler turns it into a payable ransom note.
At a glance
How attackers find and exploit it
- Run wide internet-scale crawling and Google dorking (for example intitle queries and 'DB_PASSWORD' filetype searches) to enumerate hosts and subdomains that respond to a request for /.env and common variants.
- Send a GET request for /.env, /.env.local, /.env.production, /.env.bak, and /api/.env, then inspect the response body for KEY=value patterns and a 200 status rather than a 404 or redirect.
- Parse the returned file for high-value keys: AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY, DB_HOST/DB_USERNAME/DB_PASSWORD, MAIL or SMTP credentials, Stripe and other API tokens, and signing secrets like APP_KEY or JWT_SECRET.
- Validate the cloud keys out-of-band (for example calling AWS sts:GetCallerIdentity), enumerate the permissions attached to them, and pivot into the cloud account to list and read storage buckets or spin up infrastructure.
- Forge or decrypt session and authentication tokens using the leaked signing secret to impersonate users or administrators, and connect directly to the exposed database to dump or ransom its contents.
- Establish persistence by creating new IAM users or access keys, then exfiltrate data and leave an extortion note, as observed in the Unit 42 large-scale cloud extortion campaign.
How to detect it on your surface
- From an external network, request each candidate path over both HTTP and HTTPS for every site and subdomain you own: /.env, /.env.local, /.env.production, /.env.dev, and /.env.bak.
- Treat any 200 response whose body contains KEY=value lines as a confirmed exposure, and treat 403/404/redirect responses as the expected safe behavior.
- Enumerate subdomains and per-tenant hosts first, because a hardened apex domain often coexists with a forgotten staging or microservice host that still serves its .env.
- Inspect your build and deploy artifacts (Docker images, CI publish steps, and the contents of the served document root) to verify the .env was never copied into the public directory in the first place.
- Review web server access logs for prior successful (2xx) requests to dotenv paths, which indicate the file was reachable and may already have been harvested.
Detection signals
- HTTP 200 status on a request for /.env or a variant, instead of 404 Not Found, 403 Forbidden, or a redirect.
- Response Content-Type of text/plain or application/octet-stream with a body of newline-separated KEY=value pairs.
- Presence of recognizable dotenv keys in the body such as APP_KEY, APP_ENV, DB_CONNECTION, DB_PASSWORD, AWS_SECRET_ACCESS_KEY, or MAIL_PASSWORD.
- A Content-Length consistent with a small text config file (often a few hundred bytes to a few kilobytes) returned for a dotfile path.
- Framework-specific markers in the values, for example a base64 APP_KEY prefixed with 'base64:' (Laravel) or a NODE_ENV/NEXT_PUBLIC_ prefix (Node.js/Next.js), confirming a live application config.
Validate before you report
- Fetch the file and confirm the response code is 200 and the body actually contains KEY=value secret material, not an HTML error page that merely happens to return 200 (a soft-404).
- Confirm the path is the application's real environment file by correlating its keys with the detected technology (for example DB_CONNECTION and APP_KEY for Laravel) rather than a placeholder or example template.
- Without using the secrets to access third-party systems, verify the values are non-empty and non-default (not 'CHANGEME', 'your-key-here', or an obviously masked sample) so the finding reflects live credentials.
- Record the exact request, full response headers, and a redacted excerpt of the body as evidence, capturing the timestamp so the owning team can scope which secrets must be rotated.
- Re-test from a clean external vantage point to rule out a cached, geofenced, or session-dependent response and confirm the exposure is reachable by any anonymous internet client.
What looks like this but isn't
- A committed .env.example or .env.sample template intentionally contains only placeholder keys with no real values; treat it as documentation, not a credential leak.
- Some servers and CDNs return a custom 200 error or marketing page for unknown paths (a soft-404); confirm the body genuinely holds KEY=value secrets before flagging it.
- A path like /.env may be a route handled by the application that returns JSON or an HTML page rather than the raw dotenv file, which is not the same as a static credential disclosure.
Remediation
- Immediately treat every secret in the exposed file as compromised and rotate it: regenerate cloud access keys, database passwords, API tokens, and the application signing key (for example rotating APP_KEY or the JWT secret and invalidating existing sessions).
- Remove the .env file from the web document root and stop deploy pipelines from copying it into any publicly served directory; the file should live outside the served path entirely.
- Add an explicit web server rule to deny requests for dotfiles, such as a location block in Nginx returning 404 for /\.(?!well-known) or a FilesMatch directive in Apache denying access to files beginning with a dot.
- Ensure .env and its variants are listed in .gitignore (and .dockerignore) so they are never committed to source control or baked into container images.
- Move secrets out of static files altogether by injecting them at runtime from a managed secrets store (for example AWS Secrets Manager, HashiCorp Vault, or your platform's environment configuration), following OWASP Secrets Management guidance.
- Audit access logs and cloud activity for the exposure window, scope what the leaked keys could reach, and review for unauthorized use before closing the incident.
Operational checklist
- Block requests for dotfiles by default in your base web server and reverse-proxy configuration, so a stray .env is never servable even if it is accidentally deployed.
- Keep .env and *.env* entries in .gitignore and .dockerignore across every repository and pull-request template, and enforce it with a CI check.
- Run an automated secret scanner in CI (and a pre-commit hook) to block commits that introduce credential files or hardcoded keys.
- Source application secrets from a managed secrets manager with short-lived, least-privilege credentials and scheduled rotation rather than long-lived keys in a flat file.
- Continuously monitor your full external surface, including newly created subdomains and microservices, for reachable dotenv paths so a fresh deploy mistake is caught in hours, not after a breach.
- Maintain a rehearsed key-rotation runbook so that when an exposure is confirmed, every affected secret can be rotated and revoked quickly.
What to do next
An exposed .env file is the rare critical finding that costs almost nothing to confirm and almost everything to ignore: a single readable request can leak the credentials behind your database, your cloud account, and your session tokens, and attackers already scan the entire internet for it. The concrete next step is to request /.env (and its variants) against every host and subdomain you own right now; if any returns secrets, rotate them today and add a dotfile-deny rule before you do anything else. Legba Recon does this continuously and proves it, so you act on a confirmed leak instead of discovering it from a ransom note.
Methodology
Each finding-type guide is built from Legba Recon's real detection and validation logic, reviewed by a named security contributor, and cited against primary sources such as OWASP, CISA, NIST, and MITRE. We update pages when the underlying guidance changes. See our contributors and company.
FAQs.
References.
- 01Leaked Environment Variables Allow Large-Scale Extortion Operation in Cloud EnvironmentsUnit 42, Palo Alto Networks
- 02Secrets Management Cheat SheetOWASP Cheat Sheet Series
- 03
- 04
