A Scanner Hid Behind Cloudflare. A Cloudflare Starter Template Gave It Away.

One cohort, three ways in

Cohort membership needs two predicates together: a source address in one of the lanes in Table 1, and one of exactly seven user-agent strings. Both Cloudflare lanes are shared egress, so neither predicate is enough alone; on 09-12 the address predicate admitted 23 requests that the user-agent predicate excluded.

104.28.0.0/16 is Cloudflare space absent from Cloudflare's published proxy ranges, and the WARP and Gateway egress docs describe shared client egress without naming the range. Darktrace and GreyNoise Labs have both documented scanning from it. WARP is likely, not certain.

The same strings and header profiles appear on all three lanes; the lanes differ in transport, not behaviour. Table 2 lists the strings with 09-12 cohort counts; they sum to 19,363.

Googlebot and ChatGPT-User are impersonation: OpenAI's published IP list for ChatGPT-User has no prefix in 104.28.0.0/16 and no IPv6 prefix, and the same addresses sent the other six strings within the same seconds.

The busiest address sent 6,294 requests over 23 hours in 57 bursts, median 115 requests over 60 paths in 57 seconds, starts a median 16 minutes apart. The probe path /aZ9xQ7kL3m opened 52 of the 57, and across all 456 cohort bursts that day it sat in the first three requests of 208. A scheduler re-scanning every quarter hour fits; it is a hypothesis, not an observation. The cohort sent only GET requests and never asked for /robots.txt.

The 231 paths are a secrets list: 25 .env variants, 17 WordPress backup and log paths, 14 platform configuration files including wrangler.toml, .dev.vars, fly.toml and vercel.json, and the usual Git metadata, cloud credential, database dump and MCP configuration files. wrangler.toml and .dev.vars were not in SecLists or nuclei-templates when I searched on 2026-09-13; Cloudflare's docs say .dev.vars holds local development secrets and wrangler.toml holds account IDs and bindings. A scanner reaching targets through Workers is asking them for their Workers credentials.

The Workers fleet behind one address

Cloudflare's HTTP header reference states: "In cross-zone subrequests from one Cloudflare zone to another Cloudflare zone, the CF-Connecting-IP value will be set to the Worker client IP address '2a06:98c0:3600::103' for security reasons." The same page says CF-Worker "is set to the name of the zone which owns the Worker making the subrequest". Because the honeypot stores headers, the fleet is countable: 877 distinct cf-worker values on 09-12, 870 of them *.workers.dev account labels, a median of 7 requests per account that day. 849 of the labels were first seen that day, 603 of them between 01:00Z and 04:00Z. A 2025 Community thread describes the same pattern and notes the address cannot be blocked by IP at the WAF.

The proxy pool and the redirect that leaked through it

1. All 3,958 requests from the five hosting-provider addresses across 09-12 and 09-13 carry a Referer. 3,946 have the form https://<script>.<account>.workers.dev/proxy?modify&proxyUrl=https%3A%2F%2Frehagen.net%2F<path>, and in 3,945 the encoded path equals the path requested from me; the other 12 use a different proxy script's /?url= form.
2. Those Referers name 3,629 distinct hostnames, 3,627 account labels and 3,599 script names, none of them among the 871 cf-worker accounts seen across the two days.
3. /proxy?modify&proxyUrl= is the example link printed by the landing page of Cloudflare's create-cloudflare "common" template. Its proxy.js has no allowlist and no authentication, and passes the incoming request to fetch() as the init argument:

const proxyUrl = url.searchParams.get('proxyUrl');
const modify = url.searchParams.has('modify');

if (!proxyUrl) {
	return new Response('Bad request: Missing `proxyUrl` query param', { status: 400 });
}

// make subrequests with the global `fetch()` function
let res = await fetch(proxyUrl, request);

1. Cloudflare's Request documentation states: "The default for a new Request object is follow. Note, however, that the incoming Request property of a FetchEvent will have redirect mode manual." With manual, "the 3xx redirect response will be returned to the caller as-is."
2. https://rehagen.net/<any path> answers 301 with Location: https://jon.rehagen.net/<path> (curl, 2026-09-13).
3. Go's net/http client follows 301 by default, and the comment on refererForURL in client.go reads: "refererForURL returns a referer without any authentication info or an empty string if lastReq scheme is https and newReq scheme is http. If the referer was explicitly set, then it will continue to be used."
4. On the 104.28 lane the Referer is https://rehagen.net/<same path> on all 9,382 requests.

