Automated Attacks on a Public Information Website: A 30-Day Firewall Log Study, September to October 2026

Every public website is probed all day by software that never reads a page. To see what that looks like in practice, we studied 30 days of our own firewall logs, from 13 September to 12 October 2026, and counted what our defences stopped, what the requests asked for, and what the raw numbers hide. We publish the patterns and the figures. We do not publish IP addresses or the names of networks: an address in a log shows where a connection is, not who is behind it, and naming companies would suggest something the data cannot show.

Key findings

• At least 19,778 requests were blocked or challenged between 13 September and 12 October 2026, from 58 addresses in 16 networks. Our log keeps only the 60 busiest sources and paths each day, and most of those slots go to traffic we allow, so smaller attackers do not appear and the true figure is higher by an amount we cannot measure.
• Blocks came in bursts. Sources busy enough to reach our daily top-60 list appeared on 17 of the 30 days, with a peak of 3,438 on 13 September.
• An ordinary page address does not mean an ordinary request. 85% of the blocked requests we could sort were for normal pages such as the news list, but our log records only the address, not the query string or headers where attack code hides.
• Raw firewall counts mislead. More than a million other entries in the same logs were requests our rules deliberately exempt from checks: verified crawlers and our own pages' background calls.

Data and method

The data is Cloudflare firewall events for this site, copied every day into a database so they outlive Cloudflare's short retention. We counted only requests that were blocked or challenged as attacks. The log is a daily top-60 list of sources and a separate daily top-60 list of requested addresses, so every figure here is a lower bound. Country is Cloudflare's geolocation of each address, which is approximate. We list no IP addresses and no network names and make no claim about who is responsible.

How much was blocked

Blocked volume per month since we began keeping these logs in early June:

September was 78% higher than August. Do not read that as a simple rise in attacks: these counts depend on our rules as well as on attackers, and we added blocking rules over the summer, so more blocked requests is not the same as more attacks.

Within the study window, blocked sources busy enough to reach our daily top-60 list appeared on 17 of the 30 days. The peak was 3,438 requests on 13 September. Smaller, steady scanning on the other days falls below that cut-off.

What the blocked requests asked for

Our separate log of requested addresses recorded 13,867 blocked or challenged requests, about 70% of the total above. Sorted by what they asked for:

What they asked for	Share	Examples
Ordinary pages	85.4%	the news list, category pages, author pages, the contact page
Secret files	6.1%	15 spellings of .env (/.env.save, /.env.sqlite, /%2eenv/) and /.htpasswd
Admin, login and account pages	4.9%	/admin, /account, /signin, /dashboard, /api/auth/signin
WordPress and PHP paths	3.5%	/wordpress/index.php, /wp-json/batch, /blog/index.php

Ordinary pages. Most blocked requests were for normal addresses such as the news list, category pages and the contact page. Our log records only the page address, not what follows a question mark or what is sent in headers, so these figures alone do not show why each request was stopped. Some came from networks we block outright, where every request is refused whatever it asks for. Others were stopped by Cloudflare's managed rules, which block requests that carry attack code, for example in the query string of a web address or in a form submission, even when the page itself is ordinary. In one September incident, more than 300 requests to our contact page from a single home broadband connection carried attack code in the web address. An ordinary page address does not mean an ordinary request.

Secret files. A .env file holds passwords and keys. Scanners ask websites for many spellings of it (.env, .env.save, .env.production, with extra slashes and URL-encoded characters to get past simple filters), hoping one is left readable. We do not serve such a file, and every request was blocked.

Admin, login and account pages. Requests for /admin, /signin and /account look for a door to try stolen or guessed passwords on.

WordPress and PHP paths. We do not run WordPress or PHP. Scanners ask anyway, because their lists are built for the most common website software and are run against every address they find.

The entries that were not attacks

