2021年冬天，漏洞案例Log4j2的漏洞案例那个漏洞——CVE-2021-44228——把半个互联网搅得鸡飞狗跳。一个叫`${ jndi:ldap://...}`的漏洞案例字符串，塞进任何能被日志记录的漏洞案例地方，就能让服务器主动去连攻击者的漏洞案例地址，把class文件拉下来执行。漏洞案例CVSS评分10.0，漏洞案例满分。漏洞案例我当时在的漏洞案例公司连夜排查，运维群里消息刷到凌晨三点。漏洞案例

这个漏洞的漏洞案例本质不复杂。Log4j2在打印日志时，漏洞案例会解析字符串里的漏洞案例`${ }`表达式，其中`jndi:`这个lookup功能允许远程加载。漏洞案例设计者的漏洞案例初衷是方便——比如动态获取环境变量、配置值。问题是，这个解析是默认开启的，而且不需要任何权限校验。你只要让服务器记一条日志，就够了。

攻击面大到离谱。用户登录时输错用户名？那串错误信息会被记进日志。HTTP请求头里的User-Agent？也会被记。甚至你在电商平台搜索框里敲几个字，后台可能就把搜索词写进日志了。换句话说，攻击者不需要什么高深技巧，往输入框里粘贴一段恶意字符串，剩下的交给Log4j就行。

一个真实的攻击链

安全研究者Marcus Hutchins当时做了个演示。他搭了一个存在漏洞的Minecraft服务器——Minecraft服务端用Log4j记录聊天消息——然后在游戏聊天栏里输入那段JNDI字符串。几秒后，服务器就从他控制的LDAP服务器上下载并执行了一个恶意类。整个过程不需要任何游戏内权限，普通玩家就能做到。

Minecraft只是冰山一角。苹果iCloud、Steam、Twitter的部分服务、亚马逊AWS的部分基础设施，都被证实受影响。Cloudflare的CEO在推特上说，他们一天之内拦截了数万次利用尝试。这不是某个小网站的局部问题，是底层组件级别的系统性风险。

为什么没人提前发现

Log4j2是Apache基金会的项目，用的人多，审的人少。JNDI lookup这个功能存在了好几年，没人觉得它是个安全问题——直到有人真正去想“如果输入可控会怎样”。安全审计有个老问题：代码review时大家盯着业务逻辑漏洞，很少有人会去质疑一个日志库的表达式解析功能。

另一个原因是依赖链太深。很多开发者根本不知道自己用了Log4j2——它是被Spring Boot、Kafka、Elasticsearch这些框架间接引入的。你写业务代码时不会直接import它，但它在classpath里躺着。这就是供应链安全的典型困境：你信任的框架信任了别的库，而那个库出了事。

修完之后呢

Apache很快发了补丁，2.17.0版本默认禁用了JNDI lookup。但后续又发现了绕过方式——比如通过`${ ${ lower:j}ndi:...}`这种嵌套写法绕过低版本的限制。补丁打了三轮才基本堵住。很多公司升级完以为没事了，结果扫描器又报出新的绕过。

这件事改变了一些东西。SBOM（软件物料清单）从合规要求变成了实际需求，企业开始认真梳理自己的依赖树。但说实话，大部分中小团队至今也说不清自己项目里到底有多少个间接依赖。下次再出一个Log4j级别的漏洞，该慌还是得慌。

漏洞不会消失。只要代码在写，依赖在用，就总有下一个。区别只在于，你是提前知道自己在用什么，还是等凌晨三点的电话打过来。