Log4j和Jackson漏洞修复不能仅靠替换JAR包，必须综合评估组件引入方式、运行环境及启用状态；Log4j需同步升级log4j-api与log4j-core至2.17.1+等安全基线版本，并确认实际日志实现是否启用；Jackson则要求jackson-core、databind、annotations三者版本严格对齐，通过Maven强制指定并排除旧版传递依赖，再验证类加载路径与运行时行为。
Log4j 和 Jackson 漏洞修复不能只靠“换一个 jar 包”了事，得看组件怎么被引入、运行在哪、是否被实际启用。升级本身不难，但错一步就可能服务起不来或漏洞照旧。
Log4j 漏洞修复关键点：看版本、看用途、看组合
- 受影响的是 Log4j 2.x（不是 Log4j 1.x），重点排查
log4j-core和log4j-api这两个 jar - 版本在 2.0-beta9 到 2.17.0 之间都存在风险（如 CVE-2021-44228、CVE-2021-45105 等），2.17.1+（JDK8+）、2.12.4（JDK7）、2.3.2（JDK6）才是安全基线
- 单独升级
log4j-api不行，必须log4j-core同步升级；否则启动报错或功能缺失 - Spring Boot 项目默认用 Logback，即使依赖里带了旧版 log4j-core，只要没主动切换日志实现（比如删了
spring-boot-starter-logback、加了spring-boot-starter-log4j2），实际不会触发漏洞 - 如果确认用了 Log4j2，优先升级到官方推荐版本（如 2.17.1 或更高），不要只打补丁或改 JVM 参数——那是临时缓解，不是修复
Jackson 漏洞修复关键点：系列对齐、加载优先级、避免覆盖失效
- Jackson 家族三个核心包必须版本一致：
jackson-core、jackson-databind、jackson-annotations（例如全用 2.15.0） - CVE-2025-52999 是
jackson-core的反序列化问题，但databind才是实际调用入口，漏升任何一个都可能留后门 - Logstash 这类打包应用不支持直接替换 lib 目录下的 jar（会校验签名或类加载冲突），必须走
logstash-overrides/目录机制：新建该目录 → 放入三件套新 jar → 重启生效 - 普通 Java 应用（Maven 项目）直接在
pom.xml中强制指定新版 Jackson 依赖，并用<exclusions>剔除传递依赖里的旧版，比手动拷 jar 更可靠
验证是否真正修复
- 查进程加载的 jar 路径和版本（
jps -l+jcmd <pid> VM.native_memory | grep jackson或查 classpath） - 检查启动日志，确认 Logstash 加载了
logstash-overrides下的 jar，或 Maven 项目编译后target/classes/META-INF/maven/...里版本号正确 - 对 Log4j，可跑最小测试用例：
logger.info("${jndi:ldap://x}");，如果没抛 JNDI lookup 异常或 DNS 请求，说明已生效 - 对 Jackson，构造深度嵌套 JSON 或含特殊 Unicode 的 payload，观察是否仍能触发反序列化异常或 OOM
升级不是终点，而是确认路径闭环的开始。
