Millions of Publicly Exposed .env Files Put Internet Services at Risk: A Mysterium VPN Research

Configuration mistakes rarely look dramatic. A single forgotten deployment rule, an overlooked web server setting, or an uploaded project folder that contains hidden files can quietly make a website’s most sensitive secrets accessible to anyone on the internet. Often, these secrets are stored in environment configuration files called .env files.

Researchers here at Mysterium VPN identified over 12 million IP addresses with publicly accessible .env-style files, revealing credentials and tokens, including JWT signing keys, API keys, database passwords, and service tokens. This discovery indicates a significant and persistent digital security hygiene issue affecting companies, developers, and end users across multiple countries and industries.

The risk isn’t theoretical. OWASP (a nonprofit that works to improve software security) states that secrets must be carefully controlled, rotated, and audited. When they leak, attackers can gain access to systems, move laterally within networks, and compromise sensitive data.

Key Takeaways

• 12,088,677 IPs were identified with publicly exposed environment configuration files during the research process.
• Exposed values include database access credentials, API keys, JWT secrets, and application tokens, all of which could let an attacker gain unauthorized access, steal data, or take over accounts.
• The United States leads the count with nearly 2.8 million exposed IPs, accounting for around 23% of the total IP pool.
• The issue is global: Japan (1.1M), Germany (777K), India (652K), France (636K), and the UK (583K) also have substantial exposures, showing that this is a global security hygiene problem.
• Past research confirms that .env leaks aren’t a new issue; developers repeatedly expose sensitive credentials accidentally, making this an ongoing operational risk across industries.

What Is a .env File and Why Does It Contain Secrets?

A .env file is a configuration file oftentimes used to store environment variables for an application. In modern development workflows, these variables often include:

• Database connection strings (hostnames, usernames, passwords, database names).
• API keys for payment processors, email providers, analytics, and messaging services.
• OAuth client secrets (the information users give to the websites they’re trying to visit).
• JSON Web Tokens (JWT) signing keys or session secrets.
• Cloud access keys and storage credentials.
• Third-party service tokens and webhooks.

The file format is simple: key-value pairs like DATABASE_URL=... or JWT_SECRET=.... 

Frameworks and libraries (often via “dotenv” tooling) automatically load these values when the application starts. That simplicity is exactly why .env files became so popular: they are easy to create, easy to modify, and easy to deploy. But that same simplicity creates risk.

If an .env file is accidentally placed inside a publicly accessible directory (or if a web server fails to block access to hidden files), anyone who knows the URL pattern (for example, /.env) can try to download it. No exploit chain. No malware. Just a direct request.

From a security perspective, exposed secrets are treated as high-impact events because they remove the attacker’s need to break in. Instead of bypassing authentication or exploiting a vulnerability, an attacker may simply use the credentials exactly as intended. 

OWASP’s guidance frames this as a lifecycle and governance problem. Secrets must be: 

• Protected from unauthorized access.
• Centrally managed and auditable.
• Rotated regularly.
• Scoped to least privilege.

When those controls are missing, a leaked .env file can provide an immediate, direct path to compromise.

Exposure at Scale: Inside the 12 Million IP Dataset

The scan results reveal a significant problem; not a handful of exposed servers, but millions. 12,088,677 IPs with exposed environment files were discovered. That number alone signals a systemic issue. Secret exposure at this scale can’t be explained by isolated mistakes. It reflects repeated configuration patterns across hosting environments, frameworks, and deployment workflows:

• United States: 2,799,918 IPs (23.2%);
• Japan: 1,101,633 IPs (9.1%);
• Germany: 777,321 IPs (6.4%);
• India: 651,846 IPs (5.4%);
• France: 636,491 IPs (5.3%);
• United Kingdom: 582,816 IPs (4.8%);
• Singapore: 579,287 IPs (4.8%);
• Ireland: 562,274 IPs (4.7%);
• Canada: 551,586 IPs (4.6%);
• Australia: 540,526 IPs (4.5%);
• Other countries: 3,304,979 IPs (27.3%).

Exposure Matches Infrastructure Density

Countries with large web hosting markets and major cloud footprints naturally have more exposed systems. The United States, for instance, hosts a significant share of the global cloud infrastructure, which explains why it represents nearly a quarter of the dataset.

Similarly, Singapore and Ireland function as major infrastructure hubs for multinational cloud and CDN providers. Their appearance in the top 10 reflects hosting geography, not necessarily the nationality of affected organizations.

