Apache Tomcat 漏洞允许攻击者通过 HTTP/0.9 请求绕过安全限制
Apache Tomcat 已披露 CVE-2026-24733，这是一个低危安全约束绕过漏洞，当某些访问控制规则以特定方式配置时，可通过 HTTP/0.9 请求触发该漏洞。
Apache Tomcat 已披露 CVE-2026-24733，这是一个低危安全约束绕过漏洞，当某些访问控制规则以特定方式配置时，可通过 HTTP/0.9 请求触发该漏洞。
Apache Tomcat 安全团队发现了该问题，最初的安全公告于 2026 年 2 月 17 日发布。
从根本上讲，该漏洞源于 Tomcat 没有将 HTTP/0.9 请求限制为 GET 方法。HTTP/0.9 是一种过时的、功能最简化的协议变体，它早于现代的方法和头部处理规范，如今很少被有意使用。
但是，如果攻击者能够访问 Tomcat 实例并发送精心构造的 HTTP/0.9 风格的流量，Tomcat 的方法处理可能会在安全约束的执行方面造成意想不到的漏洞。
当 Tomcat 安全约束配置为允许对特定 URI 发送 HEAD 请求，同时拒绝对同一 URI 发送 GET 请求时，就会发生绕过 。在正常的 HTTP 版本中，该规则集会阻止通过 GET 请求获取资源主体。
利用 CVE-2026-24733，攻击者可以使用 HTTP/0.9 发送不符合规范的 HEAD 请求，从而绕过 GET 请求的配置约束。
这个问题是设计上的特殊情况：它需要特定的约束配置（允许 HEAD，拒绝 GET）以及一个可以端到端接受 HTTP/0.9 解析的攻击路径。
即便如此，它仍然与传统集成、特殊客户端以及某些代理/拓扑组合相关，在这些情况下，协议规范化可能不会按预期发生。
受影响版本及缓解措施
受影响的范围涵盖了当前维护的 Tomcat 分支以及已停止维护的旧版本。运行已停止维护版本的组织应将此视为迁移到受支持分支的提醒，因为安全修复可能无法安全地移植到旧版本。
Apache 建议升级到上述已修复的版本。作为一项切实可行的安全加固措施，团队还应审查受保护端点上 HEAD 和 GET 请求的访问控制意图，并验证任何前端反向代理或负载均衡器是否允许意外的协议降级行为。
关于作者
评论1次
### 结论 CVE-2026-24733的漏洞核心是Tomcat未限制HTTP/0.9请求的方法类型，导致攻击者可通过发送HTTP/0.9风格的HEAD请求绕过配置中对GET请求的限制。受影响场景需满足两个条件：1) 安全策略配置为允许HEAD但拒绝GET的同一资源；2) 攻击路径允许发送HTTP/0.9请求。修复需优先升级或调整安全约束配置，同时阻断旧协议降级路径。 --- ### 分析路径（T00ls方法论） #### **L1 攻击面识别** - **关键点**：HTTP/0.9协议特性（仅支持GET，无方法校验）与Tomcat安全约束逻辑的冲突。 - **目标配置**：定位所有配置了`<http-method>HEAD</http-method>`允许、同时`<http-method>GET</http-method>`拒绝的`<security-constraint>`。 - **攻击面边界**：部署反向代理或负载均衡器的环境需额外排查，因其可能隐式转换协议版本或放行HTTP/0.9请求。 #### **L2 假设与验证** - **假设1**：当配置允许HEAD但拒绝GET时，Tomcat对HTTP/0.9的`HEAD`请求未强制降级为`GET`或报错，导致约束失效。 - **验证路径**： 1. 复现配置：创建Tomcat资源`/test`，安全约束允许HEAD但拒绝GET（`<http-method-omission>`或显式拒绝GET）。 2. 发送HTTP/0.9请求：通过`curl -v --http0.9 "http://target/test"`或直接Socket发送`HEAD /test HTTP/0.9`。 3. 验证绕过：若响应返回资源内容而非403，则漏洞存在。 #### **L3 边界/异常场景** - **异常场景1**：反向代理（如NGINX/Apache）未规范协议版本，允许HTTP/0.9流量通过。 - **异常场景2**：客户端或中间设备主动降级协议（如旧版浏览器或中间人工具伪造HTTP/0.9请求）。 - **验证步骤**： - 检查反向代理配置是否强制协议为HTTP/1.1及以上（如NGINX配置`proxy_http_version 1.1;`）。 - 模拟中间人协议降级：通过拦截工具（如Burp）强制发送HTTP/0.9请求，观察约束是否失效。 #### **L4 防御反推与修复** - **防御逻辑**：漏洞源于未校验HTTP/0.9的非法方法，修复需从协议限制和策略一致性两方面切入。 - **修复优先级**： 1. **升级到受支持版本**：强制要求（即使业务使用旧版本，也需评估迁移路径）。 2. **策略一致性调整**： - 删除所有单独允许`HEAD`而拒绝`GET`的约束（`HEAD`的资源访问应与`GET`保持一致）。 - 或显式拒绝所有HTTP/0.9请求（通过连接器配置`protocol="HTTP/1.1"`并过滤协议版本）。 3. **协议规范化**：前端代理需强制协议为HTTP/1.1，阻断HTTP/0.9流量（如NGINX配置`proxy_set_header Connection close;`配合版本检查）。 --- ### 验证步骤（最小可执行路径） 1. **检查配置**： ```bash grep -r "security-constraint" $CATALINA_HOME/conf/web.xml | grep -E "(HEAD|GET)" ``` 定位允许HEAD但拒绝GET的约束。 2. **发送HTTP/0.9 HEAD请求**： ```bash # 使用curl（需指定--http0.9） curl -v --http0.9 "http://<target>/test" -X HEAD # 或通过telnet直接构造请求： telnet <target> 80 HEAD /test HTTP/0.9 Host: <target> ``` 3. **验证响应**： - 若返回资源内容（如文件内容或200状态码）而非403，表明漏洞存在。 - 捕获流量确认请求被识别为`HEAD`而非自动降级为`GET`。 --- ### 修复建议 1. **版本升级**： ```bash # 示例：升级到修复版本（以Tomcat 10.1.30为例） wget https://downloads.apache.org/tomcat/tomcat-10/v10.1.30/bin/apache-tomcat-10.1.30.tar.gz ``` 更新后重启服务，确保版本号无回退。 2. **安全策略修正**： 修改`web.xml`中受限资源的约束配置，确保`HEAD`和`GET`策略一致： ```xml <security-constraint> <web-resource-collection> <url-pattern>/test</url-pattern> <http-method>GET</http-method> <http-method>HEAD</http-method> </web-resource-collection> <auth-constraint> <!-- 权限配置 --> </auth-constraint> </security-constraint> ``` 3. **协议过滤**： 在反向代理层（如Nginx）强制协议版本并拦截HTTP/0.9： ```nginx server { location / { proxy_pass http://tomcat_backend; proxy_http_version 1.1; proxy_set_header Connection ""; # 拦截HTTP/0.9（需通过Lua或自定义模块实现，此处示意） } } ``` --- **风险提示**：旧版本Tomcat（如9.x及更早）若未维护，建议直接退役并部署新版本，避免尝试手动打补丁导致兼容性问题。