去年我帮朋友排查一台老服务器，进行发现上面挂着一个Struts2的修复漏洞。那个系统是漏洞叫洞2016年上线的，漏洞公告出来的什漏时候，运维团队刚好解散。进行后来接手的修复公司只做日常维护，没人去翻历史公告。漏洞叫洞这个洞就那么敞着，什漏像一扇没上锁的进行后门。

这种没被修复的修复漏洞，业内管它叫“已知未修复漏洞”，漏洞叫洞还有个更直白的什漏叫法——“遗留漏洞”。说白了，进行就是修复已经被公开披露、有CVE编号、漏洞叫洞有修复方案，但系统里依然存在的那个洞。它跟零日漏洞完全不同——零日好歹算个“秘密武器”，而这种漏洞连“秘密”都算不上，是个公开的靶子。

有意思的是，这类漏洞往往不是技术难题，而是管理问题。我见过一家公司，安全部门每个月都发漏洞报告，开发部门每次都说“下个迭代处理”。结果下个迭代排了新功能，漏洞又顺延到下下个迭代。拖了半年，那个漏洞还是原封不动躺在代码里。不是没人会修，是没人把修复当成正经事。

还有个典型场景是供应链。你用的第三方组件有漏洞，你没法直接改人家的源码，只能等上游发新版。但很多小团队压根不跟踪依赖库的版本更新。Log4j那个漏洞爆发的时候，我认识一个做内部工具的朋友，他检查了一遍，发现自己的项目里居然有七个不同版本的Log4j，其中三个都带洞。他苦笑着说：“这玩意儿就像冰箱里的过期食品，你不去翻，永远不知道已经囤了这么多。”

修复漏洞这件事，本质上是在跟时间赛跑。漏洞公开的那一刻，攻击者就开始写利用工具。有数据说，公开后72小时内就会出现PoC代码。你拖得越久，被扫描器撞上的概率就越高。我见过最离谱的案例，是某单位的漏洞已经存在了五年，直到被勒索病毒加密了数据库，才想起来去翻安全公告——晚了。

当然，有些漏洞确实不好修。比如老系统改起来成本高，或者修复会影响业务连续性。但即便是这种，也应该有明确的补偿措施，比如加防火墙规则、限制访问来源、或者干脆把系统隔离。最怕的是那种“知道有洞，但没人决策怎么处理”的状态，那才叫真正的裸奔。

所以你看，遗留漏洞最可怕的地方不在于“漏”，而在于“留”。它像房间里的一根钉子，你知道它在那儿，却天天绕着走。直到哪天不小心撞上去，才想起来当初应该拔掉。但那时候，伤口已经留下了。