What a frustrating article. There was an interesting bug here. It's trivial to explain. It's not a zero-day, this was fixed months before disclosure. Most of the article is basically: "Imagine you were running software with horrific security holes behind this WAF. We even made some examples. It had a flaw. If your entire security posture depended on this WAF, imagine how much damage could have been done. Imagine if AI were involved!"

On top of that, AI was clearly used to write it which made it longer than necessary and harder to read.

> The CA fetches that token over plain HTTPS

The HTTP-01 challenge can only be done on port 80.

https://letsencrypt.org/docs/challenge-types/

The article was clearly written by an LLM. It would make no sense to use https for a challenge like that, indeed.

I’m not sure what the nextjs vulnerability is supposed to showcase - they’re putting secrets on their 404 page and relying on cloudflare to not show it?

Basically, it shows that Cloudflare's WAF (which is supposed to intercept requests before they make it to the origin server), is trivially bypassable by using the `.well-known/acme_challenge` path.

That means that any client that relies on this WAF to authenticate users (like with the NextJS example, where some information that would not be considered sensitive "internally" is exposed externally) or cover over security holes in their application (like with the Spring example, where the path traversal vulnerability in Spring is normally caught by Cloudflare before Spring can see it) would have this assumption violated

It's possible you're rendering more than just a simple 404, such as an SPA response or other result as part of an application response that may leak more information...

I think it's not a severe issue in most cases, and maybe something worth noting or addressing if you are at least aware of it, you can just 404 without content, for example in the .well-known/ path. I run most of my apps behind Caddy, which handles that path itself and doesn't forward requests to that path, so I'm curious how it handles it tbh.

I'm also not sure that there's a clear/good fix for this, since CF is allowing the traffic through so that ACME negotiation can work against the final application host.

All their examples rely on having poorly configured origins. At least the PHP and Tomcat ones might be blocked by a WAF, but the Next.js one would rely on the WAF blocking responses that included secrets (which I’m not sure they do).

I think the idea for the NextJS example was that there might be some configuration variables that are not sensitive for internal / staff users, but would be problematic if exposed externally—basically, relying on Cloudflare's WAF as a "zero trust" endpoint solution, like Google IAP.

I'm not sure how realistic this is in practice. Does anyone actually configure Cloudflare WAF this way? (As opposed to, e.g., Cloudflare's dedicated zero-trust networking product, which I think works completely differently?)

The point is that WAF didn't block everything, and that if your app had some kind of default/error handler that non-blockage would have unexpectedly exposed something.

Not that big of a deal, but interesting.

> We wish to express our deep gratitude to Jason Lau, CISO and the Crypto[.]com Security Team, who we approached first to help independently verify this zero-day vulnerability.

Bizarre choice.

The one thing that I find bizarre about this: why did Cloudflare feel inspired to special-case /.well-known/acme-challenge at all? The only thing I can think of is that clients were having caching issues (Cloudflare caching the challenge value, clients forgetting to set cache-control headers, and challenges therefore failing), but that seems like a bit of a weak reason to special-case anything. Anyone using Cloudflare should already know how to set cache control headers.

My guess would be that aggressive blocking was causing verification to fail, since it gets verified from multiple well-separated locations.

If a user’s verification attempts fails because their own rules block access, that doesn’t sound like a Cloudflare bug. If a user’s verification attempt fails because of Cloudflare’s built in rules, maybe that’s an issue, and maybe Cloudflare tried to fix that and messed up.

All that being said, this workflow is rather odd. We’re talking about a customer who uses an HTTP-01 challenge to get a certificate for a domain that is proxied by Cloudflare’s TLS-terminating proxy. Setting this up in a way that is useful is dramatically harder than letting Cloudflare deal with the certificate. Maybe the idea is that the user could example proxying and get something vaguely secure without any reconfiguration at all all on the origin machine? How many users have ACME configured and are willing to run a wide-open origin behind Cloudflare anyway?

There’s a lot going on in this blog. Interestingly, the core mechanism at play here is the http-01 challenge validations which they state is fetched by the CA over HTTPS. This is particularly amusing when you consider that http-01 is explicitly NOT HTTPS (it’s HTTP), and this is actually the entire reason there’s a different code path to take.

The modern web requires secure (HTTPS) context for many things to work, so it’s commonplace to do so “HTTPS enforcement”; all requests are forcibly upgraded to HTTPS. However, you can’t do that to the CA when it’s performing a http-01 challenge validation. This necessitates a “well known” URL route be used for challenges so that they can very deliberately take a different code path that doesn’t enforce HTTPS (and be routed differently).

This is true of basically every ACME client used for http-01 challenges, not just cloudflare. So while they’ve unfortunately missed the mark on correctly explaining the mechanism at play here, I hope that I succeeded in making it a bit more clear. Other implementations are, of course, similarly exploitable.