Bugoon does not use WordPress. It does not run PHP either. Still, requests for /wp-login.php reach our servers almost every day.

We counted six days of production logs. About 5,000 requests asked for pages that do not exist. This post shows what they were looking for and who sends them. At the end, we share a quick way to run the same check on your own site.

About 5,000 requests in six days, all for pages that do not exist

We looked at error responses from October 18 to 23. Here is what we found.

4,998 were 404 (page not found) and 2 were 400 (malformed request)
0 requests got content back (200)
The busiest day had 2,484 requests. The quietest day still had 390.

Late in the morning on October 18, 1,901 requests arrived within one hour. All of them came from the same tool. It tried a list of common file names from top to bottom. This is called a dictionary scan.

What are they looking for?

We grouped the requested paths by type.

WordPress and PHP: 1,697
Config files such as .env, and credentials: 1,436
The .git folder: 117
Backup files: 35
API specs (Swagger and similar): 15
Java admin endpoints (actuator): 8

The WordPress admin page

The most requested path was /wp-login.php, with 106 requests. /wp-admin/install.php and /xmlrpc.php came next.

The sender never checks whether a site runs WordPress. It tries every site it can find and attacks only the ones that answer. So do not think "we don't use it, so we are safe." Think "it reaches us even if we don't use it."

.env and its variations

A .env file holds database passwords and keys for outside services in one place. It is handy during development, but it must never be public.

What stood out was how many name variations they tried.

/.env.bak, /.env.backup, /.env.old
/.env.local, /.env.production, /.env.prod, /.env.development
/api/.env, /backend/.env, /laravel/.env

You can read this list as a record of real accidents. Someone copied .env.bak while working and forgot to delete it. Someone put .env.production in a public folder. Because these mistakes happened before, the names ended up on the attackers' lists.

They also looked for /.aws/credentials (AWS keys) and /credentials.json.

The .git folder

Requests for /.git/config and /.git/HEAD kept arriving too. The .git folder is where Git stores the change history of your source code.

If it is public, someone may rebuild your entire source code from it. A password you wrote once and deleted right away is still in that history.

How to check your own site

This command checks whether common paths return any content. Replace example.com with your own domain.

for p in /.env /.env.bak /.env.production /api/.env /.git/config /.git/HEAD /phpinfo.php; do
  printf '%s %s\n' "$(curl -s -o /dev/null -w '%{http_code}' https://example.com$p)" "$p"
done

If every line says 404, you are fine for now. If any path returns 200, open it and look at what it contains.

A 200 is not always a problem, though. Some sites return the home page for any unknown path. In that case, compare the response with your home page to tell them apart.

Where to stop it

It is more reliable to prevent these accidents while building than to catch them by watching the server.

When writing code: Do not keep secrets in files. Load them from a secrets management service.
When building: Automatically check that .env and .git are not in the folder you publish.
Before release: Add the command above to your checklist and run it against your production URL.

At Bugoon, we do not ship secrets as files. Every path our app does not define returns 404. None of the roughly 5,000 requests got any content back.

Summary

Attacks on software you do not use still arrive every day.
The list of file names they look for is also a list of past accidents.
One command is enough to check. Put it on your pre-release checklist.

We are also thinking about adding these scan counts to our daily monitoring. A change in the usual pattern could help us notice trouble sooner.

No WordPress Here, but WordPress Attacks Arrive Daily