简介：面向WebLogic运维与安全加固人员，这份资料围绕63个CVE编号梳理了WebLogic历史上的漏洞修复情况，覆盖反序列化、远程代码执行、信息泄露与拒绝服务等典型风险，适合需要排查补丁缺口、评估系统安全状态的中高级运维与安全从业者参考。压缩包共1个docx文档，约1.93MB，以清单加分类说明的形式组织，便于按年份与漏洞类型快速检索。内容按CVE分组展开，涉及2011至2017年间的高危漏洞，如CVE-2016-0638、CVE-2015-7501等反序列化问题，以及CVE-2017-3248、CVE-2017-5638等组件风险，并提及10.3.5核心系统已打L5TD补丁的实际场景，可帮助读者对照自身环境判断修复优先级。目前已有1355人学习下载，适合作为漏洞自查与补丁管理的案头参考。

1. 补丁打过了，扫描器还是报 CVE-2016-0638：WebLogic 漏洞统计最容易踩的坑

一台跑着 10.3.5 的核心系统，L5T 补丁包已经打上，运维在管理控制台里翻来覆去确认过版本号，可安全扫描报告一出来，CVE-2016-0638、CVE-2016-3416、CVE-2015-7501 这一串反序列化漏洞照样红着。这种「补丁打了、扫描还报」的场面，在 WebLogic 漏洞统计和安全修复里太常见了，折腾人的地方不在于漏洞本身多难修，而在于你根本不知道扫描器到底在测什么、补丁到底覆盖了哪几个 CVE。手里攥着一份 63 条的 CVE 清单，从 2011 年的 CVE-2011-1411 一直排到 2017 年的 CVE-2017-10352，逐条去查修复状态，没有对照表就是纯体力活。这篇笔记面向正在被 WebLogic 漏洞清单卡住的开发和运维，把「为什么报了没修掉」「怎么定位根因」「怎么按清单逐条核对」讲透，让你拿着这份统计资源就能把账对平。

2. 反序列化漏洞反复报：CVE-2015-7501 与 CVE-2016-0638 为什么修不干净

WebLogic 的 CVE 清单里，反序列化类漏洞占了相当大的比重，CVE-2015-7501、CVE-2016-0638、CVE-2016-3416、CVE-2017-3248、CVE-2017-3506 都属于这一类。它们的共同特征是：攻击者构造一段恶意序列化数据，通过 T3、IIOP 或者 HTTP 协议送进服务器，服务器在反序列化时触发 gadget 链，最终执行任意代码。很多人以为打个补丁就完事，结果扫描器换个检测方式又报出来，根因往往不在补丁本身，而在补丁的覆盖范围和运行态的实际加载情况对不上。

2.1 补丁覆盖的是类，不是「这个 CVE 已关闭」

Oracle 的补丁机制是按组件和类打补丁的，一个 CPU 补丁包可能同时修复多个 CVE，也可能只修了某个 CVE 的一部分攻击面。以 CVE-2015-7501 为例，它本质上是 Commons Collections 反序列化链的问题，修复方式是在 WebLogic 的过滤机制里加黑名单，而不是把 Commons Collections 整个删掉。所以你在版本号上看到 10.3.5 加 L5T，只能说明补丁包装了，不能说明运行中的每个受管服务器都加载了新的过滤类。

常见做法是先确认补丁在文件系统层面是否真的落地，再确认运行态是否加载。下面这段命令用来核对补丁目录和 jar 的时间戳，是我排查「补丁打了没生效」时的第一步：

# 进入 WebLogic 补丁根目录，10.3.5 的典型路径 cd /u01/app/oracle/middleware/utils/bsu/cache_dir # 列出已安装补丁清单，确认 L5T 及其包含的子补丁 ls -lt *.jar | head -20 # 检查补丁是否解压到 modules 目录，重点看过滤相关 jar 的修改时间 ls -l /u01/app/oracle/middleware/wlserver_10.3/server/lib/ | grep -i filter

