Cloudflare began scanning Authorization headers on 20 August 2026, and the docs did not change

Summary. On 20 August 2026 Cloudflare extended leaked credentials detection to the Authorization request header, decoding HTTP Basic Authentication credentials and checking them against its leaked-credential database. The changelog states the change "was applied automatically for zones with leaked credentials detection enabled. No configuration changes are required." On Free plans that detection is on by default, and Cloudflare says 30 million Internet properties, roughly 20% of the web, sit behind it. The feature page describing what gets scanned carries a modified date of 5 May 2026 and does not mention the Authorization header at all. It also lists 3 possible values for the Exposed-Credential-Check header sent to your origin, where the managed transforms reference lists 4. The missing value is 3. Cloudflare's own research puts 52% of detected authentication requests as containing leaked passwords against a database of over 15 billion records, and 95% of leaked-password login attempts as bot traffic. The added coverage costs nothing: Cloudflare calls the check "a free feature", so this arrives at $0 on the invoice and as a behaviour change nobody approved.

What actually changed

The changelog is specific about the mechanism. Detection "now scans the Authorization request header for Basic Authentication credentials. Previously, the detection only inspected request bodies, query strings, and headers for well-known web applications or custom detection locations, which meant credentials sent through HTTP Basic Authentication were not covered by default."

The new scan "decodes the Authorization: Basic <credentials> header and compares the extracted username and password against Cloudflare's database of leaked credentials, the same way as other default scan locations."

That last clause is the operative one. Matches populate the same fields you may already be acting on, so existing rules fire on the new input without being edited.

The default scan already covered Drupal, Joomla, Ghost, Magento, Plone, WordPress and Microsoft Exchange OWA, plus "generic rules for other common web authentication patterns", per the leaked credentials detection page. That page's structured data reports a modified date of 5 May 2026. The Authorization header does not appear on it. The traffic detections page, updated 19 August 2026, does not mention it either.

Basic auth is how machines log in, and that is the exposure

A browser login form is a human typing a password. An Authorization: Basic header is usually something else: a cron job, a webhook receiver, a monitoring probe, a legacy SOAP endpoint, an internal service calling another internal service. RFC 7617 defines the scheme as transmitting "credentials as user-id/password pairs, encoded using Base64", and warns that it "is not a secure method of user authentication, nor does it in any way protect the entity, which is transmitted in cleartext across the physical network used as the carrier."

Base64 is an encoding, not encryption, so any middlebox that wants to read a Basic auth credential can. Cloudflare has now decided to.

The practical consequence is a category error waiting to happen. Service account passwords are frequently old, frequently shared, and frequently drawn from the same weak pool that ends up in breach corpora. If a service credential appears in the Have I Been Pwned matched-passwords dataset that Cloudflare uses, then a custom rule written to block cf.waf.credential_check.password_leaked will start blocking a machine client that has authenticated successfully for years. Nothing in your configuration changed. Nothing in your deployment changed. The scan location changed underneath both.

Cloudflare documents the privacy side clearly: "Cloudflare does not store, log, or retain plaintext end-user passwords when performing leaked credential checks. Passwords are hashed, converted into a cryptographic representation, and then compared against a database of leaked credentials." That addresses retention. It does not address the operational blast radius of a rule that now sees traffic it did not see on 19 August.

Two Cloudflare pages disagree about the header your origin parses

Leaked credentials detection can add an Exposed-Credential-Check request header to matching requests, so your origin can warn the user. The detection page describes the value as "for example, 1 if both username and password were a leaked pair, 2 if the username was leaked, or 4 if only the password was leaked."

The managed transforms reference lists a fourth value the detection page never mentions.

An Enterprise origin handler written from the detection page will not have a branch for 3. Depending on how it was coded, that request either falls through to a default deny or falls through to a default allow, and both are wrong. The reference also notes that on Free plans, where only password leakage is knowable, "Cloudflare will add an Exposed-Credential-Check: 4 header to the request."

Where two vendor pages disagree about a value your code switches on, the safer read is the reference page, and the correct fix is a default branch that logs the unexpected value rather than guessing.

What you actually get depends on your plan

The fields exist on paper for everyone. They do not populate for everyone.

Two details in that table matter more than they look. First, custom detection locations are Enterprise-only and capped at 10, and http.request.headers is one of the permitted fields, so an Enterprise team may already have hand-built an Authorization-header location. Cloudflare has not documented what happens when a custom location now overlaps a default one. Second, on Free plans the docs state that "the leaked credentials detection is enabled by default, and no action is required", which means the Authorization-header scan reached the largest population of zones without anyone opting in.

That default-on posture was already contentious. A documentation issue filed against Cloudflare's own repository on 17 March 2025 argued that the docs "breeze past the fact that the Leaked Credentials Detection can view your credentials as well as the fact that this is enabled by default on free accounts", and asked for the kind of reassurances a compliance reviewer expects. The issue was closed the next day. Seventeen months later the same page has gained a new default scan location and not a new sentence about it.

