七月上旬Apache官方安全团队悄然放出一则补丁公告将编号CVE-2026-49844的漏洞正式纳入已知风险清单。这个藏在log4j-api组件里的小毛病表面看只是JSON序列化时的一个编码疏忽实则可能在关键时刻让你的日志管道彻底瘫痪甚至让安全团队的告警系统变成聋子。一个数字就能搞垮整条日志链事情的起因说起来并不复杂。Apache Log4j在处理MapMessage对象时如果其中包含了NaN、Infinity或者-Infinity这类非有限浮点数值JsonTemplateLayout或者其他调用MapMessage.asJson()方法的布局组件会直接把这些Java原生字符串原封不动地写进JSON输出。可问题在于RFC 8259标准压根就不允许JSON里出现这些裸token。下游的日志采集器、Elasticsearch、Splunk或者各类SIEM平台一旦碰到这种畸形数据大概率会直接把整条记录拒之门外。攻击者不需要什么高深技巧只要找到一个能向日志系统注入浮点数的入口塞一个精心构造的非有限值进去就能让后续的日志流出现断层。这种打法不像传统RCE那样能直接控制服务器但它对可用性和数据完整性的破坏往往更隐蔽、更难排查。为什么日志完整性比代码执行更值得关注很多人看到CVSS 4.0评分6.3归类为中等风险第一反应可能是问题不大。但这种判断在日志安全领域其实有点危险。日志是什么它是你事后溯源的黑匣子是合规审计的底稿也是SOC团队发现异常的生命线。如果攻击者能预测到你的日志解析行为并且知道往哪个字段里扔一个NaN就能让整条记录消失那这本质上就是一种针对可见性的攻击。想象一下某个深夜入侵者已经在你的系统里踩好了点正准备横向移动。正常情况下异常登录、权限提升、敏感文件访问这些行为都会留下痕迹触发告警。可如果关键时间窗口的日志因为格式错误被解析器丢弃你的安全运营中心可能根本收不到那条本该让你从床上弹起来的警报。这种静默丢失比一次性的服务崩溃可怕得多因为你甚至不知道自己错过了什么。漏洞触发的两个必要前提这个漏洞并非无条件触发它的利用路径有一定的门槛。应用必须同时满足两个条件一是使用了JsonTemplateLayout的message resolver或者其他任何依赖MapMessage.asJson()进行序列化的布局二是日志消息本身包含攻击者可控的浮点数值且最终以MapMessage的形式被记录。换句话说如果你的系统只是简单地用Log4j记字符串没有涉及结构化日志里的浮点字段那暂时可以松口气。但现代微服务架构里MapMessage被广泛用于记录结构化上下文——用户ID、请求耗时、坐标位置、传感器读数这些场景里浮点数太常见了。一旦某个API接口把用户输入的数值直接写进日志风险就敞开了。有意思的是这次修复其实还补上了前一轮补丁的漏网之鱼。今年四月披露的CVE-2026-34481已经处理过JsonTemplateLayout里的类似问题但当时的修复只覆盖了一部分代码路径。MapMessage.asJson()这个口子没堵上才有了现在的CVE-2026-49844。Apache官方也坦诚2.25.4版本的补丁并不彻底这才催生了2.25.5和2.26.1的后续更新。当前威胁态势尚未被大规模利用但别掉以轻心从公开情报来看CVE-2026-49844目前还没有现成的概念验证代码流出研究人员也未确认有真实攻击案例在野出现。EPSS评分低于1%CISA KEV列表里也没有它的名字。这些指标说明短期内被脚本小子批量利用的可能性不高。但安全评估不能只看当下。这个漏洞的利用条件并不苛刻攻击向量清晰而且防御方往往在日志解析层缺乏对单条记录格式异常的实时监控。很多企业的日志 pipeline 是fire and forget模式数据丢就丢了没人专门盯着解析失败率。这种盲区恰恰是攻击者喜欢的。受影响版本与修复路径这次漏洞的波及面不算小。log4j-api从2.13.1到2.25.4的全部版本都受影响2.26.0也未能幸免连3.0.0的早期预发布版本alpha1到beta2也在名单里。Apache给出的解药很直接升级到2.25.5或者2.26.1。这两个版本对非有限浮点值做了RFC 8259合规处理会把NaN和Infinity转换成合法的JSON表达从根本上消除解析失败的可能。如果升级暂时排不上期也有权宜之计。在浮点数值进入日志记录器之前先做一次有限性校验把非有限值拦截掉。具体做法可以是在业务代码里对准备记录的数字调用Double.isFinite()或者在日志配置层增加自定义的过滤器。当然这种缓解措施治标不治本毕竟日志入口可能分散在代码各处很难保证没有漏网之鱼。写在最后Apache Log4j自2021年的Log4Shell事件以来一直是安全社区的重点关注对象。CVE-2026-49844虽然没有当年那个漏洞那么惊心动魄但它揭示了一个常被忽视的安全维度日志不仅仅是记下来就行它的格式合规性、传输完整性、下游可解析性共同构成了审计追踪的可信基础。一旦这个链条上的某个环节被绕过安全团队就会陷入有数据却看不见的困境。对于运维和开发团队来说现在最务实的动作就是清点一下当前环境里的Log4j版本确认是否落在受影响区间。如果用了JsonTemplateLayout或者类似的JSON布局优先级应该再往上提一档。日志安全无小事别让一个非法的NaN成了你安全防线上的盲眼缺口。
七月上旬Apache官方安全团队悄然放出一则补丁公告将编号CVE-2026-49844的漏洞正式纳入已知风险清单。这个藏在log4j-api组件里的小毛病表面看只是JSON序列化时的一个编码疏忽实则可能在关键时刻让你的日志管道彻底瘫痪甚至让安全团队的告警系统变成聋子。一个数字就能搞垮整条日志链事情的起因说起来并不复杂。Apache Log4j在处理MapMessage对象时如果其中包含了NaN、Infinity或者-Infinity这类非有限浮点数值JsonTemplateLayout或者其他调用MapMessage.asJson()方法的布局组件会直接把这些Java原生字符串原封不动地写进JSON输出。可问题在于RFC 8259标准压根就不允许JSON里出现这些裸token。下游的日志采集器、Elasticsearch、Splunk或者各类SIEM平台一旦碰到这种畸形数据大概率会直接把整条记录拒之门外。攻击者不需要什么高深技巧只要找到一个能向日志系统注入浮点数的入口塞一个精心构造的非有限值进去就能让后续的日志流出现断层。这种打法不像传统RCE那样能直接控制服务器但它对可用性和数据完整性的破坏往往更隐蔽、更难排查。为什么日志完整性比代码执行更值得关注很多人看到CVSS 4.0评分6.3归类为中等风险第一反应可能是问题不大。但这种判断在日志安全领域其实有点危险。日志是什么它是你事后溯源的黑匣子是合规审计的底稿也是SOC团队发现异常的生命线。如果攻击者能预测到你的日志解析行为并且知道往哪个字段里扔一个NaN就能让整条记录消失那这本质上就是一种针对可见性的攻击。想象一下某个深夜入侵者已经在你的系统里踩好了点正准备横向移动。正常情况下异常登录、权限提升、敏感文件访问这些行为都会留下痕迹触发告警。可如果关键时间窗口的日志因为格式错误被解析器丢弃你的安全运营中心可能根本收不到那条本该让你从床上弹起来的警报。这种静默丢失比一次性的服务崩溃可怕得多因为你甚至不知道自己错过了什么。漏洞触发的两个必要前提这个漏洞并非无条件触发它的利用路径有一定的门槛。应用必须同时满足两个条件一是使用了JsonTemplateLayout的message resolver或者其他任何依赖MapMessage.asJson()进行序列化的布局二是日志消息本身包含攻击者可控的浮点数值且最终以MapMessage的形式被记录。换句话说如果你的系统只是简单地用Log4j记字符串没有涉及结构化日志里的浮点字段那暂时可以松口气。但现代微服务架构里MapMessage被广泛用于记录结构化上下文——用户ID、请求耗时、坐标位置、传感器读数这些场景里浮点数太常见了。一旦某个API接口把用户输入的数值直接写进日志风险就敞开了。有意思的是这次修复其实还补上了前一轮补丁的漏网之鱼。今年四月披露的CVE-2026-34481已经处理过JsonTemplateLayout里的类似问题但当时的修复只覆盖了一部分代码路径。MapMessage.asJson()这个口子没堵上才有了现在的CVE-2026-49844。Apache官方也坦诚2.25.4版本的补丁并不彻底这才催生了2.25.5和2.26.1的后续更新。当前威胁态势尚未被大规模利用但别掉以轻心从公开情报来看CVE-2026-49844目前还没有现成的概念验证代码流出研究人员也未确认有真实攻击案例在野出现。EPSS评分低于1%CISA KEV列表里也没有它的名字。这些指标说明短期内被脚本小子批量利用的可能性不高。但安全评估不能只看当下。这个漏洞的利用条件并不苛刻攻击向量清晰而且防御方往往在日志解析层缺乏对单条记录格式异常的实时监控。很多企业的日志 pipeline 是fire and forget模式数据丢就丢了没人专门盯着解析失败率。这种盲区恰恰是攻击者喜欢的。受影响版本与修复路径这次漏洞的波及面不算小。log4j-api从2.13.1到2.25.4的全部版本都受影响2.26.0也未能幸免连3.0.0的早期预发布版本alpha1到beta2也在名单里。Apache给出的解药很直接升级到2.25.5或者2.26.1。这两个版本对非有限浮点值做了RFC 8259合规处理会把NaN和Infinity转换成合法的JSON表达从根本上消除解析失败的可能。如果升级暂时排不上期也有权宜之计。在浮点数值进入日志记录器之前先做一次有限性校验把非有限值拦截掉。具体做法可以是在业务代码里对准备记录的数字调用Double.isFinite()或者在日志配置层增加自定义的过滤器。当然这种缓解措施治标不治本毕竟日志入口可能分散在代码各处很难保证没有漏网之鱼。写在最后Apache Log4j自2021年的Log4Shell事件以来一直是安全社区的重点关注对象。CVE-2026-49844虽然没有当年那个漏洞那么惊心动魄但它揭示了一个常被忽视的安全维度日志不仅仅是记下来就行它的格式合规性、传输完整性、下游可解析性共同构成了审计追踪的可信基础。一旦这个链条上的某个环节被绕过安全团队就会陷入有数据却看不见的困境。对于运维和开发团队来说现在最务实的动作就是清点一下当前环境里的Log4j版本确认是否落在受影响区间。如果用了JsonTemplateLayout或者类似的JSON布局优先级应该再往上提一档。日志安全无小事别让一个非法的NaN成了你安全防线上的盲眼缺口。