More than a million other firewall log entries in the same period were not attacks. They record requests that one of our rules deliberately exempts from further checks: search engines and other crawlers that Cloudflare has verified (including the AI crawlers we allow and social networks' link-preview bots), and our own pages' background calls, such as reporting a page view. If you read raw firewall counts without separating those out, ordinary and well-known traffic looks like an attack. This is the most common mistake in reading web firewall data, and the reason the networks of large technology companies can top an unfiltered list.

Where the connections come from

This shows where the addresses are, according to Cloudflare's geolocation, not who is behind them.

• The busiest single network accounted for 20% of blocked requests: 3,924 requests from 8 addresses over 4 days.
• Consumer broadband and mobile connections, mostly in France, accounted for about 42%. Traffic from ordinary connections can come from infected devices, from paid proxy services that route requests through people's connections, or occasionally from a real visitor caught by a rule. It does not mean the provider or its customers are responsible. Our log does not record which rule acted on each request; for networks we do not block outright, the likely rule is Cloudflare's managed rules.
• Large cloud platforms accounted for about 14%. Anyone can rent a server on these platforms, so a request from their address space says nothing about the company that owns them.
• By the country Cloudflare's geolocation assigns to each address, France accounted for about 45%, the Netherlands 26%, Sweden 12% and the United States 7%. Where an address is located is not where the person using it is.

What we do, and what you can do

We block networks that only scan, block requests for secret files and WordPress paths, let Cloudflare's managed rules stop requests that carry attack code, and challenge some suspicious requests. We keep search engines and AI crawlers allowed on purpose. We do not publish our exact rules.

1. Check what is reachable. Make sure /.env, .git, backup files and phpinfo pages cannot be fetched from the web. Test them yourself.
2. Protect every login. Put rate limits and two-step verification on each one.
3. Hide admin pages. Keep them on a path or network only you can reach.
4. Separate the log. Split requests your rules let through from requests they block before you count attacks.
5. Judge the request, not only the address. Decide by what a request asks for and carries, not only by where it comes from.

Limits of this study

• One site, 30 days. Patterns on another site may differ.
• Every figure is a lower bound because of the daily top-60 limit, and the path breakdown covers about 70% of blocked requests.
• Our log does not record query strings, headers or which rule acted, so we cannot say why each ordinary-looking request was stopped.
• Country is Cloudflare's approximate geolocation of each address.
• Counts depend on our rules, which changed during the period. We make no claim about who is responsible for any request.

Frequently asked questions

What is a .env file and why do scanners ask for it?

It is a text file many web applications use to store passwords, API keys and database details. If it is placed in a folder the web server publishes, anyone who guesses its address can read it. Scanners ask every site for it because it is a quick, high-value check.

Does a blocked request mean someone tried to hack the site?

Not always. A request can be blocked because its network is on a block list, because it asked for a secret file, or because it carried suspicious content. Some blocked requests are simply copying pages in bulk. The log alone does not show intent.

Why do large technology companies appear in raw firewall logs?

Many log entries come from rules that deliberately let verified crawlers and link-preview bots through. Counted as "events", those entries outnumbered blocked requests by more than fifty to one in our logs, which is why we counted only blocked and challenged requests.

Why are IP addresses and network names not published?

An address shows where a connection is, not who uses it, and many belong to infected devices or shared proxies. Naming addresses or companies could wrongly blame people or businesses, so we publish patterns and numbers instead.

What should a small website owner do first?

Fetch your own site at /.env, /.git/config and common backup file names. If any of them returns content, fix that before anything else.

Sources

1. Our own Cloudflare firewall event logs, 13 September to 12 October 2026 (aggregated; no IP addresses or network names retained in this article).
2. Cloudflare WAF documentation: the Skip action in custom rules
3. Cloudflare WAF documentation: Managed Rules
4. OWASP Web Security Testing Guide: Review old, backup and unreferenced files for sensitive information

If your own accounts or devices have been targeted, see our country-by-country cybercrime help hub for step-by-step reporting and recovery guides.