Cassandra 4.0 log4j相关漏洞处置方案咨询

首先明确已核实的组件风险基线：

• Cassandra 4.0内置的log4j-over-slf4j-1.7.25组件已确认不受CVE-2021-44228（Log4Shell）漏洞影响，无需针对该漏洞做专项修复。
• 唯一关联风险为其依赖的slf4j 1.7.25版本对应的CVE-2018-8088漏洞。

先明确该漏洞的实际触发条件：CVE-2018-8088是slf4j-ext扩展包中EventData类存在的反序列化漏洞，仅当应用主动加载该类、且接收不可信来源的序列化数据传入解析时才可能被利用。Cassandra 4.0默认运行逻辑不会调用该类，默认安装包甚至不会携带slf4j-ext组件，绝大多数部署场景下该漏洞无实际可利用路径，风险等级为低。

具体处置方案 #

无合规强要求、业务不能中断的生产场景 #

• 先执行校验：进入Cassandra安装目录的lib文件夹，检查是否存在slf4j-ext-1.7.25.jar包。默认官方发行版中不存在该包，这种情况直接忽略该漏洞告警即可，不会产生实际安全风险。
• 如果检查发现lib目录下存在slf4j-ext包，直接删除该jar包即可，Cassandra核心运行、日志输出逻辑完全不依赖该组件，删除后无需专门重启即可阻断漏洞触发路径，可等下次节点例行维护重启时完成清理。

有合规扫描要求、可安排维护窗口的场景 #

通过滚动升级slf4j组件到安全版本彻底修复，注意不要跨大版本升级，避免兼容性问题：

• 选择1.7.x分支的最新稳定版（最低要求1.7.35及以上，该版本已正式修复CVE-2018-8088），不要升级到2.0及以上版本，否则会和Cassandra 4.0的日志桥接逻辑冲突导致节点启动失败。
• 逐节点停机替换lib目录下的相关jar包：
  • 将原log4j-over-slf4j-1.7.25.jar替换为对应高版本的同组件包
  • 将原slf4j-api-1.7.25.jar替换为对应高版本的同组件包
  • 如果部署时自定义替换过日志实现（如使用logback、slf4j-log4j12绑定），同步将相关slf4j绑定包替换为和slf4j-api版本匹配的版本
• 替换完成后启动节点，验证日志输出正常、集群读写、gossip通信等核心功能无异常后，再操作下一个节点，直到全集群升级完成。

避坑提示 #

• 不要照搬CVE-2021-44228的修复方案，往JVM参数里加-Dlog4j2.formatMsgNoLookups=true这类参数，对CVE-2018-8088完全无效，反而可能引发未知的启动异常。
• 不要直接单独升级log4j-api、log4j-core到2.x高版本，Cassandra 4.0没有适配Log4j2的日志配置，强行替换会导致日志系统完全失效。

内容的提问来源于stack exchange，提问作者Nitin P