We Replayed Four Weeks of Our Own Edge Traffic. 97% of It Asked for Paths That Exist on Every Website. The 3% That Didn't Is the Interesting Part.
For four weeks our edge has been writing down everything it blocked or trapped. This week we stopped reading it day by day and replayed all of it at once: 39,036 blocked requests, 23,975 honeypot canary records and 1,305 requests that got past the edge to our origin, from October 2 to October 30. We compared the weeks, followed the operators, and then went and read the public code that probably wrote their wordlists.
Four findings, then what we are changing because of them.
First, almost none of it was about us. Second, the paths being asked for changed: scanners are adding the configuration files of AI coding agents to the same lists as .env and .git. Third, the operators changed faster than our blocklist can follow. Fourth, nothing we saw was an exploit. It was reconnaissance for exploitable things, at much higher volume.
What we replayed
Three of our own instruments, plus two outside ones. The edge blocks and the canary records are ours, first-party, and so is the origin honeypot that records what slips through. We joined them to our indicator graph, and then to GitHub, using the public search API only, reading and never running anything. "Membrane" here means the planes cross-checking each other: a block tells you a path was asked for, a canary tells you someone took a lure, the origin tells you what got past, and GitHub tells you where the idea came from.
Who changed
Volume went up and the number of operators went down. Edge blocks rose 19% week over week and canary hits rose 81%, while unique IPs fell from 1,213 to 757. 71% of this week's IPs had never appeared before.
The leader changed hands. Google Cloud was 45% of our blocked and trapped hits the week before and 24% this week. A dedicated-server range that was absent the week before produced 33% of all hits, nearly all of it from one operator. A range that sprays with plain curl rose about 7.6 times. Hits from Cloudflare's own network rose from 23 to 996, which is hosting abuse and not something anyone can blocklist wholesale. Amazon fell 60%, and a scraper that had hammered our blog paths for weeks, about 2,700 blocked requests a week, went to seven.
How they ask changed too. Plain tool user agents went from about 3% of hits to 44%: the two largest operators do not even pretend to be browsers. The share of hits arriving inside bursts of 60 or more requests a minute went from 12% to 53% to 70%. The largest burst was 1,537 requests in one minute from one IP, nearly all of it for the site root.
What they ask for now
Two things stand out.
The first is a long wordlist of .env backup names. .env.save.bkp, .env1, .env.original and dozens more, each requested about sixty times, mostly by one operator walking the list in order. Next to it, a random ten-character path, a test for whether every URL returns a page.
The second is AI coding agents. Over 16 days we saw four IPs ask for ten distinct paths: Claude Code, Claude Desktop, Cursor, VS Code, JetBrains Junie and Amazon Q Developer configuration files. These hold MCP server commands, tool allowlists and often keys. The first request was October 14. By October 23 three operators on three different networks had it.
We went looking for where the list came from. Public Nuclei templates already exist for these exposures: claude-settings-exposure, written by shadowhunter-92 and added on July 30, and vscode-mcp-json, written by DhiyaneshDk and added in January. Between them they cover /.claude/settings.json, /.claude/settings.local.json, /.mcp.json and /mcp.json. They do not cover .cursor, .junie, .amazonq or claude_desktop_config.json, which the sweeps also asked for. So the operators are using public templates and extending them, which is how a wordlist spreads. The vendors' own documentation lists every one of those paths, and a wordlist author only has to read it. That last link is our inference, not something we observed.
Is any of it aimed at us?
Mostly not. 3.3% of this week's requests touched anything specific to our site, against 3.5% the week before. The rest asked for paths every website has.
The 3% is more interesting than the rest. One whitepaper page was requested 76 times by one cloud provider's address space, wearing a very old Android browser identity. Twenty-two different IPs across 13 networks asked for our pricing page. And a pool of about two dozen addresses, mostly in Google Cloud, cycled through twelve AI crawler names (GPTBot, ClaudeBot, PerplexityBot, Bytespider and others) while asking for blocked paths. Google Cloud and other hosting ranges are not where those vendors' crawlers run. A user agent is a claim, and these were claims made to get through a door that is held open for the real ones.
The other half of that picture is who stopped. Several categories that earlier weeks had asked for, our feed route, the Jeevesus routes, blog paths and two AI-application scanners (Flowise and Langflow), dropped to zero or close to it this week.
Exploit or reconnaissance?
Reconnaissance. We classified every request by exploit-shaped pattern. Path traversal rose from 114 a week to 693 and then 414: variants like /js../.env, a probe for a well-known web server misconfiguration, and encoded ..%2f combined with .env. We saw requests for PHP-CGI binaries, Spring actuator endpoints, Atlassian Jira path-confusion strings, and a Docker registry catalog. We saw no log4shell strings, no PHP wrappers, no cloud metadata requests. The origin honeypot has recorded 9,103 requests since December, and exactly two were POSTs: login guesses. Nothing carried a payload.
What the membrane did and did not do
Credit where it is due: nothing got through that mattered, and the edge stopped the bursts. The weakness is timing. For the 25 heaviest IPs this week, three were already on our published blocklist before they first reached us. Eleven were listed the same day, eight were listed one to nineteen days later, and three were not listed. Fourteen of the 25 were Google Cloud addresses, most of them fresh for a day or two. An IP list is always one request behind a pool that rotates, and 71% of this week's addresses were new.
So listing is reactive by construction. That is not a failure of the list. It is what a list is.
What we are changing
A rule that does not need to have met the IP before. Flag any address that asks for 20 or more distinct paths inside 60 seconds when at least 60% of them are secret-shaped. We replayed all four weeks against that rule: it would have flagged 182 of 3,552 IPs, a median of 23 requests in, and 43% of the requests in the dataset arrived after the trigger point. A plain burst rule at 60 requests a minute flags 88 IPs. Path diversity catches about twice as many sweeps, earlier, including slow ones. It went live today in observe mode (edge-shield 2.26.0): it records and tags what it would have done and blocks nothing, because the point right now is to learn what is hitting us. When it has a few weeks of real flags we will say what it caught and what it got wrong, and only then decide whether it blocks.
Limits
The dataset is only requests we already blocked or trapped, so we cannot measure false positives against real visitors; that has to come from observe mode. Four weeks is a short window, and one of the largest operators appeared mid-window. "Listed the same day" is our own listing time and says nothing about who saw it first. The user-agent classes and the secret-shaped path pattern are ours. The idea that the AI-crawler names were cycled by one operator is an inference from the shared IP pool. The Worker only sees paths its routes send to it, so the rule covers some hosts and not others. Our Cloudflare firewall rules also run before the Worker: 17 of the 18 agent-configuration blocks were answered there, not by the Worker, so the new rule only ever sees what that layer lets through.
Five percent of this is wrong somewhere. It always is.
If this was useful, or was not, rate it at the bottom of the page.
Every indicator in this post is in the feed. Free.
1.58M+ IOCs, STIX 2.1 / TAXII, 88% novel vs ThreatFox, exploited-CVE leads ahead of CISA. No credit card — a free API key in 30 seconds, and you can audit every claim above against the live endpoints.