第一段ls -lt按时间倒序列出补丁缓存，能看出最近一次打补丁是什么时候、装的是哪个包；第二段查server/lib下的过滤相关 jar，如果时间戳还是几年前的，说明补丁虽然进了 cache_dir，但没有真正应用到 wlserver 的类路径里。参数上要注意，middleware路径随安装方式不同会变，有的环境是/u01/app/oracle/product/，先用find / -name "bsu" -type d定位再操作，别照抄路径。

2.2 受管服务器没重启，补丁等于没打

这是血泪经验里最冤的一种。管理服务器重启了，受管服务器还在跑旧进程，类加载器里持有的还是旧版本的过滤类。扫描器打的是受管服务器端口，自然照样报漏洞。判断方法很直接：看进程启动时间和补丁安装时间的先后。

# 查看所有 WebLogic 进程的启动时间 ps -eo pid,lstart,cmd | grep -i weblogic | grep -v grep # 对比补丁 jar 的修改时间 stat -c '%y %n' /u01/app/oracle/middleware/wlserver_10.3/server/lib/*filter*.jar

ps的lstart输出完整启动时间，如果进程启动时间早于补丁 jar 的修改时间，说明这个进程没吃到补丁。解决方式是按受管服务器逐个重启，不要图省事只重启管理节点。重启顺序上，先停受管再停管理，启动时反过来，这是 WebLogic 的老规矩，顺序错了会出现节点无法纳管的情况。

2.3 T3 协议开着，补丁修了也白修

CVE-2016-0638 这类漏洞的入口是 T3 协议。补丁修的是反序列化过滤，但如果 T3 对外网开放，攻击面依然存在，扫描器会持续判定为高风险。很多内网系统觉得「反正内网」，但漏洞统计报告是按暴露面算分的。收敛方式是在控制台里限制 T3 的连接来源，或者通过连接筛选器只放行可信网段。

# 在 config.xml 中确认是否配置了连接筛选器 grep -i "connection-filter" /u01/app/oracle/middleware/user_projects/domains/base_domain/config/config.xml

如果这条 grep 没有任何输出，说明没配连接筛选器，T3 对所有能访问 7001 的来源开放。补全方式是在控制台的「环境 - 服务器 - 协议」里配置连接筛选器，或者在config.xml的 server 节点下加<connection-filter>weblogic.security.net.ConnectionFilterImpl</connection-filter>，再配config.xml同目录的net.properties规则文件。改完必须重启对应服务器，规则才生效。这一步做完，扫描器对反序列化类漏洞的评级通常会降下来，因为攻击路径被收窄了。

3. 版本对不上号：CVE-2014-4210 到 CVE-2013-2390 的清单核对方法

63 条 CVE 里，2013 到 2014 年那批（CVE-2013-1504、CVE-2013-2390、CVE-2014-2479、CVE-2014-2480、CVE-2014-4210、CVE-2014-4241、CVE-2014-4253 一直到 CVE-2014-4267）最容易在核对时翻车。原因是这批漏洞横跨多个 CPU 季度补丁，有的在 10.3.5 的早期补丁里修了，有的要等到后续的 L5T 甚至更高补丁级别。手里只有一份 CVE 编号清单，没有「哪个补丁修了哪条」的映射，核对就变成了猜。

3.1 用补丁 README 反查 CVE，而不是靠记忆

Oracle 每个补丁包解压后都带 README，里面列了修复的 bug 号和对应的 CVE。这是最权威的对照来源，比任何第三方统计都准。操作方式是把补丁包解开，grep CVE 编号。

# 解压补丁包到临时目录（不要动生产目录） mkdir -p /tmp/patch_check && cd /tmp/patch_check unzip -o /u01/app/oracle/middleware/utils/bsu/cache_dir/*L5T*.jar -d ./l5t # 在 README 里反查某个 CVE 是否被这个补丁覆盖 grep -r "CVE-2014-4210" ./l5t/README.txt grep -r "CVE-2013-2390" ./l5t/README.txt

unzip -o的-o是覆盖已存在文件，避免交互卡住；-d指定解压目录，一定要放/tmp这类临时位置，别解到 middleware 目录里污染生产环境。grep 命中说明这个补丁的 README 里明确列了该 CVE，没命中不代表一定没修，可能是 README 只列 bug 号不列 CVE，这时要拿 bug 号去反查。我一般会把 63 条 CVE 做成一张表，逐条标注「在哪个补丁 README 里命中」，命中的打勾，没命中的单独列出来重点跟进。

