小茉莉知识学习站
上一篇讲清了 CVE-2026-91403 是什么。这一篇只讲怎么做，按「先摸清、再升级、升不了就收敛」的顺序来。
一、30 分钟建立版本台账
这一步做不完，后面全是瞎忙。Java 的版本藏在四个地方，逐个查：
- 业务进程：每台机器上的
java -version，注意多版本共存时看的是进程实际使用的那个二进制 - 容器镜像：
docker images里带jdk/jre/temurin/openjdk的基础镜像，以及构建阶段的多阶段镜像 - 中间件自带运行时：Tomcat、Elasticsearch、Kafka、Jenkins、Nexus、SonarQube 这些自带 JRE 的产品，系统里的 Java 版本和它没有关系
- 构建与调度机器：CI runner、定时任务机、批处理节点——它们同样跑 JSSE
# 进程视角：谁在用哪个 java
ps -eo pid,comm,args | grep -E '[j]ava' | head -20
# 文件视角：镜像与产品目录里的运行时
find / -maxdepth 5 -type f -name java 2>/dev/null | head -30
# 容器视角
docker images --format '{{.Repository}}:{{.Tag}}' | grep -Ei 'jdk|jre|temurin|openjdk|tomcat'对照表（Oracle 版本编号，其他发行版请查各自公告）：
| 产品线 | 受影响 | 修复版本（以官方警报为准） |
|---|---|---|
| Java SE 8 | 8u511、8u511-perf | 8u512 及以后 |
| Java SE 11 | 11.0.33 | 11.0.34 及以后 |
| Java SE 17 | 17.0.21 | 17.0.22 及以后 |
| Java SE 21 | 21.0.13 | 21.0.14 及以后 |
| Java SE 25 | 25.0.5 | 25.0.6 及以后 |
| Java SE 27 | 27.0.1 | 27.0.2 及以后 |
| GraalVM for JDK | 17.0.21、21.0.13 | 跟随对应 JDK 修复版本 |
提醒：这些编号来自公开报道的整理，OpenJDK 发行版（Temurin / Corretto / Zulu / Liberica）有自己的编号节奏，部署前一定去发行版的安全公告页确认，别拿 Oracle 的号直接对。
补丁号存在口径差异：Oracle 警报页给出的版本号与部分发行版公告并不完全一致，个别公告里 8u512 仍被列为受影响版本。本文表格仅用于快速对照，最终以 Oracle 安全警报页和你所用发行版的公告为准，照抄版本号去升级是本手册唯一不能接受的操作。
二、升级顺序：公网 TLS 优先
- 备份当前 JDK 与启动参数：记下
JAVA_HOME、-Xmx等参数，保留旧版本目录，方便回滚 - 按暴露面排序：自己终止 TLS 的公网服务 → 内网 TLS 服务 → TLS 客户端 → 构建机与客户端
- 灰度一台：先换一台非核心实例，跑通启动与核心接口
- 验证握手：不要只看
java -version，要真的建立一次 TLS 连接（见下一节） - 回归业务：HTTPS 出站调用、双向 TLS、数据库 SSL、回调验签、客户端证书
- 全量并观察：重点看证书相关异常、握手失败率、超时率
# 切换版本（以发行版实际路径为准）
export JAVA_HOME=/usr/lib/jvm/temurin-21-jdk
systemctl restart your-app
# 用 openssl 从外部验证握手与证书链
openssl s_client -connect 127.0.0.1:8443 -servername your.domain -tls1_3 -brief </dev/null
# 查看生效的 TLS 相关属性
java -XshowSettings:properties -version 2>&1 | grep -Ei 'java.version|jdk.tls'三、六项验证清单
java -version输出的是修复版本，且进程用的就是这个二进制java -XshowSettings:properties -version里java.home指向新目录- 外部
openssl s_client能完成握手，证书链完整、无警告 - 应用日志里没有新增
SSLHandshakeException/CertPathValidatorException - 数据库 SSL、第三方 HTTPS 调用、双向 TLS 全部通畅
- 客户端证书 / 自签证书场景未被新版本策略误伤（这类问题通常在此次升级后才暴露）
四、今天就要上线，又动不了 JDK
先说结论：官方没有提供缓解措施。下面三条都是降低暴露面，不是修复，别写进验收结论里。
| 做法 | 收益 | 代价 / 局限 |
|---|---|---|
| TLS 前移到 Nginx / 负载均衡，Java 只跑内网 HTTP | 直接消掉「JVM 终止 TLS」这条最危险路径 | 改动大，需要处理真实 IP、超时、WebSocket |
| 收紧入站/出站白名单，只放可信网段 | 把「网络可达」这个前提打掉 | 内网横向仍然存在 |
| 加强数据访问审计与出站流量监控 | 这类漏洞无可用性影响，只能靠数据侧发现 | 只能发现，不能阻止 |
如果只能做一件事：把公网入口的 TLS 交给反向代理，Java 退回内网 HTTP。这一步能砍掉绝大部分暴露面，而且不依赖 JDK 版本。
五、怎么判断有没有已经被利用
因为可用性无影响，传统的「服务是否存活、CPU 是否飙升」监控基本无效。要往数据侧看：
- 数据库审计日志里的异常查询、批量导出、非工作时间访问
- 出站连接中的陌生 IP、异常 SNI、非预期端口
- 证书校验相关告警突然增多，或
javax.net.debug=ssl调试日志里出现异常协商 - 同一账号/服务在多地的并发访问
怀疑被入侵时，保留现场（日志、内存镜像、镜像版本），再按常规应急流程走，别急着清日志重启。
六、谁 / 做什么 / 什么时候
| 角色 | 动作 | 时限 |
|---|---|---|
| 运维 | 建立 JDK 版本台账（含容器、中间件、CI） | 今天 |
| 后端 | 确认哪些服务自己终止 TLS、哪些走 TLS 出站 | 今天 |
| 运维 + 后端 | 公网 TLS 服务升级并验证握手 | 24–72 小时 |
| 运维 | 内网服务、TLS 客户端、构建机升级 | 本周 |
| 安全 | 数据访问审计与出站监控加固 | 本周 |
参考
- Oracle Security Alert for CVE-2026-91403（补丁版本与受影响范围以此为准）
- NVD 记录：nvd.nist.gov/vuln/detail/CVE-2026-91403
- OpenJDK Vulnerability Advisory 2026-10-21
- 各发行版安全公告：Eclipse Temurin、Amazon Corretto、Azul Zulu、BellSoft Liberica
文中命令仅用于自查与升级验证，执行前请先在测试环境确认；版本号与发行版差异请以官方公告为准。
