2021年12月，高危Apache Log4j2 被曝出一个远程代码执行漏洞，漏洞编号 CVE-2021-44228。修复攻击者只需构造一段形如 ${ jndi:ldap://...} 的高危字符串，就能让目标服务器加载远程恶意类文件，漏洞直接拿到系统权限。修复这个漏洞波及全球数百万台服务器，高危从苹果 iCloud 到 Steam 游戏平台，漏洞无一幸免。修复

我之所以拿它开篇，高危是漏洞因为它完美展示了高危漏洞的本质：利用门槛极低，影响范围极广，修复留给防守方的高危反应时间极短。

所谓高危漏洞，漏洞通常指 CVSS 评分在 7.0 以上的修复安全缺陷。但分数只是参考，真正决定一个漏洞危险程度的，是三个现实因素——利用代码是否公开、受影响资产是否暴露在公网、以及补丁能否快速落地。Log4j 三项全中，所以它成了年度灾难。

修复高危漏洞这件事，最怕的不是技术难，而是节奏乱。我见过不少团队一收到漏洞告警就全员扑上去，结果资产清单没理清，补丁兼容性没验证，测试环境都没跑通就往生产推，最后漏洞没修好，业务先挂了。

合理的做法是分三步走，但这里说的“三步”不是教科书上的流程，而是实战中真正管用的顺序。

第一步，搞清楚你到底有多少资产受影响。这话听起来像废话，但我跟你讲，大部分公司根本不知道自己跑了多少个 Log4j 实例。微服务架构下，一个业务请求可能穿过七八个服务，每个服务依赖的组件版本都不一样。靠人工排查，黄花菜都凉了。得用软件成分分析工具自动扫描依赖树，把直接依赖和传递依赖全揪出来。同时查清哪些资产对外暴露，优先处理公网可达的。

第二步，缓解措施先上，别等完美补丁。Log4j 漏洞爆发时，官方补丁出了好几版，每版都有绕过。与其干等，不如先在 JVM 参数里设 log4j2.formatMsgNoLookups=true，或者用 WAF 拦截 JNDI 注入特征。这些手段不彻底，但能争取时间窗口。我认识一个运维负责人，他当时直接批量改了启动脚本，两小时内覆盖了八成生产节点。剩下两成因为版本太老改不了，才走紧急升级流程。

第三步，补丁验证要分层做。别指望在测试环境跑一遍就完事。高危漏洞的修复往往涉及底层库升级，可能引发依赖冲突、接口行为变化。我们的做法是：先在预发布环境跑自动化回归，再挑一个非核心业务的生产节点灰度，观察 24 小时。指标正常，再分批推全量。听起来慢，但比全量回滚快得多。

还有一个容易被忽略的点：修完不等于结束。你得确认攻击者有没有在漏洞窗口期进来过。查日志、查异常进程、查外连记录。Log4j 那波，很多公司补丁打完了，三个月后才发现已经被挖了矿。

说到底，高危漏洞修复考验的不是某个人的技术深度，而是团队的工程素养和应急纪律。工具能帮你定位问题，但决策节奏、优先级判断、风险取舍，这些得靠人。别追求一次修完所有东西，先堵住最致命的缺口，再逐步收尾。漏洞永远修不完，但你可以让自己不那么容易被击穿。