3.2 版本号相同不代表补丁级别相同

10.3.5 是一个大版本，后面跟着不同的补丁级别。两台都显示 10.3.5 的服务器，一台打了 L5T，一台只打到更早的补丁，漏洞状态完全不同。核对时不能只看版本号，要看补丁级别。

# 查看当前 WebLogic 的补丁级别 cd /u01/app/oracle/middleware/utils/bsu ./bsu.sh -view -status=applied -prod_dir=/u01/app/oracle/middleware/wlserver_10.3

-view是查看模式，-status=applied只看已应用的补丁，-prod_dir指向 wlserver 安装目录。输出里会列出每个已应用补丁的编号和描述。把这份输出和 CVE 清单对照，才能确定「这台机器到底修到哪一步」。如果输出里只有零星几个补丁，而清单里有 2017 年的 CVE，那基本可以判定这些 2017 年的漏洞（CVE-2017-3248、CVE-2017-3506、CVE-2017-10063 等）在这台机器上没修，需要评估升级或打更高补丁。

3.3 清单里混入了非 WebLogic 组件的 CVE

63 条里有几条需要特别留意归属。CVE-2017-5638 是 Struts2 的漏洞，CVE-2014-3566 是 SSLv3 的 POODLE 问题，CVE-2011-5035 涉及哈希碰撞。这些不是 WebLogic 自身代码的漏洞，而是 WebLogic 运行环境里依赖的组件或协议配置问题。核对时如果拿 WebLogic 补丁去对这几条，永远对不上，会误判成「补丁缺失」。

处理方式是分类核对：WebLogic 自身漏洞走补丁 README 反查；依赖组件漏洞（如 CVE-2017-5638）查应用侧引入的 jar 版本；协议配置类（如 CVE-2014-3566）查config.xml里的 SSL 协议配置，确认是否禁用了 SSLv3。分类之后，63 条清单才不会变成一锅粥。

4. 扫描器报的和你修的不是一回事：CVE-2017-3506 与 CVE-2016-5531 的误报排查

安全扫描器的工作原理是发探测包、看响应特征，它不读你的补丁 README。所以经常出现「补丁确实修了，扫描器还报」的误报，也出现「扫描器没报，实际还开着口子」的漏报。CVE-2017-3506（T3 反序列化）和 CVE-2016-5531（T3 相关）这类漏洞，扫描器往往只根据端口开放和协议响应就下结论，不区分补丁级别。

4.1 先确认扫描器测的是哪个端口、哪个协议

拿到扫描报告，第一件事不是去翻补丁，而是看报告里的目标地址和端口。WebLogic 的管理端口（常见 7001）和受管端口、以及是否开了 T3，决定了扫描器的判定逻辑。如果报告指向的是一个已经下线的旧节点，或者指向的是负载均衡后面的某个实例，修错对象就白忙。

# 确认本机监听的 WebLogic 相关端口 netstat -tlnp | grep -E "7001|7002|7003" # 确认 T3 是否在响应（用 nc 探测，不要用生产凭据） echo "" | nc -w 3 127.0.0.1 7001 | head -c 200

netstat的-tlnp分别表示 TCP、监听、数字端口、进程，能看出哪个进程占了哪个端口。nc -w 3是 3 秒超时探测，返回内容里如果出现HELLO之类的 T3 握手特征，说明 T3 在响应。这一步的目的是把「扫描器说的目标」和「实际在跑的服务」对齐，对齐之后再看补丁，才不会修错地方。

4.2 用官方公告的受影响版本区间做二次判定

每条 CVE 在官方公告里都有受影响版本区间。CVE-2017-3506 影响的是特定版本段，如果你的 10.3.5 已经打到包含该修复的补丁级别，就属于误报。判定方法是把bsu.sh -view的输出和公告的修复版本对照。这一步不需要联网查，把公告里的版本信息整理进你的 CVE 对照表即可。

