Exposed Secrets in the AI Era: .env Files, Hardcoded Keys, and the Breaches That Follow

A single line of text in the wrong file can cost a company its entire cloud account. Not a sophisticated zero-day, not a nation-state implant, just a forgotten `.env` file served as plaintext over HTTPS, or an AWS access key pasted into a commit five years ago and never rotated. In August 2024, researchers documented a single extortion campaign that scanned more than 230 million unique targets, harvested credentials from exposed environment files across roughly 110,000 domains, then used the victims' own AWS Identity and Access Management keys to escalate privileges, exfiltrate S3 buckets, delete the data, and leave a ransom note behind. The attackers exploited no vulnerability in any cloud provider. They simply found secrets that should never have been reachable.

This is the uncomfortable shape of the modern breach. The most damaging exposures are rarely exotic. They are credentials sitting in places nobody meant to publish, indexed by automated bots within minutes of going live. For a security team or an MSSP, the job to be done is not "scan harder" — it is to find your own leaked secrets before someone monetizes them. This article maps exactly how secrets escape, grounds each pathway in verifiable incidents and primary research, and shows where these exposures land in your external attack surface.

The scale problem: secrets sprawl is accelerating, not shrinking

Start with the numbers, because they reframe the entire risk model. In its State of Secrets Sprawl 2025 report, GitGuardian found that 23.8 million secrets were leaked on public GitHub repositories during 2024 alone — a 25% year-over-year increase. The prior year's report counted 12.8 million for 2023, which itself was a 28% jump. The trend line does not bend toward improvement; it compounds.

What makes this worse than a one-time exposure is persistence. GitGuardian reported that roughly 70% of the secrets leaked in 2022 were still valid two years later. Even when a researcher or automated alert flags an exposed credential, prior reporting found that around 90% of leaked valid secrets remain active for at least five days after the author is notified. A leaked key is not a momentary slip. It is a standing invitation that most teams never get around to revoking.

The AI era adds a specific accelerant. GitGuardian's 2024 report documented a 1,212x surge in leaked OpenAI API keys as developers wired generative AI into everything from internal tooling to customer features. Add the velocity of AI-assisted coding, where credentials get auto-suggested and pasted into config without a second thought, and the leak rate is structurally rising. We explore that dynamic further in The Vibe Coding Security Crisis.

Pathway one: the committed .env file

The `.env` file exists to keep secrets out of source code. The irony is that it has become one of the most reliable places to find them. A `.env` is just a flat text file of `KEY=value` pairs — database URLs, API tokens, signing secrets, cloud credentials. The intended workflow is that it lives only on the developer's machine and the server, listed in `.gitignore` and never committed. The failure mode is that someone forgets the `.gitignore` entry, or copies `.env.example` to `.env` inside a tracked directory, and the whole file ships to a public repository.

Because the format is so predictable, automated scanners crawl public repositories specifically for `.env` content and known key prefixes — `AKIA` for AWS, `sk_` for Stripe, `AIza` for Google. This is why our exposed .env file exposure check exists, and why leaked API keys in frontend code sits beside it: the same secret often appears in more than one place once it has been committed once.

The canonical cautionary tale is Toyota. As GitGuardian documented, a subcontractor uploaded portions of the T-Connect application source to a public GitHub repository in December 2017, including a hardcoded access key to a data server. The repository stayed public until September 2022 — nearly five years — and the exposed credential could be used to access an email address and management number for roughly 296,000 customers. No exploit chain, no malware. Just a key that lived in the open long enough that the company could not rule out that someone had used it.

Pathway two: the .env served statically by your own web server

There is a second, sneakier variant that does not involve Git at all. The `.env` file lives on the server exactly where it should — at the application root — but the web server is misconfigured to serve files from that directory as static content. A request to `https://victim.example/.env` returns the file verbatim. The secret never touched a repository; it is simply reachable over the public internet.

This is precisely the mechanism behind the 2024 extortion campaign. As The Hacker News reported and CSO Online corroborated, the threat actors did not exploit any flaw in AWS itself. They mass-scanned for exposed `.env` files, extracted long-lived AWS IAM keys, and used those keys to provision new roles, escalate privileges, and pivot through the victims' own cloud environments. The campaign netted over 90,000 unique variables from environment files, of which roughly 7,000 belonged to cloud services and 1,500 to social media accounts. Cyble's telemetry separately detected more than 1.4 million publicly exposed `.env` files in 2024.

The most striking aspect of the attacks is that they do not rely on security vulnerabilities or misconfigurations in cloud providers' services, but rather stem from the accidental exposure of .env files on unsecured web applications to gain initial access.— The Hacker News, reporting on the 2024 cloud extortion campaign

This is what makes the statically-served `.env` so dangerous from an attack-surface standpoint: it is invisible to source-code scanning. A tool that only watches your repositories will never see it. You have to look at the asset the way an attacker does — from the outside, over HTTP — which is the entire premise of external attack surface management. The same external view catches sibling misconfigurations like directory listing enabled and exposed git directories, where the `.git` folder itself is downloadable and lets an attacker reconstruct your source and its embedded secrets.

