影响面为什么这么大
该漏洞的特殊之处在于利用门槛极低：只要应用把用户可控的字符串写进日志，就可能触发远程加载，攻击者无需认证即可在服务器上执行代码。而 Java 生态里使用这个日志组件的项目极其广泛，且它常作为传递依赖被间接引入——项目自己的依赖清单里看不到，实际却被打进应用。排查的关键因此不是看应用版本，而是找实际的组件文件。
基本信息
| 加固项 | Java 组件漏洞处置 |
|---|---|
| 适用平台 | Linux 与 Windows（Java 应用） |
| 风险等级 | 高 |
| 基线 | 不存在受影响版本的组件文件 |
| 排查对象 | 独立组件文件与打包进应用的内嵌依赖 |
典型使用场景
- 漏洞响应：收到通告后在全量主机上排查受影响组件
- 存量资产梳理：确认哪些业务仍在受影响版本上
- 整改验收：升级后确认旧版本文件已不存在
- 入侵排查：确认是否出现过外部加载或异常进程
- 供应链评估：判断构建产物中是否间接引入了该组件
全盘排查
全盘排查
find / -name 'log4j-core-*.jar' 2>/dev/null | head -30
find / -name '*.jar' -path '*log4j*' 2>/dev/null | xargs -I{} sh -c 'echo {}; unzip -p {} META-INF/MANIFEST.MF 2>/dev/null | grep -i version' 2>/dev/null | head -40
find / -name '*.war' -o -name '*.ear' 2>/dev/null | head -20 # 打包应用内的内嵌依赖需解包确认
ps -ef | grep -i java | head -10 # 结合运行进程定位应用Windows 侧
Windows 侧
Get-ChildItem -Path C:\ -Recurse -Filter 'log4j-core-*.jar' -ErrorAction SilentlyContinue | Select-Object FullName, Length | Select-Object -First 20
Get-ChildItem -Path C:\ -Recurse -Filter '*.jar' -ErrorAction SilentlyContinue | Where-Object Name -like '*log4j*' | Select-Object -First 20 FullName排查结果与处置
| 情形 | 含义 | 处置 |
|---|---|---|
| 独立组件文件受影响版本 | 直接暴露 | 升级或替换，重启应用后验证 |
| 内嵌在应用包中的版本 | 外层包看不出来，最易遗漏 | 解包确认，替换后重新打包 |
| 仅存在不受影响版本 | 暂不处置 | 记录结论并纳入后续巡检 |
| 应用仍在运行旧版本 | 可能存在已利用窗口 | 升级后追加一次入侵排查 |
处置顺序建议是先做边界缓解再升级：网络层的拦截与出网限制可以快速降低利用可能，随后再完成组件升级。升级后要验证业务日志功能正常，并确认新版本文件确实生效，而不是只看升级动作完成。
嵌套依赖最容易被漏掉：打包进应用归档文件或构建产物内部的组件不会出现在文件系统的单独路径里，需要解包排查。同时要确认运行时实际加载的是哪个版本的组件——只更新外层应用版本，不一定更新了内部依赖。
排查结果的留档
建议输出一张表：主机、应用路径、组件版本、是否受影响、处置动作、验证结论。受影响的条目要有升级记录与验证结果，不受影响的也要留档，便于通告复评时直接引用。这张表在同类漏洞响应中可以复用，把排查成本从「每次重新找」变成「按表更新」。