去年十一月，系统修复我帮一个做跨境电商的高危朋友看服务器。他图省事，漏洞把后台管理系统直接暴露在公网，系统修复密码是高危 admin123。我扫了一眼日志，漏洞过去三天有十七个不同 IP 尝试过登录，系统修复其中一个已经成功，高危还上传了一个 WebShell。漏洞他问我怎么办。系统修复我说先断网，高危再谈修复。漏洞他犹豫了一下说，系统修复网站还在跑订单，高危能不能等晚上。漏洞我说你现在每多开一分钟，客户数据就在别人手里多转一圈。他沉默了五秒，拔了网线。
这就是系统高危漏洞的典型处境。它不是会不会被利用的问题，是已经被利用了多少次、你知不知道的问题。很多人把漏洞修复当成"有空再做"的维护事项，但高危漏洞的本质是：攻击者比你更清楚它的存在，而且已经在写了利用脚本。你拖一天，等于把钥匙插在门上出门逛街。
那为什么还有人拖着不修？我观察下来，理由无非三种。第一种是"业务不能停"。修复要重启，重启要停机，停机要损失订单。这个逻辑听起来合理，但算错了账——停机两小时的损失是确定的，数据泄露的代价是不确定的，而不确定的东西往往更贵。第二种是"没人攻击我"。这是幸存者偏差。你没发现被攻击，不代表没被攻击。很多入侵者会先留后门，观察几个月再动手。第三种最麻烦：知道有漏洞，但不知道怎么修。老旧系统、没人维护的代码、离职员工写的模块，修起来像拆炸弹。
但真正让我警惕的，是另一种态度：把高危漏洞当成"技术问题"，交给技术团队处理就完了。不是的。高危漏洞是管理问题。它考验的是你愿不愿意为不确定的风险付出确定的成本。我见过一个 CTO，发现漏洞后直接给 CEO 发了封邮件，标题写"我需要你批准今晚停机四小时"。CEO 回了一个字：准。后来他们修完漏洞，顺带把备份策略也改了。这个决定不是技术判断，是优先级判断。技术团队只能告诉你"这个洞有多危险"，但"要不要现在修"是业务决策。
那到底怎么判断一个高危漏洞要不要立刻修？我的标准很简单：如果这个漏洞被利用后，攻击者能拿到数据、能执行命令、能横向移动，那就必须立刻修。没有例外。如果只是信息泄露但泄露的是公开信息，或者需要物理接触才能触发，可以排期。但排期不等于忘记，得有个明确的截止日期，而不是"下个迭代看看"。
修复本身也有讲究。打补丁是最直接的，但有些系统不能打补丁，那就得用虚拟补丁、WAF 规则、网络隔离来缓解。缓解不是修复，是买时间。买来的时间得用来做真正的修复，而不是用来继续拖。我见过一个团队，用 WAF 挡了半年，最后发现 WAF 规则写错了，漏洞一直敞着。这就是把缓解当成了终点。
说回我那个朋友。他断网之后，花了六个小时清理后门、改密码、加防火墙规则。第二天他给我打电话，说订单数据没丢，但客户手机号可能泄露了。他问我要不要通知客户。我说你自己判断。他想了半天，发了通知。后来有几个客户投诉，但更多人回信说谢谢告知。他说早知道这么简单，就不该犹豫那五秒。
高危漏洞要修复吗？要。而且要快。不是因为它一定会出事，是因为你赌不起。你赌的是攻击者没空、脚本没写好、运气够好。但攻击者不赌，他们只算概率。你的系统在他们眼里就是一个待办事项，你拖得越久，它越靠前。拔网线那五秒的犹豫，可能就是数据泄露和没泄露之间的距离。