Not a Single-Ecosystem Problem

The geographic spread across North America, Europe, and Asia suggests that this issue isn’t tied to one specific framework, language, or platform. Instead, it suggests a recurring workflow problem:

• Default server configurations that fail to block hidden files.
• Deployment practices that upload entire project directories.
• Inconsistent secret management across development and production environments.

Essentially, the exposure pattern repeats across stacks. The data found by our team of researchers points to an operational hygiene issue embedded in how applications are built and deployed, not a vulnerability unique to one vendor, cloud provider, or region.

Why Exposed .env Files Are So Damaging

Exposed .env files are dangerous because they often contain live credentials, not harmless configuration details. When attackers retrieve these files, they don’t even need to exploit a vulnerability. Instead, they can simply use the exposed secrets as intended. Below are the most common and highest-impact consequences.

#1 Database Access and Data Theft

Database credentials are often the most valuable contents in .env. When an attacker obtains a working database username and password, the attacker may gain:

• Read sensitive user data (emails, order history, personal details)
• Modify records or permissions
• Extract password hashes
• Discover additional internal secrets stored in tables

This can quickly escalate from data exposure to full system compromise. OWASP DevSecOps guidance explicitly warns against secrets in code or uncontrolled locations and recommends detection mechanisms such as pre-commit hooks and CI pipeline scanning because credentials can lead directly to compromise.

#2 API Abuse and Financial Damage

Many .env files contain API keys for third-party services such as email providers, SMS platforms, cloud storage, or payment integrations. If exposed, attackers may:

• Send spam or phishing emails.
• Run expensive workloads on paid APIs.
• Abuse messaging systems.
• Impersonate legitimate service accounts.

Because API keys are often broadly scoped, misuse can lead to both reputational harm and unexpected financial costs.

#3 JWT Forgery and Session Hijacking

JWT tokens are commonly used for authentication. A typical JWT is signed with a secret (HMAC) or a private key (asymmetric cryptography). If the signing secret is leaked, an attacker can forge tokens that look valid to the application. Outcomes include:

• Account takeover without credentials.
• Escalation to administrator roles if roles are encoded in claims.
• Persistent access if refresh token secrets are exposed.

In this scenario, no password cracking is required, as the trust mechanism itself is compromised.

#4 Email Account Compromise and Phishing

SMTP (the standard protocol used to send and relay emails across networks) credentials and mailbox passwords are often stored in .env files. If these credentials work, an attacker can:

• Send phishing emails from a legitimate domain.
• Reset passwords for other services that rely on email verification.
• Access sensitive inbound communications (invoices, contracts, user complaints).

With the growing number of phishing attacks, a compromised email account can do significant damage to the reputation of the service you’re providing.

#5 Cloud Storage Exposure and Secondary Compromise

Cloud access keys (e.g., object storage credentials) can turn catastrophic if leaked. Attackers can search buckets for:

• Database backups.
• Identity documents (KYC).
• Contracts and internal files.
• Application logs with further secrets inside.

Even when the initial .env exposure originates from one web application, the leaked keys can unlock entirely different systems.

How .env Files Become Publicly Accessible

Exposed .env files typically appear because of one or more operational errors. The following causes are consistently observed in incident write-ups and large-scale scanning research:

Web Server Misconfiguration

Proper server configurations should block access to hidden files and sensitive extensions. Exposure happens when:

• Deny rules for hidden files are missing.
• Reverse proxies forward requests for /.env.
• Static file serving points to the project root.
• Default configurations are left unchanged.

A single missing rule can make a sensitive file directly downloadable.

Uploading the Entire Project Directory

Many deployments involve copying a full project folder to a server. If the .env file sits inside that directory (and the directory is web-accessible), the file becomes public. Because filenames beginning with a dot are hidden by default in some operating systems, teams may not even realize the file was included.

Containerization and Build Artifacts

In container-based deployments, secrets may be baked into images or included in build outputs. A misconfigured route, debug endpoint, or static file mapping can expose configuration content. Separately, environment variables may leak through logs or diagnostics, a risk discussed in multiple security engineering threads and vendor guidance.

Backups and “Leftover” Files

In real environments, .env isn’t always the only risk. Teams sometimes leave:

• .env.bak, .env.old, .env.save.
• .env.production, .env.stage, .env.dev.
• config.php~, settings.json.bak, or ZIP archives of the project.