我一般会在对照表里加三列：受影响版本、修复补丁号、本机是否命中。命中且已打补丁的标「已修」，命中但没打补丁的标「待修」，不在受影响区间的标「不适用」。63 条走完一遍，待修清单通常只剩个位数，后续跟进就有了明确目标，不用再对着整份清单焦虑。

4.3 误报要留证据，别只口头说「修了」

扫描器误报在合规检查里是要有交代的。做法是把补丁 README 命中记录、bsu.sh -view输出、端口收敛配置截图整理成一个证据包，按 CVE 编号归档。下次扫描再报同一条，直接拿证据包回应，不用重新排查一遍。这个习惯看起来笨，但能省下大量重复劳动，尤其是季度扫描这种周期性任务。

5. 避坑清单：WebLogic 漏洞统计里最容易翻车的五个点

5.1 只重启管理服务器，受管服务器还在跑旧类

现象：补丁装完，管理控制台显示正常，扫描器对受管节点照样报反序列化漏洞。原因：受管服务器是独立 JVM，类加载器不会因为管理节点重启而刷新。解决：按节点逐个重启，重启后用ps -eo pid,lstart核对进程启动时间晚于补丁时间。

5.2 把 CVE-2017-5638 当成 WebLogic 补丁问题

现象：清单里 CVE-2017-5638 一直标红，翻遍 WebLogic 补丁 README 找不到。原因：这是 Struts2 的漏洞，属于应用依赖组件，不在 WebLogic 补丁范围内。解决：转到应用侧查WEB-INF/lib下的 struts 相关 jar 版本，升级对应依赖，别在 WebLogic 补丁上死磕。

5.3 补丁包装了但没 apply

现象：cache_dir里有补丁 jar，bsu.sh -view却看不到。原因：补丁只是下载到缓存目录，没有执行 apply 动作。解决：用bsu.sh -install -patchlist=<补丁号> -prod_dir=<wlserver路径>正式应用，应用后再-view确认。

5.4 连接筛选器配了但规则文件没生效

现象：config.xml里加了 connection-filter，T3 还是能被外部探测到。原因：规则文件net.properties路径或格式不对，或者改完没重启。解决：确认规则文件与管理服务器同域目录，格式为「目标网段 本机网段 允许/拒绝」，改完重启对应服务器。

5.5 拿版本号当补丁级别用

现象：两台都是 10.3.5，一台安全一台报漏洞，核对时懵了。原因：10.3.5 是版本号，补丁级别是另一套编号（如 L5T）。解决：统一用bsu.sh -view -status=applied的输出做对照，版本号只用来判断大版本兼容性。

6. 快速定位：拿到一份 CVE 清单后我固定走的四步

第一步永远是分类，不是逐条查。把 63 条按性质分成三类：WebLogic 自身代码漏洞（反序列化、T3、IIOP 相关，占大多数）、依赖组件漏洞（CVE-2017-5638 这类）、协议配置类（CVE-2014-3566 这类）。分类之后，每一类走不同的核对路径，避免用错工具白费力气。

第二步是建立对照表，字段固定为：CVE 编号、受影响版本、修复补丁号、本机补丁级别、是否命中、证据位置。这张表是整件事的核心，后面所有判断都基于它。下面是我常用的表结构，可以直接照着建：

第三步是运行态验证，不信任任何静态信息。补丁装了要看进程启动时间，配置改了要看端口响应，T3 收敛了要用nc探测确认。静态信息（版本号、配置文件内容）只能作为线索，运行态才是结论。

第四步是把证据固化下来。每条「已修」的 CVE 都对应一个证据位置：README 命中行号、bsu.sh -view输出片段、端口探测结果。下次扫描再报，直接调证据，不重复排查。

这套流程走下来，一份 63 条的清单通常两三个小时能对完，待修项收敛到个位数。从那以后我每次拿到 WebLogic 漏洞统计清单，都强制先分类再建表，绝不逐条硬查——逐条查看着勤快，实际上是在用体力掩盖方法问题。希望这份整理能帮到你，把手里那份清单真正对平。

本文还有配套的精品资源，点击获取