Blog

Why your site gets .env and wp-login probes, and what to do about them

By Peter Mitala, Director · 9 November 2026

Open the access log of almost any public website and you’ll find requests for files that were never there: /.env, /.git/config, /wp-login.php, /xmlrpc.php, old backup archives. Your site might be a Laravel app or a static page with no WordPress anywhere. The requests come anyway.

This post explains why, and what to do about it.

Nobody chose your site

These requests almost never come from a person who picked you. They come from scanners: programs that walk through large ranges of IP addresses and domain names and ask every server the same short list of questions.

The list is chosen for payoff, not for you:

• .env files often hold database passwords and API keys. If a framework’s environment file sits inside the web root and the server will serve it, one request is enough to leak every secret in it.
• .git folders let an attacker rebuild your source code, including any secrets that were ever committed.
• WordPress login and XML-RPC endpoints are worth trying because so many sites run WordPress. A scanner doesn’t check first; asking is cheaper than checking.
• Backup and archive files (backup.zip, site.tar.gz, database dumps) are left behind surprisingly often.

Because the scanner asks everyone, a request for /wp-login.php on a site with no WordPress is not a sign you are being targeted. It’s background noise. It only matters if one of those questions gets a real answer.

What we see on our own sites

We run DBshieldX on our own production sites first. In the 7 days to 7 November 2026, block mode would have stopped 159 clients across 16 sites, and every one we profiled was a scanner or fuzzer. Only 11 of them were already on CrowdSec’s community blocklists, so most of this noise comes from addresses that no shared list knew about yet.

That’s the point to take away: you can’t blocklist your way out of scanners. New ones appear all the time. What works is making sure they find nothing, and slowing down the ones that keep trying.

What to do about it

1. Make sure the answer is always “no”

The probes are harmless if nothing sensitive can be served. Check these first:

• Keep secrets out of the web root. The document root should hold only what visitors need. Environment files, config files and keys belong one level up, where the web server can’t serve them.

• Deny dotfiles at the web server. In nginx, one rule refuses every hidden file and folder except /.well-known/, which certificates and security.txt need:

  location ~ /\.(?!well-known/) {
      deny all;
  }

• Don’t deploy with Git into the web root, or if you must, deny /.git as above.

• Delete old backups and dumps from anywhere the web server can reach.

Then test it yourself: request your own /.env and /.git/config and make sure you get a 403 or 404, never a file.

2. Protect the login pages you do have

If you run WordPress or any other app with a login page, the login probes are real attempts to guess passwords:

• turn on two-factor sign-in for every admin account;
• rate-limit the login endpoint;
• disable XML-RPC if nothing you use needs it;
• keep the core, plugins and themes up to date.

3. Watch before you block

A web application firewall can recognise scanners by their probe paths and tool fingerprints, and by behaviour over time: a client that walks through dozens of paths that don’t exist looks nothing like a visitor.

In DBshieldX, scanners and bad bots are one of the detection categories, and path enumeration and error bursts are behaviour rules. Every route starts in monitor mode, so you first see what would be blocked, check that none of it is real traffic, and only then switch blocking on. Clients that keep sending high-risk requests are banned through CrowdSec for 4 hours, then 24 hours, then 7 days, and the ban is shared across all your servers.

4. Don’t spend your evening on it

Background scanning isn’t an incident. Unless one of the probes got a real file back, there’s nothing to clean up. Make the checks in step 1 part of every deployment, protect your logins, and let the firewall deal with the noise.

---

Want to see what scanners ask your own site? Book a demo and we’ll run DBshieldX in monitor mode on one of your sites for a week.