Bots asked our sites for .env files 11,769 times

A .env file is where many web apps keep their secrets: database passwords, API keys, email logins, payment keys, cloud credentials. It's meant to sit on the server, outside the folder the web server shows to the world. When a deploy goes wrong and it lands in the public folder, anyone who asks for https://yoursite.com/.env gets the keys to everything.

Attackers know this, so they ask. Constantly.

They try every name a developer might use

Scanners don't just ask for /.env. They work through every variation a developer, a framework or a backup habit might produce:

Requests whose path contains ".env", our five sites, 2–16 Oct 2026. The other 677 paths shared the remaining 10,102 requests.

Look at the names: .save, .bak, .old are what editors and people leave behind. /api/, /backend/, /app/ are where a framework's folder ends up public by mistake. Each name is a guess about a common mistake.

It's not just .env

The same scanners asked for every other place secrets live:

• Git internals: /.git/config (261), /.git/HEAD (78), /.git-credentials (82). A public .git folder can hand over your entire source code, history and any passwords ever committed.
• Cloud and tool credentials: /.aws/credentials (102), /.aws/config (88), /.npmrc (96), /credentials.json (90), /secrets.json (73), /.ssh/id_rsa (41).
• Deploy files: /docker-compose.yml (84), /.gitlab-ci.yml (78), /.github/workflows/deploy.yml (68). They often hold server names, and sometimes passwords.
• Backups and dumps: /database.sql (55), /dump.sql (18), /wp-config.php.bak (17) and dozens more.
• Server information: phpinfo.php and info.php pages, which list a server's settings, often including its environment variables.

None of our sites runs PHP or WordPress. It made no difference: scanners don't check what a site runs before they try.

Who sends them

• Cloud servers, mostly Google's. 54% of the requests came from Google Cloud addresses: rented servers, not Google itself. Most of the rest arrived through Cloudflare, where our log didn't record the real address.
• Dressed as browsers. Most sent a normal Chrome or Safari user agent, so a quick look at the log makes them look like visitors.
• Dressed as crawlers. 720 requests came from fake crawlers, including 140 claiming to be Googlebot. Some even used the names of AI bots. Here's how to spot a fake.
• In waves. Quiet days saw under 100 requests; on 13 October there were 2,756. All five sites were hit, including our smallest, which had just 100.

98% of them got a 404. Most of the rest were dropped or turned away, and a handful aimed at our home page with a file path hidden in the query string, like /?file=../../../../var/www/html/.env, got the normal home page back, because the site ignores that parameter. Analytics never saw any of it: these requests don't run JavaScript.

How to check your own site in two minutes

1. Open https://yoursite.com/.env in a private browser window. Then try /.git/config, /.env.bak and /backup.zip. You want a "not found" page every time, never a file.
2. Make sure your web server's public folder (often public, public_html or www) contains only what visitors need. Secrets, the .git folder and backups belong above it.
3. Add a rule that refuses every hidden file, as a safety net:

   # nginx: refuse any path segment starting with a dot,
   # except .well-known (used for certificates)
   location ~ /\.(?!well-known/) {
       return 404;
   }
   
   # Apache (.htaccess)
   RedirectMatch 404 /\.(?!well-known/)

4. If a secret file was ever public, even briefly, change every key in it. Removing the file isn't enough: scanners save what they find.

What your logs can tell you

A wave of .env requests is background noise for every site. What matters is the exception: a request for a secret file that got a 200 instead of a 404, or one path suddenly asked for far more than the rest. You'll only see those in your server logs. Paste a sample into our free log analyzer to see which attack paths reach your site, and our post on WordPress attacks on sites without WordPress covers the other big category.

Humansift sorts every attack by what it was after, alerts you to sudden surges, and its protection check asks your own site for .env, .git/config and backup files the way scanners do, then tells you whether each one is blocked, refused or readable.

How we measured

Every number here comes from the server logs of our own five websites (a pet guide, an education site, a small-business tool, a crafts marketplace and a fashion blog), from 2 to 16 October 2026: 400,425 page and API requests. Images, styles and scripts were counted separately and are left out. Each request was sorted by Humansift: named bots by their user agent, Googlebot, Bingbot, GPTBot, ChatGPT and Perplexity checked against the address ranges their owners publish, attack paths by pattern, and data-centre traffic by network. A "visitor" is one address and browser on one day. Five small sites are a small sample, so read these as one honest data point, not an industry average.