厂商没有修复的厂商漏洞叫“既定行为”。

我盯着屏幕上那个标着“Won't Fix”的修复工单看了很久。提交漏洞的漏洞叫是个刚入职的安全研究员，语气里带着新人特有的厂商兴奋，附上了完整的修复复现步骤和一段概念验证代码。三天后厂商回了三个字：不影响。漏洞叫代码还挂在文档里，厂商漏洞描述被改成了“预期功能”。修复

这行字背后是漏洞叫另一种逻辑。厂商的厂商修复优先级从来不是按危险程度排的，是修复按商业影响排的。一个能进内核的漏洞叫提权漏洞可能连夜修，因为会影响云服务客户的厂商续费率；但一个需要物理接触设备才能触发的后门，大概率会被标记为“低风险”然后扔进某个永远不打开的修复文件夹。不是漏洞叫修不了，是不值得修。

更隐蔽的一类是“设计如此”。某路由器厂商的固件里留着一个调试端口，文档里写的是“供工厂测试使用”。但那个端口在出厂后依然开着，而且用的是硬编码的弱口令。提交给厂商，回复说这是产品特性，不建议修改，因为改了会影响产线效率。你看，漏洞一旦和生产流程绑定，就成了不能动的祖宗。

还有那些“修了反而更糟”的漏洞。一个开源库的维护者跟我抱怨过，某个漏洞的修复方案需要改动核心数据结构，会影响所有依赖这个库的上层应用。他权衡了两周，最后选择把漏洞文档留在仓库里，加了个“已知问题”的标签。不是不想修，是修了以后会产生更多不可控的bug，那还不如让这个漏洞继续躺着。

最讽刺的是有些漏洞厂商是真想修，但修不动。老系统的代码早就没人看懂了，核心模块的作者离职了，文档也丢了。新来的工程师对着几万行汇编无从下手，最后只能把漏洞描述改成“建议用户升级到新版本”。可用户不升级，新版本太贵了。于是这个漏洞就成了一个公开的秘密，在安全圈子里流传，但没人再提。

厂商不修的漏洞，大致可以分成三类：影响太小懒得修，影响太大不敢修，影响不清没法修。但不管哪一类，最后都会在工单系统里留下同一个状态——Closed as Not a Bug。这个状态的意思是：我们知道了，但我们不打算处理。你拿它没办法。

有个老前辈跟我说过一句话：漏洞这东西，厂商比你更清楚它在哪。他们不修，要么是觉得不值，要么是觉得不能，要么是觉得不必。真正让人头疼的不是那些被公开的漏洞，而是那些被“温和地拒绝”的漏洞——它们永远处于一种半公开的状态，像一颗定时炸弹，但没人知道倒计时走到哪了。

后来我也学会了。提交漏洞之前先看厂商的修复历史，看他们最近修过什么类型的问题，看他们的安全团队规模有多大，看他们的产品线是不是已经进入维护期。如果发现这个厂商最近半年只修过几个高危漏洞，其他全是“Won't Fix”，那我基本就明白了——这个厂商的漏洞，不是用来修的，是用来记录的。

记录在案，然后继续用。这就是现实。