2023年3月，远程某企业内网一台测试服务器被植入挖矿程序，代码CPU占用率飙到90%以上。执行运维排查后发现，漏洞攻击者利用的补丁正是Apache Log4j2的一个远程代码执行漏洞。这台服务器上跑着一个内部日志分析系统，远程版本是代码2.14.1——漏洞披露已经过去一年多，补丁始终没打。执行

远程代码执行漏洞的漏洞破坏力，和普通漏洞不在一个量级。补丁SQL注入最多丢数据，远程XSS最多劫持会话，代码RCE直接让攻击者在你服务器上跑任意代码。执行想读文件读文件，漏洞想装后门装后门，补丁想横向渗透就横向渗透。权限拿到之后，整台机器就是别人的了。

补丁这件事，难的不是“知不知道要打”，而是“能不能打”。我见过一个真实场景：某金融公司的核心交易系统依赖一个老版本中间件，厂商明确说升级后不保证兼容。业务部门不敢动，安全部门催着打补丁，两边僵了三个月。最后怎么解决的？在中间件前面加了一层WAF规则做虚拟补丁，同时在新采购的服务器上部署了修复版本，等业务迁移过去再下线老系统。这种折中方案不完美，但比什么都不做强。

虚拟补丁和真正的代码补丁是两回事。WAF规则、RASP探针、网络层ACL，这些只能挡住已知的攻击模式。攻击者换个编码方式、换个协议路径，规则就可能被绕过。真正的修复必须落到代码层面——升级组件版本、替换存在漏洞的函数、重新编译部署。这个过程涉及测试、灰度、回滚预案，工作量不小。但省掉这一步，就等于把门锁换成了纸糊的。

打补丁的时机也有讲究。漏洞披露后的72小时是黄金窗口，攻击脚本往往在PoC公开后几小时内就会出现。2021年底Log4j漏洞爆发时，我认识的一个安全团队连夜升级了所有对外服务，但内部系统拖了一周。结果外部没出事，内部反而被扫到了。攻击者才不管你的系统是对外还是对内，能连上网就是目标。

还有一个容易被忽略的点：补丁打了不等于问题解决了。升级完组件，得确认旧版本进程真的被替换掉了。我遇到过运维执行了升级命令，但服务没有重启，内存里跑的还是带漏洞的旧代码。也有升级后配置文件没同步，新版本用了默认配置，反而打开了调试接口。补丁管理是个闭环——发现、评估、测试、部署、验证，少一步都可能是白干。

说回开头那台被挖矿的服务器。事后复盘，问题出在资产清单不准确。这台机器登记的是“已下线”，实际还在跑业务。安全团队按清单推补丁，自然就漏了它。RCE漏洞的修复，技术手段只是一半，另一半是资产管理和变更流程。你连自己有什么机器都不知道，谈什么打补丁。

现在很多团队开始用SCA工具做组件成分分析，自动识别依赖库里的已知漏洞。方向是对的，但工具报出来的漏洞列表动辄几百条，真正能被利用的RCE可能就几条。优先级怎么排？我的判断标准很简单：能直接触达的、无需认证的、利用条件不苛刻的RCE，排在最前面。其他的可以按节奏来。资源有限的时候，把力气花在刀刃上。

补丁不是万能药，但不打补丁是万万不能的。攻击者的工具在进化，自动化扫描和利用框架越来越成熟。一个未修复的RCE漏洞，从被发现到被利用，可能只需要几分钟。防守方的时间窗口，比想象中窄得多。