彻底修复 Log4j2 漏洞的唯一可靠方案是将组件升级到安全版本，临时缓解措施仅适用于无法立即升级的场景。
先说结论：升级至 Apache 官方推荐的安全版本是根本解决方式，排查重点在于定位依赖该组件的应用。
- 先判断：确认服务器上是否存在受影响的 log4j-core 包
- 优先做：将版本升级至 2.17.1 或更高（Java 8+）
- 再验证：检查 Jar 包版本信息并观察应用日志
快速排查命令
以下命令帮助你在 Linux 文件系统中快速定位可能受影响的 Jar 包，生产环境建议指定目录搜索以避免 IO 飙升：
find /opt /home /usr -name "log4j-core*.jar" 2>/dev/null查看具体版本号（修正版）：
unzip -p /path/to/log4j-core.jar META-INF/MANIFEST.MF | grep Implementation-Version漏洞原理简述
该漏洞源于 Log4j2 组件在处理日志消息时，默认启用了 JNDI 查找功能。攻击者可以通过构造特定的日志内容，诱导服务器发起外部请求并执行远程代码。
分步修复流程
1. 定位文件
使用上述 find 命令搜索。注意检查 Web 应用目录（如 tomcat/webapps）、中间件 lib 目录以及用户家目录。
2. 备份原文件（重要）
在替换或修改 Jar 包前，务必备份原文件，以便出现问题时回滚：
cp /path/to/log4j-core.jar /path/to/log4j-core.jar.bak_$(date +%F)3. 执行升级
通过构建工具（Maven/Gradle）更新依赖，或手动替换 Jar 包。对于 Java 8 及以上环境，建议升级至 2.17.1 或更高版本；Java 7 环境建议升级至 2.12.4。
4. 重启服务
替换完成后需重启应用生效，根据实际服务管理方式执行：
systemctl restart tomcat5. 临时缓解（仅当无法升级时）
在启动参数中添加 -Dlog4j2.formatMsgNoLookups=true。若必须删除 Jar 包中的 JndiLookup.class 文件，请先备份 Jar 包，操作不当可能导致包损坏。
验证修复结果
再次运行版本检查命令，确认 Implementation-Version 已变更为安全版本。重启应用后，观察启动日志是否有报错。如有条件，可使用漏洞扫描工具对服务端口进行探测。
常见风险与坑
- 传递依赖：很多框架间接依赖 Log4j2，只修改主项目 pom 文件可能无效，需排查依赖树。
- 多版本共存：服务器上可能运行多个应用，各自携带独立的 Jar 包，需全部排查。
- 全盘搜索风险：生产环境避免直接使用
find /，建议指定业务目录搜索，防止 IO 飙升影响业务。 - 缓解措施局限：系统属性缓解方案在某些高版本 JDK 或特定 Log4j 版本下可能无效，不要依赖临时方案长期运行。
参考来源
- Apache Logging Services - Security Advisories: https://logging.apache.org/log4j/2.x/security.html
- NVD - CVE-2021-44228 Detail: https://nvd.nist.gov/vuln/detail/CVE-2021-44228