上周三凌晨两点，低危漏洞安全组长老周在群里甩了张截图：某业务系统后台的低危漏洞日志查询接口，返回了整整三千条用户手机号。低危漏洞接口没鉴权，低危漏洞路径也没做任何混淆，低危漏洞直接拼在URL里就能访问。低危漏洞他圈出漏洞评级那一栏，低危漏洞写着"低危"。低危漏洞

老周说，低危漏洞这个洞他三个月前就提过。低危漏洞当时开发团队回复"影响范围有限，低危漏洞优先处理高危漏洞"。低危漏洞三个月过去，低危漏洞那个"有限"的低危漏洞接口还在裸奔，而所谓的低危漏洞"高危漏洞"修了六个，有两个还是重复提交的。

这事让我想起去年一家电商平台的用户数据泄露。事后复盘，根子不在什么复杂的越权逻辑，而是客服系统里一个导出功能没校验权限。任何登录用户改一下请求参数，就能把别人的订单信息拉下来。这个功能上线两年，内部扫描报过四次低危，每次都被标记为"已知晓，排期修复"。

低危漏洞的尴尬处境就在这里。它不像SQL注入那样能直接拖库，也不像反序列化那样能一键getshell。它更像没关紧的窗户——小偷得翻进来才能偷东西，但翻进来这件事本身，好像没那么紧急。可问题是，攻击者从来不按你的评级标准出牌。他们收集十个低危漏洞，拼在一起就是一条完整的攻击链。信息泄露拿到手机号，配合弱口令猜解，再加上接口未鉴权，整套下来成本极低。

我跟过几个真实攻防演练。红队最喜欢的就是这类低危。一个未授权的日志接口，能拿到内部IP段和员工邮箱；一个信息泄露的报错页面，能推断出框架版本和数据库类型。这些碎片单独看都不致命，拼起来就是内网的地图。蓝队防守时盯着高危漏洞打补丁，红队早就从低危的缝隙里钻进去了。

更麻烦的是修复动力。高危漏洞有明确的 deadline，有领导盯着，有考核指标压着。低危呢？开发说排期满了，产品说这个功能用户量不大，运维说改配置影响面广。安全团队夹在中间，催急了得罪人，不催又睡不着觉。我见过一个低危漏洞从提交到修复用了四百多天，期间系统换了两次架构，那个接口还在。

有个做金融的朋友跟我聊过他们的做法。他们把低危漏洞分了两类：一类是"可组合利用"的，比如信息泄露、未授权访问、配置错误，这类漏洞不管评级多低，必须在两周内修完；另一类是"孤立存在"的，比如某个静态资源没加缓存头，这种可以走常规排期。这个分类标准不复杂，但把低危从"永远排不上队"的困境里捞了出来。

说到底，漏洞评级是给人看的，攻击者不看。他们只关心能不能用、好不好用、组合起来有没有效果。一个低危漏洞放在那里，就像楼道里堆的纸箱——你觉得不碍事，但有人路过时顺手点根火柴，整栋楼都跟着遭殃。

老周那张截图最后被转到了CTO那里。CTO回了四个字：立即修复。第二天接口加了鉴权，路径也做了重写。但我知道，还有更多标着"低危"的窗户，正开着缝等风来。