The numbers Cloudflare published

The scale case for doing this is strong, and it is Cloudflare's own data rather than a vendor estimate. In an application security analysis published 17 March 2025, Radwa Radwan of Cloudflare wrote that "41% of successful logins across websites protected by Cloudflare involve compromised passwords", measured on traffic between September and November 2024.

The same analysis reports that "52% of all detected authentication requests contain leaked passwords found in our database of over 15 billion records, including the Have I Been Pwned (HIBP) leaked password dataset", and that "95% of login attempts involving leaked passwords are coming from bots, indicating that they are part of credential stuffing attacks."

Extending that check to Basic auth is defensible security engineering. Shipping it as a silent default while the reference page sits at 5 May 2026 is what turns a good change into an incident.

India-specific considerations

Indian teams have a sharper reason to care, and it cuts both ways.

Section 8(5) of the Digital Personal Data Protection Act 2023 obliges a Data Fiduciary to take reasonable security safeguards to prevent a personal data breach. The Act's schedule sets the penalty for breaching that obligation at an amount that "may extend to two hundred and fifty crore rupees", or ₹250 crore. Detecting that your users are authenticating with credentials already circulating in breach corpora is evidence of a safeguard, and the Exposed-Credential-Check header gives you a mechanism to force a reset.

The other side is the transfer question. Section 16 of the same Act lets the Central Government restrict transfers of personal data for processing to notified countries. Credential checking happens at Cloudflare's edge on hashed values, and Cloudflare states plaintext passwords are neither stored nor logged, so the exposure is narrower than it first reads. It is still a processing step performed outside your application boundary, and it belongs in your record of processing activities rather than being discovered during an audit. Our DPDP Act engineering playbook covers how to document that class of edge processing.

What to check this week

Four checks, ordered by how badly the surprise lands.

List every custom rule and rate limiting rule that references cf.waf.credential_check.password_leaked or any sibling field with a block or challenge action. Those are the rules whose input set just grew. Move them to log for a week if you have any machine clients on Basic auth.

Inventory which of your endpoints accept Authorization: Basic. Internal APIs, webhook receivers and legacy integrations are the usual holdouts, and they are the ones with service passwords nobody has rotated.

Check whether the Add Leaked Credentials Checks Header managed transform is on. If it is, read your origin's handler and confirm it has an explicit branch for value 3 and a safe default for anything unrecognised.

Look at Security Analytics for the days either side of 20 August 2026 and compare the volume of requests with a leaked-credential match. A step change on that date is this feature, not an attack.

Longer term, the durable fix is not a WAF rule. Basic auth on a machine-to-machine path should become a scoped token with a rotation policy, which is the same argument we make in our write-up of credential handling for AI agents.

What is still unknown

Cloudflare has not stated whether Authorization: Bearer values are inspected, whether Digest authentication is in scope, what precedence applies when an Enterprise custom detection location targets the same header, or whether the Free-plan default-on behaviour extends to this new scan location in every region. None of those are documented as unsupported. They are undocumented, which is a different and less comfortable thing. Test against a staging zone before you write a rule that depends on any of them.

FAQ

How eCorpIT can help

A default-on scan that changes what your block rules see is an application security change, not a vendor announcement. Our senior engineering teams inventory the endpoints still using Basic auth, move credential rules to log before they block, and replace machine passwords with scoped, rotatable tokens. eCorpIT is ISO 27001:2022 certified and builds applications aligned with DPDP Act requirements. If Basic auth is still holding up an internal integration, book an application security review and we will map the exposure with you. The rollout mechanics sit in our code scanning and application security rollout service, and the wider edge-detection picture is covered in our comparison of Cloudflare session and bot detection options and in our web platform guide for 2026.

References

1. Leaked credentials detection now scans Authorization headers, Cloudflare Changelog, 20 August 2026

1. Leaked credentials detection, Cloudflare WAF documentation

1. Traffic detections and availability by plan, Cloudflare WAF

1. Managed transforms reference, Add leaked credentials checks header, Cloudflare Rules

1. Get started with leaked credentials detection, Cloudflare WAF

1. Password reuse is rampant, Cloudflare, 17 March 2025

1. RFC 7617, The Basic HTTP Authentication Scheme, IETF

1. Pwned Passwords, Have I Been Pwned

1. Leaked Credentials Detection docs needs better explanation, cloudflare-docs issue 20903

1. Custom rules, Cloudflare WAF

1. Rate limiting rules, Cloudflare WAF

1. Security Analytics, Cloudflare WAF

1. The Digital Personal Data Protection Act 2023, sections 8 and 16 and the schedule, Ministry of Electronics and IT

Last updated 23 August 2026.