【高危漏洞预警】Apache Tomcat FORM认证授权绕过高危漏洞CVE-2026-6852

飓风网络安全

2026年10月28日 23:29
广东

去阅读

风险简述：Apache Tomcat FORM表单认证机制存在授权逻辑缺陷，攻击者可通过切换HTTP请求方法绕过基于请求方法的访问控制策略；仅POST请求受保护的后台接口、管理端点，攻击者改用GET请求即可直接越权访问，获取敏感业务数据、操作后台功能；该漏洞为无前置权限远程利用，公网暴露Tomcat服务风险突出，适配Java业务、AI平台后台、企业管理系统资产自查。

一、漏洞原理

该缺陷根源于Tomcat FORM Authenticator 表单认证模块对HTTP方法粒度安全约束校验逻辑处理错误：

1. 开发者在web.xml安全约束配置中，对资源路径设置策略：仅对POST请求启用身份认证保护，GET方法无访问限制，是Java Web项目常见的接口隔离配置；

2. Tomcat原有校验逻辑错误地将「资源路径」和「HTTP请求方法」解耦校验：当安全约束仅绑定POST方法时，FORM认证拦截器仅校验POST请求的登录态；

3. 攻击者将原POST访问的受保护后台接口，直接替换为GET方法发起请求，Tomcat不再触发FORM登录校验，直接放行访问该资源，形成授权绕过

边界说明：漏洞不是绕过登录Cookie/Session身份凭证，而是绕过【基于HTTP Method的访问控制策略】；如果该接口配置为所有方法都强制认证，则不受该漏洞影响。

典型受害场景：后台提交接口、配置保存接口、用户查询接口，业务代码只限制POST提交，运维在安全约束里仅对POST开启鉴权。

二、影响范围

✅ 受影响官方维护版本

• Tomcat 11.0.0-M1 ~ 11.0.24

• Tomcat 10.1.0-M1 ~ 10.1.57

• Tomcat 9.0.0.M1 ~ 9.0.120

✅ 已经停止维护（EOL）但同样存在漏洞（无官方补丁，强烈建议下线）

• Tomcat 8.5.0 ~ 8.5.100

• Tomcat 7.0.0 ~ 7.0.109

✅ 修复基线版本

• Tomcat 11.0.25

• Tomcat 10.1.58

• Tomcat 9.0.121

提示：大量中间件、自研平台、AI业务后台、国产化应用内置打包Tomcat，这类嵌入式Tomcat同样受漏洞波及，不能只看服务器单独部署的Tomcat资产。

三、攻击面与利用条件

1. 攻击向量：远程（AV:N），无需内网，公网可直接发起

2. 权限要求：无（PR:N），攻击者不需要账号、Cookie、登录凭证

3. 利用复杂度：低（AC:L），仅修改请求Method，Burp、curl一行请求即可验证，POC门槛极低

4. 利用效果：

越权读取后台敏感接口数据：用户列表、配置参数、密钥信息、AI平台提示词模板

调用后台操作接口：修改业务配置、提交任务、读取模型日志（取决于接口本身能力）

仅影响配置了Method粒度FORM安全约束的web应用；默认无method区分的常规部署不受影响

5. 野外现状：目前公开POC已在安全社区扩散，红队、扫描器厂商已集成检测规则；勒索团伙、资产测绘平台已经开始批量探测公网Tomcat站点。

简易验证示例（仅用于企业自查）

原受保护请求（POST，需要登录）

POST /admin/config HTTP/1.1

Host: xxxx

Content-Type:application/x-www-form-urlencoded

绕过测试请求（GET，漏洞下直接放行）

GET /admin/config HTTP/1.1

Host: xxxx

四、资产检测排查方案

1. 版本快速核查

查看独立部署tomcat版本

cd tomcat/bin

./version.sh

嵌入式tomcat：查找jar包，解析tomcat-catalina.jar版本

find / -name \"tomcat-catalina\*.jar\"

2. 业务配置核查（核心！版本没问题也需要核对策略）

检查WEB-INF/web.xml里的security-constraint配置，查找这类写法：

/admin/\*

POST

admin

这类只写POST、没有限制GET的配置，是漏洞的触发前提。

3. 流量&日志监控策略

4. 对后台管理路径（/admin、/manage、/config、/api/admin）建立告警：同一资源同时出现GET和POST访问，且POST需要登录、GET直接返回200

5. 审计access.log，监控陌生IP对后台路径GET请求，状态码200，作为可疑绕过行为

6. WAF/网关规则：对后台管理接口做Method白名单控制，不允许随意切换请求方法

五、修复与缓解方案（优先级排序）

✅ 方案1：首选，升级Tomcat至官方修复版本（9.0.121 /10.1.58 /11.0.25）

升级后Tomcat会统一安全约束校验逻辑，Method粒度鉴权逻辑修复，从底层封堵绕过链路；升级前做好业务兼容性测试，重启服务生效。

✅ 方案2：临时应急修复（短期内无法升级）

1. 修改web.xml安全约束：删除限制，改为http-method-omission，对所有HTTP方法统一强制鉴权；或者显式列出GET/POST/PUT/DELETE全部方法加入保护范围，不要只保护POST

/admin/\*

admin

2. 应用层兜底：在Filter、Spring拦截器统一校验鉴权，不要把身份认证完全交给Tomcat原生FORM认证；业务层接口强制校验session登录态，不依赖容器安全约束

3. WAF/反向代理层：后台接口做HTTP Method管控，后台提交接口禁止GET访问，在网关直接拦截GET请求访问POST后台端点

❌ 无效缓解：单纯改复杂登录密码、增加验证码，无法阻止该Method切换绕过。

六、企业侧安全建议（适配AI智能体业务场景）

1. 资产梳理：重点排查AI平台后台、模型管理控制台、向量库管理页面、内部业务后台、客户管理系统，这类系统大量使用Tomcat+FORM表单登录，且习惯POST提交配置；

2. 开发规范落地：禁止仅针对单一HTTP方法配置容器层鉴权，鉴权逻辑下沉到业务代码，统一权限中间件；

3. 上线安全扫描：在CI/CD、上线前安全测试中增加【HTTP方法切换绕过】用例，作为Java后台必测项；

4. 边界防护：公网管理后台优先接入零信任、VPN，不直接暴露公网；

5. 红队演练：把该漏洞加入内部渗透测试清单，重点核查所有FORM认证的Java管理系统。