The mechanism that fits all seven: the scanner's client requested a pool Worker's /proxy URL with proxyUrl set to the apex path. The template fetched the apex with redirect mode manual, inherited from the incoming request, got my 301 and returned it unchanged. The client followed Location to jon.rehagen.net directly, outside the proxy, with Referer set to the Worker URL it had just left. On the 104.28 lane the same client fetched the apex directly and followed the same 301, which is observation 7.

Where the evidence stops:

• The pattern matches steps 3 to 6 on 3,945 of 3,958 requests. The alternative, 3,600 fabricated decoy Referers in the template's own link format, has no supporting evidence and no purpose I can see.
• Browsers and some HTTP wrappers also follow redirects and set Referer from the previous hop. Go is a likely client, not a demonstrated one.
• The five hosts ran the client or are its immediate egress; a VPN exit or forward proxy would look the same, and Shodan lists a Squid service on one of them. Confidence is medium-high.
• Whether the 3,629 hostnames are the operator's accounts, a rented proxy service, or third parties' default deployments, I cannot determine. I am not reproducing any label; some may belong to uninvolved people.

What it cost and what the LLM layer bought

384 live model calls on a 20,000-request day, about 0.50 USD, with a week-long response cache and a per-path ceiling absorbing the rest. 1,126 cohort requests received a response carrying a planted artifact; none reused an identifier in the window, and none followed a link from a generated response. Reuse elsewhere would be invisible to me. It is one observation, not a comparison arm, and it suggests wordlist scanners do not read what they get.

Where this sits in the public record

Searched 2026-09-13; each negative is bounded by what I searched. /aZ9xQ7kL3m has no GitHub hits beyond my own tracker and is absent from SecLists and nuclei-templates; because ffuf accepts a caller-supplied calibration string, a constant probe does not prove a private tool, but it is a stable correlation indicator. No public scanner ships the seven-string set. GreyNoise's 2026-08-28 report describes 824 IPs with forged AI-crawler identities, none matching OpenAI's lists and none requesting /robots.txt; hrbrmstr documents a similar kit with a different rotation. I found no report of the template's /proxy route used as a proxy pool.

What an operator behind Cloudflare can do

Blocking is the wrong tool for the two Cloudflare lanes. The useful moves are about visibility:

• Log cf-worker at the origin; Cloudflare's header reference shows the nginx log_format line. One unblockable address becomes a list of zones you can count and report.
• Match on cf.worker.upstream_zone at the edge, not on the header, which WAF rules run before. Transform Rules have matched on it since June 2025, so a header stamped worker when it is non-empty and cloudflare-client when the source ASN is 13335 gives your logs the lane split. Tag and log; do not block AS13335; validate on owned traffic first.
• Read cf-ipcountry as the exit country, not the operator's.
• Keep an apex redirect; it hands you the address that follows it, when the client follows redirects and egresses directly.

What I am changing

• Promote cf_worker and a parsed Referer host to first-class columns.
• Turn the three cohort properties (probe path, exact user-agent set, the wrangler.toml and .dev.vars pair) into a classification after a false-positive check on other weeks.
• Report Cloudflare egress as "Cloudflare-fronted" instead of as countries, and add the edge tag above, tag-only.
• Split "AI responses" into live calls, cache hits and ceiling denials, so the next summary email does not overstate a day by a factor of 36.

Methods and limits

The cohort rests on exact user-agent matching within known egress ranges; it cannot separate one operator from several customers of one tool, and it would miss the same operator with a different string set. Every Cloudflare-lane figure depends on cf-connecting-ip, cf-worker and cf-ipcountry as Cloudflare sets them, application headers rather than TCP peer addresses. The redirect mechanism is reconstructed from the Cloudflare Request API docs, the workers-sdk template at commit 164e4fb (dated 2026-09-12; proxy.js unchanged since 2023 and still present at main on 2026-09-15) and Go's client.go at master on 2026-09-13, not reproduced. Nothing here contacted the scanner's infrastructure.

On 2026-09-15 I reported the 871 subrequest accounts and the 3,627 proxy-pool labels to Cloudflare Trust and Safety as an abuse report, and raised the template's unauthenticated /proxy route in workers-sdk issue #15660. Whether a demo template should ship an open proxy is Cloudflare's call. This dataset shows it in use at scale.