几乎每个现代网站上，都有一个为机器而非人类准备的 URL：它位于 /.well-known/acme-challenge/ 这个路径下。
在证书颁发流程的短短几秒钟里，一个自动化机器人会访问这里，检查你是否真的控制着该域名。按理说，这只是一次平淡无奇的例行任务：没人关注、不会出错、也不该引发任何动静。
但在这个案例里，正是这条“安静的小路”，制造了巨大的声响。
本文将讲清楚一个关键问题：即使应用的其他部分已经被用户设置的 WAF 规则严格阻挡，为什么指向证书验证路径的请求仍然能穿过 Cloudflare，直接抵达源站？
关于 ACME 的 60 秒入门
ACME 是一种协议，用来让证书颁发机构（CA）验证你对域名的控制权。
在最常见的 HTTP-01 验证方式中，CA 会要求你的网站在下面这个路径提供一个一次性令牌：
/.well-known/acme-challenge/{token}
随后，CA 会像普通用户访问网页一样，通过 HTTPS 去请求这个令牌内容；如果返回字节完全匹配，证书就会被签发。
这个机制的设计目标非常“克制”：
- 只访问一个固定的路径
- 只读取一个临时的小文件
- 不触碰任何业务逻辑
ACME 通道本质上是给一个“拿着剪贴板的机器人”准备的，而不是让一群人趁守卫不注意溜进系统内部。
不合常理的发现
研究人员在审查一组应用的访问控制策略时，发现了一个不合理的现象。
这些应用部署在 Cloudflare 后方，并且 WAF 被配置为：
- 默认阻挡所有来源
- 只允许特定来源访问
在绝大多数路径上，WAF 都严格执行了这些规则。但当请求目标变成：
/.well-known/acme-challenge/{token}
奇怪的事情发生了：WAF 没有拦截，反而放行了请求，源站直接返回了应用自己的响应。
最明显的线索就是“谁在说话”变了：
- 正常请求：返回 Cloudflare 的拦截页面
- ACME 路径请求：返回 源站框架的响应页面（通常是 404）
即使不看响应头，仅从页面风格也能一眼分辨：一个是 Cloudflare 的页面，另一个明显是应用自身的页面。
可复现的演示环境
为了确认这不是某个租户的特殊错误配置，研究人员搭建了一个受控的演示环境：在 Cloudflare 后面部署了几个默认会阻断正常访问的站点：
在普通路径下访问这些站点，你会看到 Cloudflare 的阻挡页面。
但当你用任意真实令牌访问这些站点的 ACME 挑战路径时，你会得到源站生成的响应——最常见的是框架自己的 404 页面。
这种差异非常直观：
- 一个是 Cloudflare 的拦截页
- 一个是应用框架的错误页
更确信的证据：不需要真实 ACME 文件也能绕过
在演示主机上，研究者进一步验证：即使请求并不存在的挑战文件，也能触发该行为。
他们使用了小型、幂等的请求，并在令牌后附加无害后缀（例如在令牌后加上 /ae），用来证明：
绕过并不依赖于真实存在的 ACME 文件。
在每一种情况下，结果都一致：
- 收到的是源站响应
- 而不是预期中的 WAF 阻挡页面
以下是演示环境的代表性截图：
第一张图：正常请求最终显示 Cloudflare 阻挡页面
第二张图：用于阻挡 cf-* 主机名的自定义规则
接下来的三张图：请求指向 ACME 路径后，返回了源站框架生成的 404 页面
阻挡页面（正常请求）
自定义规则 – 阻挡包含 cf-* 的主机名
为了演示，研究者创建了一条规则：阻挡任何包含 cf- 的主机名。
在真实生产环境中，很多团队也会采取类似策略——阻挡公共互联网访问，仅允许公司 VPN 出口的流量进入。此规则模拟的就是这种“默认拒绝”的安全姿态。
源站 404 页面（Next.js）
源站 404 页面（Spring）
源站 404 页面（PHP）
如何获取一个稳定的挑战令牌（方便长期复现）
为了做可重复演示，研究者需要一个不会在测试过程中失效的挑战令牌。
Cloudflare 的 SSL/TLS 自定义主机名（Custom Hostnames） 功能允许你为第三方主机名管理证书（通常是 CNAME 到你的域名），并支持多种验证方式。
研究者添加了一个名为：
cf-well-known.fearsoff.org
的自定义主机名，并明确选择 HTTP 验证。下面截图展示了添加流程以及最终的“待验证”状态：
关键点在于：研究者故意不为 cf-well-known.fearsoff.org 创建 DNS 记录，让证书签发流程永久停留在“待定”状态。
在这种状态下，Cloudflare 会提供 CA 将要访问的 HTTP-01 URL，例如：
http://cf-well-known.fearsoff.org/.well-known/acme-challenge/yMnWOcR2yv0yW-...Jm5QksreNRDUmqKfKPTk
他们并没有完成验证，也没有在该路径部署任何挑战文件。
他们的目的很明确：
- 获得一个确定性、长期有效的 token 形式
- 用它作为测试锚点
- 避免和真实 CA 的验证窗口“赛跑”
这样一来，就能在全球任何 Cloudflare 节点上持续测试 /.well-known/acme-challenge/{token} 的行为。
为什么这个问题在现实中很危险？
WAF 本应是“前门”。
但如果有一条特殊路径绕过了这扇门，那么“内部”和“外部”的边界就被改变了。
从安全角度看，问题在于：
/.well-known/acme-challenge/...这条路径的信任边界，从 WAF 滑落到了源站。
一旦源站可以被公网访问——哪怕只开放了一个路由——那么很多原本“关在内网”的风险都会被激活：
- 普通漏洞获得了可达路径
- 普通页面变成了侦察入口
- 内部调试接口可能暴露到公网
下面是演示中出现的典型影响。
Spring / Tomcat：从 ACME 路径跳到敏感端点
在正常情况下，Spring Boot 的执行器（Actuator）端点通常位于 WAF 和内网访问控制之后。
但当 ACME 路径能直达源站时，边界就变了。
研究者利用某些 Servlet 栈中众所周知的路径遍历特性（..;/），从 ACME 路径跳转访问：
/actuator/env
并返回进程环境与配置信息。
这些信息常常包含敏感内容，比如：
- 数据库连接 URL
- API Token
- 云平台密钥
它会直接扩大任何错误配置或漏洞的“爆炸半径”。
Next.js：源站直连导致 SSR 信息暴露风险
服务端渲染框架（如 Next.js）往往会把部分服务器端衍生数据传递给客户端用于页面注水。
在 WAF 守住前门时，这通常没问题。
但当源站开始直接响应时，同样的页面可能会暴露一些原本不希望暴露给公网的细节，例如：
- 内部路由结构
- 构建信息
- 服务端逻辑痕迹
PHP 路由：一旦可达，LFI 就可能变成文件读取
很多 PHP 应用会通过 index.php 路由所有请求，并通过查询参数选择视图。
如果这种模式存在本地文件包含（LFI）漏洞，那么当源站变得公网可达时，风险会升级为文件读取。
研究者用读取 ../../../../etc/hosts 来证明影响。
在演示中，甚至连 404 错误流都通过 index.php 路由，这意味着：
一旦源站开始“直接说话”，就可能暴露出更多可利用的入口。
需要强调的是：这些演示只是后果，而不是根因。
根本问题在于：WAF 对一条特殊路径做出了不同的决策。
一旦这扇门被打开，源站内部任何脆弱部分都可能变得“一键可达”。
不仅仅是 404：账户级 WAF 规则也被跳过
研究者进一步证明：这不是“碰巧绕过导致 404”那么简单。
他们配置了一个账户级 WAF 规则，用于阻挡带有特定信标头的请求。
在根路径下，带有 X-middleware-subrequest: 头的请求会被正常拦截。
但如果把完全相同的请求发往 ACME 路径，则会被放行，并由应用程序正常处理。
换句话说：
本应阻止请求的账户级 WAF 规则，并没有在该路径上被评估。
这为什么重要？
因为现实世界中，很多应用会依赖请求头来做逻辑判断，或者把头部信息传递到下游代码。
一旦 WAF 不再过滤这些头部，整个漏洞类别都可能重新“获得通路”，例如：
- 遗留代码中基于头部的 SQL 拼接
- 利用
X-Forwarded-Host/X-Original-URL的 SSRF 与主机混淆 - 依赖头部区分缓存键导致的缓存投毒
- 使用
X-HTTP-Method-Override的方法覆写 - 通过自定义头触发调试开关或隐藏逻辑
随之而来的问题是：
有多少应用仍然过度信任头部？
又有多少团队依赖 WAF 来守住“信任与公网之间的边界”？
可能的原因与修复情况
在调查过程中，研究者的合理推测是：
位于 /.well-known/acme-challenge/ 下的请求，可能走了不同的内部处理流程——
这是一个为了证书验证而存在的“隐式例外”，并且发生在客户自定义阻挡规则之前。
这可以解释为什么：
- ACME 路径总能到达源站
- 其他路径却严格显示 Cloudflare 阻挡页面
2025 年 10 月 27 日，Cloudflare 部署了修复。
研究者随后重新测试，观察到了预期行为：
- WAF 会统一应用客户规则
- 包括
/.well-known/acme-challenge/*路径
那条原本“该乏味就乏味”的路径，终于再次恢复乏味。
AI 与新的攻击面
像这样的 WAF 旁路问题，在 AI 驱动攻击不断发展的背景下，会变得更加紧迫。
原因很简单：自动化攻击工具可以非常快速地枚举并利用类似 /.well-known/acme-challenge/ 这种“特殊路径”，在大规模范围内探测：
- 框架特定弱点
- 常见错误配置
- 内部接口暴露
举例来说：
如果一个 AI 模型被训练用于识别：
- Servlet 的遍历特性
- PHP 路由漏洞模式
那么它就能把“旁路路径”与“针对性 payload”串联起来，把一个原本狭窄的维护通道，扩展成广泛可用的攻击入口。
反过来，AI 也能帮助防御者：通过模拟攻击路径、自动验证边界变化来提前发现问题。研究者提到，他们与 Crypto[.]com 安全团队合作时，也利用了 AI 分析来验证该问题。
随着源站变得可直接寻址，攻击者与防御者的竞赛加剧——这使得可靠且一致的 WAF 控制比以往任何时候都更关键。
时间线
- 2025年10月9日 – 通过 HackerOne 提交报告
- 2025年10月13日 – 厂商验证开始
- 2025年10月14日 – 被 HackerOne 分类
- 2025年10月27日 – 最终修复部署完毕；重新测试确认问题已修复
