内容摘要：那封回复函是凌晨两点十七分收到的。我盯着屏幕上的"已阅"两个字，光标在输入框里闪了十七下，最后只敲出一句：漏洞编号CVE-2024-3891，修复补丁已于三小时前推送，但你们系统里的旧版本还在跑。 这

那封回复函是系统凌晨两点十七分收到的。我盯着屏幕上的漏洞"已阅"两个字，光标在输入框里闪了十七下，回复函最后只敲出一句：漏洞编号CVE-2024-3891，系统修复补丁已于三小时前推送，漏洞但你们系统里的回复函旧版本还在跑。

这行字发出去的系统时候，我知道对方大概率不会看。漏洞运维老张上周还在跟我抱怨，回复函说他们那套订单系统从2019年上线就没动过，系统Java 8的漏洞运行时，Struts2的回复函框架，连Log4j都没升到2.17。系统我问他为什么，漏洞他说"动不了，回复函一动就崩，老板说等下次大版本再说"。

下次。这个词在技术圈里跟"稍后处理"一样，基本等于"永远不处理"。

漏洞本身不复杂。一个反序列化的口子，构造好的payload能直接弹shell。我在内部靶场复现的时候，从发送请求到拿到root权限，一共花了四秒。四秒，够干什么？够泡面还没撕开调料包，够电梯从一楼到十楼，够一个没打补丁的系统被人从里到外翻个底朝天。

但回复函不能这么写。得按模板来：漏洞等级、影响范围、修复建议、参考链接。我写了三页，附了十二张截图，连Burp Suite的请求包都贴进去了。发出去之后，对方技术负责人回了一句话："我们评估一下。"

评估。这个词比"下次"还玄学。上次有个SQL注入的漏洞，我发了三封邮件催，最后他们回了个"已转交相关同事"。那个相关同事我到现在都没见过，企业微信里搜不到，邮箱也退信。

说实话，干这行久了，你会慢慢接受一个事实：大部分系统漏洞不是修不好，是没人愿意修。修一个漏洞要走变更流程，要写测试报告，要等窗口期，要背可能影响业务的锅。不修呢？不修只是"存在潜在风险"，风险这东西，只要没爆，就等于没有。

我见过最离谱的一个案例。某单位的OA系统，PHP 5.3，上传目录直接给了777权限。我写了个webshell传上去，他们安全处的人打电话过来，第一句话是"你能不能先删掉，我们领导看到会扣分"。我说这不是扣分的问题，这是你家大门敞开的问题。他说"我知道我知道，但你先删，我们内部处理"。

后来那个webshell我删了。再后来，那个系统在三个月后被人挂了黑页，首页上飘着一面旗子。我不知道是不是同一批人干的，但我知道那个上传目录还是777。

回到这封回复函。我最后加了一段话，没按模板写："如果你们决定不修，麻烦在工单里备注一下，就说已知悉风险，业务方接受。这样下次出了事，至少能分清是谁的责任。"

发完我就关电脑了。第二天早上打开邮箱，对方回了一个字："好。"

那个"好"字下面，是系统自动附上的原始邮件，三页修复建议，十二张截图，安安静静地躺在那里。像一份没人签收的快递，你知道里面装的是灭火器，但收件人觉得，反正火还没烧起来。