Behind a CDN Is Not Protected: Origin IP Leaks and the WAF Bypass

The Nisura Team · 13 October 2026

A question we get from customers reading their own exposure report: “this host is behind Cloudflare — shouldn’t that lower the score?” It is a fair instinct. A CDN with a WAF in front of it is a real control, it costs real money, and it blocks real traffic. But the answer in our engine is no, and the reason is not stubbornness — it is that the premise is usually false. A CDN only protects the origin if the origin is unreachable directly, and in the measured majority of cases, it isn’t.

Discounting risk for CDN-fronting would also contradict a check we already ship: when a scanned apex sits behind a CDN, Nisura goes looking for the paths around it, and reports what it finds as a DDoS/WAF-bypass exposure. You cannot credit a control in one column and flag its failure in another.

Does a CDN protect the origin server?

A CDN/WAF is a reverse proxy. Your DNS points at the provider’s edge; the edge reads the hostname from the TLS SNI field (or the HTTP Host header), applies caching and filtering rules, and then forwards what’s left to your origin server, over the public internet. That last clause is the whole problem. As Zafran’s research team put it in their 2024 BreakingWAF analysis, the origin’s IP and port are treated as “a secret in the design principles of CDN/WAF services” — and keeping that secret is “the primary (and potentially only) line of defence” unless the customer additionally configures the origin to reject anything that didn’t come from the edge.

That configuration is on you, not on the provider. Allowlist the CDN’s IP ranges, validate a pre-shared header, or enforce mTLS — each is a change you make on every origin box. Zafran’s internet-wide scans found those measures “are rarely implemented”. So the CDN is a control that is only as strong as a secret that leaks constantly.

How the origin IP leaks: eight measured vectors

This is the best-measured problem in external attack surface management, and it has been for a decade. In Maneuvering Around Clouds: Bypassing Cloud-based Security Providers (ACM CCS 2015), Vissers, Van Goethem, Joosen and Nikiforakis built CloudPiercer, ran eight origin-exposing vectors against 17,877 domains protected by five providers (Cloudflare, Incapsula, DOSarrest, Prolexic, Sucuri), and verified each candidate IP really served the site. The headline: 71.5% of protected domains were bypassable — 72.5% of the Cloudflare-protected subset. 42% leaked through more than one vector, and 19% would have had to fix at least three before they were safe.

Rates across all five providers, from Table 2 of the CCS 2015 paper (PDF). Per-provider figures differ: subdomain exposure hit 48.9% of Cloudflare and 51.5% of Sucuri customers, but only 3.3% of DOSarrest’s — they issued dedicated per-customer IPs, so no Host header was needed to route.

Is origin exposure still a problem today?

Zafran re-ran the experiment at scale in 2024 against the Fortune 1000. They harvested ~700K company domains from Certificate Transparency logs, identified 140K of them as CDN/WAF-fronted, scanned the IPv4 space for TLS certificates on port 443, and matched certificate names back to those domains. The result: 8K domains mapped to 36K directly reachable backend servers. After verification and filtering, 2,367 exposed origin servers remained, of which 2,028 domains at 135 different Fortune 1000 companies were assessed with high confidence. The impacted domains were owned by nearly 40% of Fortune 100 companies and 20% of the Fortune 1000. Financial services made up over a third of affected companies. Affected domains included chase.com, which JPMorganChase fixed after disclosure; the researchers demonstrated impact with a 20-second denial of service against a Berkshire Hathaway subsidiary.

Two details matter more than the headline. First, the authors are explicit that their numbers are a floor: they scanned only port 443, only IPv4, and only companies whose domains they could attribute automatically — and they believe most origins listen on non-standard ports. Second, they checked how many exposed origins actually enforced mTLS. Censys showed over 200,000 hosts presenting a Cloudflare Origin CA certificate; of a random sample of 1,000, 780 answered a request successfully and only 130 responded in a way consistent with a client-certificate requirement. Roughly 13% enforcement, generously counted.

Cloudflare documents these leak vectors itself

This isn’t a vendor-versus-researcher dispute. Cloudflare’s own Protect your origin server guidance tells customers to audit DNS-only records “(SPF, TXT, and more) to make sure they do not contain origin IP information”, not to host mail on the same server as the protected web resource (bounces reveal the mail IP), and to rotate the origin IP after onboarding, because “historical records are kept and would contain IP addresses prior to joining Cloudflare”. That is the CloudPiercer vector list, written by the vendor, as deployment advice.

The same page grades the countermeasures honestly. Cloudflare Tunnel — where the origin has no publicly routable address at all — is “very secure”. Secret-header validation is “moderately secure”. And the network layer option, allowlisting Cloudflare’s IP ranges, is weaker than it looks: Vienna-based Certitude Consulting showed in Using Cloudflare to bypass Cloudflare that both the CF IP allowlist and Authenticated Origin Pulls with the shared Cloudflare certificate trust Cloudflare, not your tenant. An attacker points their own Cloudflare zone at your origin IP, turns every protection off in their account, and tunnels the attack through the same infrastructure you allowlisted. Cloudflare first closed the report as informative, then re-rated it High (7.5) and updated its documentation and dashboard. Mitigations: per-hostname or per-zone origin pulls with your own CA, Host-header validation, dedicated egress IPs (Aegis) — and keeping the origin IP confidential.

Should a CVSS score be lowered for a WAF or CDN?

