2021年冬天，漏洞遇Log4j2的漏洞遇那个漏洞爆出来时，我正蹲在客户机房调一台老服务器的漏洞遇日志采集。手机震了十几下，漏洞遇全是漏洞遇安全群的消息，有人甩了条链接，漏洞遇说“核弹级”。漏洞遇我点开一看，漏洞遇JNDI注入，漏洞遇远程代码执行，漏洞遇CVSS评分10.0。漏洞遇当时没觉得多严重，漏洞遇因为这台机器根本不连外网。漏洞遇但三小时后，漏洞遇我发现自己错了——内网另一台测试机在跑Jenkins，漏洞遇而Jenkins用了Log4j2。那台测试机能访问这台老服务器。链条就这么串起来了。

漏洞这东西，从来不是孤立的。它像水管上的砂眼，单独看就一个小点，可一旦水压上来，整面墙都得泡烂。Log4j2的可怕之处在于它太基础了，基础到像空气一样无处不在。Java生态里几乎每个框架都直接或间接依赖它。你写个logger.info(userInput)，用户输入里带个${ jndi:ldap://...}，服务器就去请求那个地址，下载并执行恶意类。整个过程不需要你写错什么逻辑，只是“用了这个库，调了日志”。

我见过一个真实案例。某公司内网有个资产管理系统，页面有个搜索框。搜索框的内容会写进日志。攻击者在内网钓鱼邮件里放了个链接，点开就触发搜索请求，参数里塞了JNDI payload。服务器中招，反向shell弹到攻击者机器上。从点击到失陷，不到两分钟。事后复盘，安全团队说“我们没暴露Log4j2到公网”。可攻击者根本不需要公网，他只需要一个能触发日志写入的入口，加上内网某台机器能出网。这两条件一凑，漏洞就活了。

修复过程更让人头疼。你以为升级版本就完了？很多老系统锁死在Java 6或7，Log4j2的新版本要求Java 8+。升级Log4j2意味着升级JDK，升级JDK意味着改代码、回归测试、重新部署。一个跑了八年的ERP系统，谁敢动？于是大家开始用各种临时方案：设置log4j2.formatMsgNoLookups=true，删掉JndiLookup.class，或者上WAF拦关键词。这些招都有用，但都有漏。比如删class文件，如果应用用了自定义classloader，可能加载不到；WAF拦${ jndi，攻击者可以编码绕过，${ ${ lower:j}ndi:...}。

更有意思的是漏洞披露后的混乱。安全厂商抢着发通告，扫描器厂商连夜更新插件，甲方安全团队疯狂扫资产。扫出来的结果吓人：几千个受影响实例。可真正能利用的有多少？得看网络拓扑、看出网策略、看JDK版本。很多扫描器只测版本号，不测实际可达性。于是安全团队拿着报告去找运维，运维说“这机器早下线了”“这IP是测试环境”。扯皮半个月，真正该修的没修几个。

我自己后来写了个小脚本，专门跑内网，不扫版本，直接发一个无害的JNDI请求到自己的LDAP服务器。能连上的，就是真能利用的。扫了三百多台，真能打的只有七台。这七台里，五台是开发机，一台是CI/CD节点，一台是内部Wiki。Wiki那台最要命，因为它能访问代码仓库。攻击者拿到Wiki的shell，翻配置文件，找到仓库凭据，拉代码，改代码，推代码。整条供应链就断了。

漏洞遇到的不只是代码，还有人。有次我给一个团队讲Log4j2，讲完问“你们打算怎么修”，一个运维说“等厂商出补丁”。我说补丁早出了。他说“我们用的中间件厂商还没发适配版”。这就是现实：漏洞在开源库里，但你用的商业产品把它包了一层，你得等商业厂商重新打包、测试、发版。这中间的时间差，就是攻击窗口。

最后那台老服务器怎么处理的？我把它从网络里摘出来，单独划了个VLAN，只允许采集端口出向流量。日志采集继续跑，但JNDI出不去。漏洞还在，只是够不着了。有时候修复不是消灭漏洞，是让漏洞够不着你。这道理，跟锁门一样——门不一定非要换成保险门，但至少得把窗户关上。