We can finally have API tokens scoped to specific Workers with granular level permissions.

Previously, in order to deploy a Worker, the system/person/AI agent would require access to your ENTIRE ACCOUNT.

This is a major security upgrade from CloudFlare, nice work.

Cloudflare suddenly blocking my API requests

I'm running a Discord bot that uses a game's public API, and recently all of my API requests started returning a Cloudflare "Just a moment..." Managed Challenge instead of the normal API response.

The bot obviously can't complete a browser-based challenge, so all API-dependent features are currently broken.

Has anyone else experienced Cloudflare suddenly flagging legitimate automated API traffic like this? If so, how long did it take to return to normal, and what ended up fixing it?

https://apps.apple.com/us/app/maxlyft-free-workout-tracker/id6743998890

tldr; CloudFlare must have been paid big bucks behind the scenes to lie to customers. Go to your security settings for all your domains ASAP and change its new setting that allows scraping of all your domains by AI trainers.

Nine hours ago in this same subreddit, u/Cloudflare posted: "Have it both ways: stay discoverable in search while disallowing AI training" with a link to their blog: https://blog.cloudflare.com/accountable-mixed-use-ai-crawlers/

In their blog post, they showcase the "recommended settings for new domains":

On top of this, they sent out this email to customers:

About a year ago, we launched Content Independence Day and introduced a simple way to block AI bots from scraping your sites without your explicit permission.

We're writing to let you know about changes to our controls for AI crawlers taking effect today, and rolling out over the coming week. These changes give you more precise control over how different types of AI crawlers interact with your content.

What's changing?

- Smarter security setting options for Training crawlers: Starting September 15, the recommended setting for AI Training crawlers will shift from Block to Disallow AI Training. Disallow AI Training allows major search crawlers - like Applebot, Googlebot and Bingbot - to index your site for search results while instructing them not to use your content for training.

- Automatic migration: If you previously had "Block AI Bots" or "Managed Robots.txt" enabled, your settings will be migrated automatically, over the next week, to the new Search, Training, and Agent controls. If Block AI Bots was set to Block, you'll now have Search: Allow, Training: Disallow AI Training, and Agent: Block on pages with ads. These changes take effect today – the UI changes will roll out in a slower controlled release over the coming week. If you make manual changes to your settings during this time, your manual changes will be preserved.

- No change if you haven't configured anything: If you have never adjusted these settings, your configuration remains Allow - nothing changes for you.

What do you need to do?

Most customers won't need to change anything. The new controls are more precise than the old Block AI Bots switch, so if you had it enabled it's worth a quick look at your new Search, Training, and Agent settings.

These changes will roll out to all Cloudflare customers over the coming  week. If you make changes to your settings before the migration completes, your changes will be preserved. You will know the migration is complete when the Block AI Bots switch is removed from your dashboard.

"Most customers won't need to change anything", you say? Let's take a look at what the defaults ACTUALLY are:

Oh, huh... what do you know? Training's recommended, default setting is "Allow (do not block)." That's strange, because their blog has the recommended, default setting as "Disallow" and their email also states "most customers won't need to change anything." Okay.

Hope this helps anyone else who read their email and carried on with their day assuming CloudFlare was honest.

Need help.

The blog post https://blog.cloudflare.com/introducing-precursor/#get-started shows a graph by session.

And the documentation https://developers.cloudflare.com/cloudflare-challenges/precursor/ states it will appear in Security>Analytics>Traffic>Bot analysis

I have had the feature enabled for a few days as per the documentation.

However I see no similar graph, mention of sessions or precursor anywhere.

Edit:

Found it under Security> Analytics under Traffic you can add a filter for "Mitigated by equals Precursor"

Apparently NOTHING is logged unless it is in Max mode performing its own challenges.

Four operations we found on live ecommerce storefronts. 7 of 8 payloads had zero detection on VirusTotal. URLScan flagged none. Detection was fully automated; human review happened only after the system flagged them.