The tempting shortcut is to encode “it’s behind a CDN” as a severity discount. FIRST’s CVSS v4.0 User Guide is specific about when you may do that, and the conditions rule this case out.

Under Vulnerable Systems Protected by a Firewall, a network-reachable vulnerability may be re-scored with Modified Attack Vector MAV:A only if “the analyst has high confidence that the vulnerable system is deployed on a secure network unavailable from the Internet”. A CDN-fronted origin is, architecturally, available from the internet — that is how the edge reaches it. Absent mTLS, a secret header, or a tunnel, the honest confidence level is low, and the measurements above say the reachability is usually real rather than theoretical.

And even when the precondition is met, the adjustment is small. FIRST’s own worked example — a stored SQL injection in MySQL, CVE-2013-0375 — moves from a CVSS-B of 5.1 to a CVSS-BE of 4.9:

A network control in front of a vulnerability does not turn a critical into a non-issue. Under the one condition where it counts at all, it is worth two tenths of a point.

The deeper point the guide makes is the one our whole model rests on: “CVSS Base (CVSS-B) scores are designed to measure the severity of a vulnerability and should not be used alone to assess risk.” Base score is intrinsic to the flaw and “independent of any factor associated with threat or the computing environment”. Environment and threat belong in the Environmental and Threat metric groups — which the consumerapplies, with evidence. So “we have a CDN” is not a CVSS input at all. It is a hypothesis about reachability, and a hypothesis is something you test.

What Nisura does instead: test reachability, never discount it

When Nisura’s passive scan sees a CDN in front of the apex, it correlates the data it already collected into exposed-origin candidates: subdomains that resolve off the CDN edge, self-hosted MX hosts (outsourced SaaS mail is excluded — that IP is the provider’s, not yours), and the domain’s own SPF ip4: ranges. Reverse DNS on the resolved asset IPs adds the box’s own hostname, which frequently names the hosting provider or the machine’s role. Where a keyed intelligence source is available, three pivots read existing indexes to confirm: non-CDN IPs serving the site’s favicon, non-CDN IPs presenting a certificate for the domain, and the apex’s pre-CDN historical A records.

Two discipline rules sit on top of that, both inherited from our passive-by-design scan model. We never send a packet to a candidate origin — everything above is public DNS plus indexes someone else already built — so an unconfirmed IP is labelled candidate, not origin, and only an index hit on the site’s own favicon or certificate upgrades it to confirmed. And the finding only ever moves risk in one direction: an exposed origin is a control failure that raises modelled exposure. There is no code path where the presence of a CDN lowers a probability.

That keeps the arithmetic honest. Our per-vector probability is EPSS × susceptibility × control-effectiveness, aggregated so that an attacker needs only one working path, and EPSS already measures exploitation in the wild — against real deployments, many of which sit behind CDNs. Multiplying it down again for a control whose own vendor tells you to assume the secret has leaked would be double-counting a defence we have not verified.

Why a CFO should care about a DNS record

Because a WAF bypass converts a line item into a gap. You are paying for DDoS absorption and request filtering at the edge; if an attacker can address the origin directly, you are paying for an edge they will not use. Zafran’s demonstration was a 20-second outage; their cost framing — an average DDoS lasting around 68 minutes, and far more expensive for financial institutions — is American and advertising-adjacent, so we treat it as an anchor rather than an input. Nisura prices the same hour in euros: Eurostat labour cost for the country, revenue × the disrupted share × the sector’s gross margin from Damodaran Europe data, plus forensics and the governing regulatory exposure.

There is a compliance edge too, and it is sharper than the config nit suggests. NIS2 Article 21(2) requires appropriate, state-of-the-art technical measures — and the state of the art here is documented by the vendor whose product you bought. GDPR Article 32 asks the same question of measures protecting personal data. For financial entities, DORA applies regardless of size, which is pointed given that financial services were the most affected sector in the 2024 scan. “We had a WAF” is a weaker answer to a supervisor than “we had a WAF, and we verified the origin only accepts traffic through it.”

How to stop your origin IP from leaking: nine checks

None of this requires a product. In rough order of measured payoff:

1. Enumerate your own subdomains and find the ones resolving off the CDN edge — ftp., mail., webmail., cpanel., direct., origin., staging.
2. Rotate the origin IP if you never did after onboarding. Historical DNS is permanent and public.
3. Read your own SPF and TXT records back. Any ip4: that is also your web host is a published origin.
4. Move self-hosted mail off the web origin, or accept that MX and bounces publish the hosting range.
5. Check for a forgotten AAAA record — IPv6 origins were excluded from the 2024 scan precisely because they are common and under-protected.
6. Prefer a tunnel or mTLS with your own CA over the shared provider certificate, and add Host-header validation.
7. Treat a CDN IP allowlist as defence-in-depth only — it authenticates the provider, not your tenant.
8. Don’t stop at :443. Origins on non-standard ports are the single largest blind spot the researchers admit to.
9. Search Certificate Transparency logs for your own certificates and read the SANs. Attackers start there; so should you.

The takeaway

“Behind a CDN” describes a routing arrangement, not a security boundary. The boundary exists only if the origin refuses everything that didn’t come through the edge — and two independent measurements, nine years apart, agree that most origins don’t refuse, and that the address meant to be secret usually isn’t. Until that is verified for a specific host, the correct treatment of CDN-fronting in a loss model is no credit at all.

You can check your own side of it in a few minutes: run the free external exposure scan to see which of your hosts resolve past the CDN, or go straight to the CRQ simulation for what that exposure costs in euros.