Attackers routinely enumerate these patterns because “forgotten” files are common and easy to exploit. Prior scanning-based reporting has emphasized that leftover files on public websites can enable high-impact breaches even without complex exploits.

What Defenders Should Do Immediately

If a team discovers an exposed .env file, they should treat the event as a security incident. A defensive response should assume secrets are compromised.

First, defenders must immediately remove public access by blocking .env and related patterns at the web server layer, removing the file from any public web root, and purging cached copies from CDNs and reverse proxies if applicable.

Second, defenders must rotate every secret: database passwords, API keys, OAuth client secrets, JWT signing keys, SMTP credentials, and any service tokens present in the file. OWASP emphasizes that proper secret management requires rotation and auditing, as secrets are high-value compromise targets.

Defenders must also invalidate sessions and tokens: if JWT signing keys were exposed, invalidate active tokens by rotating signing secrets and enforcing short token lifetimes. Rotate refresh token secrets if they exist.

Next, you must review logs for suspicious activity: check for unusual database logins, API spikes, and outbound email anomalies, and look for access from unfamiliar geographies or networks. 

The last thing to do is implement secret detection. This includes adding repository scanning and CI scanning for secrets, using pre-commit hooks to prevent secret commits, and monitoring build logs and pipeline logs for secret output.

OWASP DevSecOps guidance specifically calls out detection across repositories, pre-commit, and pipelines as a practical control.

What Users Can Do to Reduce Personal Risk

End users can’t directly fix server misconfigurations, but users can reduce harm if a site they use is compromised:

• Use unique passwords and a password manager.
• Enable multi-factor authentication where offered.
• Treat unexpected password reset emails as high-risk.
• Monitor financial accounts for unusual activity.
• Be cautious with sites that request unnecessary personal data.

The primary responsibility remains with organizations operating exposed infrastructure because .env leaks originate from server-side configuration and deployment practices.

How to Prevent .env Exposure Long Term

Preventing .env exposure requires layered controls. No single safeguard is enough; protection must exist at the server, application, and operational levels.

Block Access at the Web Server and Proxy Layer

A secure baseline is to deny:

• /.env.
• Any file beginning with . in public directories.
• Backup extensions (.bak, .old, .swp, ~).
• Archive formats (.zip, .tar, .gz) in web roots unless required.

This control should exist in:

• Nginx or Apache configuration.
• CDN edge rules.
• WAF policies, where appropriate.

Move Secrets Out of Application Directories

The safest pattern is to avoid placing secrets in any directory that could ever be served by a web server. Even “private” directories can become public after a refactor or a routing mistake. A practical alternative is centralized secrets management (vault-style tooling) with:

• Access control policies.
• Audit logs.
• Rotation automation.
• Per-environment scoping.

OWASP’s Secrets Management guidance provides an actionable blueprint for these controls and explains why centralized governance reduces leak impact.

Reduce Secret Blast Radius

A leaked key shouldn’t equal total compromise. Achieve this by:

• Scoping API keys to minimum permissions.
• Enforcing IP allowlists where feasible.
• Using short-lived tokens instead of long-lived static secrets.
• Segmenting databases and enforcing network-level restrictions.

Add Continuous Secret Monitoring

Secrets frequently leak outside of source code through logs, pipelines, and accidental artifacts. Multiple security engineering sources discuss how environment variables and secrets can surface through operational workflows if not controlled. Continuous controls include:

• Secret scanning in repositories and container images.
• DLP-style monitoring of outbound logs.
• Alerting on unusual API usage patterns.
• Key rotation schedules that are enforced by policy.

Improve Deployment Hygiene

• Use “allow lists” for what gets deployed, not “copy everything.”
• Ensure .env is excluded from deployment artifacts where appropriate.
• Enforce .gitignore and build ignore patterns, but don’t rely on them.
• Add post-deploy checks that validate “no sensitive files are publicly accessible.”

Why This Research Matters Now

Secret sprawl remains a persistent challenge in software supply chains and internet infrastructure. Vendor and community guidance continues to warn that developers and operators must treat secret handling as a lifecycle problem, not a one-time configuration detail.

Mysterium VPN research’s dataset highlights that .env exposure isn’t limited to isolated mistakes. The scale suggests a repeating operational failure pattern across stacks and regions. 

That reality should influence how teams prioritize security defaults in templates and frameworks, deployment pipelines and artifact rules, and Web server hardening baselines, and continuous verification and monitoring.