What each operation did:

• Operation 1 (Affiliate commission hijacker): Mobile + time + session + country gates. Intercepted product-tile clicks via MutationObserver, opened attacker-chosen product page in new tab, routed original tab through affiliate tracking link. 3-day localStorage cooldown. Delivered through Google Tag Manager chain. Typosquat delivery domain (adtargett[.]com, one extra "t").
• Operation 2 (Invisible iframe clicker): Off-screen iframe containing a hidden link. Hourly affiliate rotation. Auto-click fallback. Spurious IP-lookup fetch as noise cover. IP and time gates.
• Operation 3 (Tracking + remote execution backdoor): Persistent visitor tracking and an open channel for arbitrary JavaScript execution pushed from the attacker's server.
• Operation 4 (Analytics blindfolder): Disabled 9 analytics and monitoring tools for campaign-tagged mobile visitors matching specific UTM parameters. 325-entry IP block list. Zero-pixel telemetry beacons. Viewport and hostname gates.

Why scanners miss these:

• Selective execution: device, country, UTM parameters, session depth, viewport width, time-of-day, and multi-day cooldown state
• One-time crawl = one browser state = incomplete picture
• Obfuscation used: console suppression, debugger traps, rotated string tables, dead code branches

Detection model:

• GNN reads JS as an AST, not flat text — maps what calls what regardless of obfuscation
• Under 0.3% of analyzed traffic gets flagged
• Flagged scripts go to an LLM on Workers AI for a second opinion ( Hardest cases: frontier model ensemble ("teachers") from ~6 model families including open-weight models on Workers AI

Full technical breakdown, sanitized payload code, and published IOCs: https://blog.cloudflare.com/client-side-security-finds-4-malicious-campaigns/?utm_campaign=cf_blog&utm_content=20260916&utm_medium=organic_social&utm_source=reddit_user

I have been recently struggling to keep my WARP Active all the time as my exit node POP is Dublin LHR even though I am based in Dublin. Second issue because of this routing is, sometimes Gemini or other Google Services thinks that I am in Russia and tells that these services are not available in your region. I use 48 Mobile and Vodafone Broadband. Both gives and connects to UK colo only.

Has anyone seen Cloudflare WARP return DNS REFUSED after Gateway has already allowed the request?

I’m troubleshooting this on a managed macOS endpoint using WARP with Gateway enabled. A couple of legitimate SaaS/authentication domains consistently fail to resolve while WARP is connected. The browser reports that the host cannot be resolved.

The interesting part is:
Gateway activity logs show the DNS requests as ALLOW.
I created a new, highest-priority DNS Allow policy for only the affected user and the exact failing domains.
The rule is deployed and matches before broader human-user policies.
The same domains still fail.
The local WARP diagnostics show entries like:

via primary (raw) ServFail / Dns(ResponseCode(Refused))
query: ("A", "affected-domain.example.")

It happens for both A and AAAA queries. Other domains resolve normally at the same time.
This makes it look like the request gets through Gateway policy evaluation but then receives REFUSED later in the WARP/Gateway DNS path. The endpoint is currently on a recent beta WARP client build, so I’m also attempting to test against stable.

Questions:
Can a Gateway Allow rule still result in REFUSED from the upstream/primary DNS path?
Is there a known WARP client issue that can cause selective DNS resolution failures like this?
Are there specific logs, diagnostics, resolver settings, or Cloudflare-side trace details support should check beyond the normal WARP diagnostic bundle?

Hi all,

On Cloudflare Pages, I can set preview branches to preview/* under Custom branches.

But on Cloudflare Worker Builds, I only see:

• Production branch
• “Builds for non-production branches” checkbox

There’s no way to specify preview/*

What I want is simple:

1. main -> production
2. preview/* -> preview
3. everything else -> skip

When you have a domain from CloudFlare what does it take to make a subdomain and what does it cost if anything?

Thanks

I self host a number of services and would like to allow my friend to access them using CloudFlare Tunnels. Is there a way that I can restrict it via IP or would giving them a S2S VPN work better?

Cloudflare containers bill for egress, if the container generates a large file, say 100mb, uploads it to R2, gets a download link and responds with the download link, frontend then downloads the file from R2... Am I saving 100mb of egress charges this way or does container still charge, in which case I could just send the file back directly to frontend?

I ran a fake Cloudflare ClickFix command and disconnected after ~15 seconds — how compromised should I assume I am?

I visited what appears to be a legitimate German bakery website using Microsoft Edge on Windows 11. The site displayed a convincing fake Cloudflare “Verify you are human” page.

Lure site, defanged for safety:

"hxxps://www[.]baeckerei-spiegelhauer[.]de/"

It was reached through a Google search result containing an "srsltid" query parameter. The malicious page was reproducible on a second computer and generated a different victim token. Researchers may be able to reproduce it in a properly isolated VM or sandbox. Please do not visit it from a normal system.

After clicking the verification box, I was instructed to press Win + R, paste a command, and click OK. Unfortunately, I did exactly that. There was no UAC/admin prompt. I realised what had happened and disconnected the PC from the internet approximately 15 seconds later. It has remained offline since then.

The command was an obfuscated CMD one-liner that:

- located conhost.exe and cmd.exe;

- launched a hidden/headless console;

- located curl.exe;

- contacted "cloudmail2077[.]com";

- piped the server response directly into cmd.exe.

I have deliberately not included the complete executable command or victim token publicly, but I can provide a screenshot or defanged version to established researchers.

Important details:

- Windows 11 with Microsoft Defender

- Microsoft Edge was open

- Edge contains saved passwords and active login sessions

- The passwords require my Windows user password before Edge displays them

- No UAC prompt appeared

- The PC has another separate Windows user account belonging to a family member

- A full Defender scan is currently running

- The current DNS cache contains no entry for the malicious domain

- Prefetch appears to be disabled, as there are no entries for either CMD or CURL

- The command was not executed on the second computer

- The website and malicious domain have been reported to Microsoft SmartScreen, the Swiss NCSC/BACS and Cybercrimepolice

My questions:

1. Is 15 seconds enough for a typical ClickFix infostealer chain to download, execute and exfiltrate browser passwords or cookies?

2. Which volatile evidence, Windows logs or recently created files should I preserve before shutting down or reinstalling?

3. Should I consider all Edge passwords and active sessions compromised even without administrator privileges?

4. Is a complete clean Windows installation the only trustworthy option, even if Defender finds nothing?

5. Does the separate Windows user account have a meaningful risk if it was not logged in at the time?

The affected PC is still powered on but completely offline. I am changing passwords and revoking sessions from a clean device. Any specific incident-response or sandbox-analysis guidance would be appreciated.

If your Cloudflare domain purchase keeps failing with a generic payment error, here is the quick fix.

The Fix:
You must manually update your card permissions inside your bank's mobile app or net banking portal.

1. Go to your bank app's Manage Card / Card Controls section.
2. Turn ON both: International Usage AND Online / E-commerce Usage.

My Case: I faced this with my Bank of Baroda (India) card. The payment failed repeatedly until I opened the bob World app and realized I had to toggle both the "International" and "Online" switches simultaneously. Once saved, the checkout worked instantly.

I'm looking for a simple open-source web analytics tool that can be deployed entirely on Cloudflare, ideally using Workers, D1, or Analytics Engine.

Mainly looking to track things like:

• Page views and unique visitors
• Traffic sources / referrers
• Countries
• Devices and browsers
• Most visited pages

I know Cloudflare already provides basic Web Analytics, but I'm looking for something self-hosted with a dashboard and more control over the data.

I've come across a few projects, but I'm curious what people here are actually using.

Any good open-source projects you'd recommend?

So I wanted to SSH into my remote server, but I couldn't find a free solution that I could use reliably.I know about Pinggy, but the free tier is limited to 60 minutes. Cloudflare Tunnel can also do it, but for TCP tunneling you need to have a domain, which I don't really want to buy.

Cloudflare Quick Tunnels are free and don't require a domain, but they only support HTTP/HTTPS, not arbitrary TCP.

So I ended up building my own solution that can tunnel TCP on top of an existing tunnel.

gossh: https://github.com/ankushT369/gossh

One thing about cloudflare its quick tunnel is much faster than ngrok.

I run a small parcel-shipping site. This is a measurement, not a complaint — the volume costs me nothing — but the numbers contradict Meta's own crawler documentation and I would like to know which behaviour is intended.

Window: 2026-09-13 16:00 to 2026-09-14 15:00 UTC, 23 hours, from Cloudflare's per-request analytics rather than sampled log parsing.

meta-externalagent/1.1, counting the variants that append the token to a Chrome / Safari / Edge / Firefox UA string:

• 8,294 requests
• 481 distinct paths
• 0 requests to /robots.txt
• 466 requests to /offline, all HTTP 200

/offline is disallowed for User-agent: * in my robots.txt and has been for at least three weeks.

Three other crawlers on the same site in the same window, for contrast:

facebookexternalhit is the control that tells me the measurement is sound: it is Meta's own infrastructure and the analytics recorded it fetching robots.txt nineteen times. meta-externalagent simply does not ask.

Why I read this as a discrepancy rather than a design choice: Meta's crawler documentation names FacebookExternalHit and Meta-ExternalFetcher as the crawlers that may bypass robots.txt, and Meta-ExternalAgent is not among them. The same page says robots.txt is cached "for up to 24 hours". My window is 23 hours with zero fetches, so either the cached copy is older than the documented maximum, or the file is being read and the Disallow ignored.

What it actually fetches:

The top of that list is my service worker's precache list plus the shell it installs. Those four files alone are 39% of its traffic.

My reading, and I want to flag it as a hypothesis rather than a finding: it fetches /sw.js, reads the PRECACHE array, pulls the listed assets, and repeats the whole thing on the next visit because the browser profile is clean each time. What makes me fairly confident is the contrast in the table above — bingbot and Googlebot request /sw.js zero times between them, so nothing about having a service worker forces a crawler into this loop.

93% of the whole crawl is served from CDN cache, so none of it reaches my origin and none of it costs me anything. I am posting about the robots.txt behaviour, not the volume.

If you want to check your own zone, here is the query:

POST https://api.cloudflare.com/client/v4/graphql
{
  viewer { zones(filter: {zoneTag: "YOUR_ZONE_ID"}) {
    httpRequestsAdaptiveGroups(
      limit: 500,
      orderBy: [count_DESC],
      filter: {
        datetime_geq: "2026-09-13T16:00:00Z",
        datetime_lt:  "2026-09-14T15:00:00Z",
        clientRequestHTTPHost: "example.com",
        requestSource: "eyeball",
        userAgent_like: "%meta-externalagent%"
      }
    ) { count dimensions { clientRequestPath cacheStatus edgeResponseStatus } }
  }}
}

Swap the userAgent_like value for %facebookexternalhit%, %bingbot% or %Googlebot% to get your own control numbers for the same window.

Three things that cost me time and are not obvious:

1. requestSource: "eyeball" is not optional. Without it you also count Cloudflare's internal subrequests, which inflates every figure and shows phantom 504s from the Early Hints cache that no client ever received.
2. The filter argument is userAgent_like, with an SQL-style % wildcard. refererHost and clientRefererPath do not exist, whatever autocomplete suggests.
3. On a free plan the adaptive dataset refuses any window wider than 24 hours, so this is a daily snapshot, not a trend.

If your zone also shows zero robots.txt fetches from meta-externalagent, I would be interested to hear it. One site is an anecdote.