Pathway three: secrets baked into the frontend bundle

The third pathway is the one developers most often rationalize away: "It's just a client-side key, it's meant to be public." Sometimes that is true — a Google Maps key restricted by HTTP referrer and a publishable Stripe key are designed for the browser. But the same build pipeline that ships those public keys routinely sweeps up secret ones. A server-side API token gets imported into a shared config module, the bundler inlines it into `main.js`, and now your private credential is one "view source" away from anyone.

Anyone can open the network tab, search the JavaScript bundle for `key`, `token`, `secret`, or `Bearer`, and read what comes back. There is no privilege boundary in front of a frontend asset. The OWASP Web Security Testing Guide treats this as a standard step, reviewing web page content for information leakage, because client-side code is a primary place sensitive data hides in plain sight. This is the heart of our leaked API keys in frontend exposure.

Source maps make it even easier

Modern frontends ship minified, transpiled JavaScript that is hard to read. Source maps (`.map` files) reverse that, mapping production code back to original, comment-rich source for debugging. Deployed to production and left publicly accessible, they hand an attacker a fully reconstructed, human-readable copy of your application — including any inline constants. Sentry's research on abusing exposed source maps walks through reconstructing application logic and pulling hardcoded secrets straight out of recovered source. The fix is mundane and effective: do not publish source maps to production, or restrict them so they are never served to the public internet.

Why a leaked secret is a breach, not a finding

Most categories of attack-surface output are probabilities. An open port is a place an attacker might try. A weak TLS configuration is a condition that might be exploitable. A leaked, valid credential is categorically different: it is access. There is no exploit step, no privilege boundary left to cross. The attacker simply authenticates as you.

That distinction matters enormously for triage, and it is the cleanest illustration of why validated findings beat scanner noise. A generic scanner might flag "sensitive file may be present" and bury it among a thousand informational alerts. A validated finding confirms the file is reachable, the key inside is live, and it grants real access. The first is noise a team learns to ignore. The second is a five-alarm event that should jump the queue ahead of everything else. The contrast is the entire point of exposure validation: proving impact, not just possibility, so the credential-level emergency does not drown in the maybe-pile.

Leaked secrets also chain. A stolen cloud key rarely stops at the asset it was found on. It becomes the pivot into the rest of the environment — exactly the kind of movement traced in attack-path mapping. In the 2024 extortion campaign, an initial IAM key became a foothold to create new roles, scan internally, and reach storage buckets. The first exposure was the cheap part; the blast radius was everything downstream. Related cloud-storage exposures like a public cloud storage bucket are frequently the second hop once a credential is in hand.

Finding your own secrets before an attacker does

The defensive program splits cleanly into prevention (stop creating leaks) and detection (find the ones you already have). Both matter, but only one of them addresses the credentials already sitting in your attack surface right now.

Prevent: align with OWASP secrets management

The OWASP Secrets Management Cheat Sheet is the authoritative baseline. Its core guidance is straightforward, and most leaks are a violation of one of these points:

• Never hardcode secrets in source code or configuration files. Centralize them in a dedicated manager such as AWS Secrets Manager, Azure Key Vault, Google Secret Manager, or HashiCorp Vault.
• Rotate secrets regularly and automatically, so that any stolen credential is only useful for a short window. A non-rotating key is the reason the Toyota credential was a five-year liability.
• Enforce least privilege. A leaked key scoped to one read-only resource is a contained incident; a leaked admin key is a company-ending one.
• Keep secrets out of the client entirely. Proxy third-party calls through a backend route so the secret stays server-side and the browser only ever sees the response.
• Treat any secret that ever appeared in a commit, deploy, or log as already compromised, and rotate it — bots indexed it long before you noticed.

Detect: look from the outside, continuously

Prevention controls only protect code written after they are in place. The statically-served `.env`, the key in last year's frontend bundle, the source map shipped in a deploy nobody remembers — these already exist, and source-code scanning cannot see them because they live on live assets, not in a repository. The only way to find them is to enumerate your real, current attack surface and inspect each asset the way an attacker would. That means continuous asset discovery across forgotten subdomains and shadow IT, then reconnaissance against every reachable endpoint — probing for `/.env`, downloadable `.git` directories, secrets in bundles, and exposed source maps — and validating each hit so you respond to confirmed access, not maybes.

This is the gap Legba Adversary is built to close. It maps your external footprint, then checks each asset for the exposures that turn a misconfiguration into stolen access — including exposed .env files, leaked API keys in frontend code, exposed git directories, and directory listing — and validates them so your team sees a confirmed credential leak, not another line item in a scanner's backlog.

The takeaway

Secrets leak through ordinary, repeatable mistakes: a missing `.gitignore` entry, a web server that serves the wrong directory, a bundler that inlines the wrong constant, a source map shipped to production. The research is unambiguous that the volume is rising and that remediation lags badly behind exposure. The breaches that follow are not clever; they are credential reuse at machine speed. The teams that stay ahead are the ones that stop assuming their secrets are private and start checking, from the outside and continuously, whether they actually are.