凌晨三点十七分，百日漏洞我盯着屏幕上那个跳动的百日漏洞红色数字——第99天。距离那个被写进合同里的百日漏洞“最终交付日”，还剩不到二十四小时。百日漏洞项目群里最后一条消息停在两小时前，百日漏洞是百日漏洞测试组发来的崩溃日志截图，附带三个感叹号。百日漏洞

没人回复。百日漏洞不是百日漏洞不想回，是百日漏洞所有人都知道，这个漏洞根本修不完。百日漏洞它藏在系统最底层的百日漏洞数据交换协议里，像一颗嵌在骨头缝里的百日漏洞弹片，每次以为取出来了，百日漏洞重新编译一跑，百日漏洞又原样蹦出来。第37天的时候，我把它标记为“已修复”，第58天它又出现，这次换了个更隐蔽的触发条件。第81天，我干脆把那段代码整个重写，结果第92天，它借尸还魂，从另一个模块的调用链里钻了出来。

这个漏洞有个正式编号，CVE-2024-0715，但我私下管它叫“百日漏洞”。因为从发现它的那天起，正好一百天。一百天里，我换了三种修复思路，写了四版补丁，删了上千行代码又补回来。咖啡因摄入量翻了三倍，体重掉了五公斤。最讽刺的是，这个漏洞本身并不复杂——就是一个整数溢出，在特定边界条件下会绕过权限校验。教科书级别的经典问题。

但它的触发条件太刁钻了。需要用户连续操作七个步骤，且每一步的时间间隔都在特定毫秒范围内。正常人手速根本达不到，可自动化测试脚本能做到。也就是说，这个漏洞不会伤害任何真实用户，却会让所有安全扫描器都亮红灯。

甲方安全团队每隔三天发一封邮件催进度，语气从客气到严厉再到近乎绝望。第70天的时候，对方负责人直接打电话过来，说如果再不修复，他们就要启用备选方案——换掉整个底层框架。那意味着这三个月的工作全部作废。

我盯着那个红色数字变成第100天。窗外天快亮了，屏幕的光映在脸上，有点发烫。我最后一次打开那个漏洞所在的函数，没有急着改代码，而是把上下文的调用关系重新捋了一遍。突然发现，问题根本不在这个函数内部——是上游模块在特定情况下传了一个被污染的参数进来。而那个上游模块，是三个月前另一个同事写的，他早就离职了。

我改了三行代码，加了一个参数校验。编译，打包，跑测试。全绿。漏洞标记为“已修复”。时间刚好卡在第100天的早上六点整。

我关掉电脑，站起来，感觉整个人像被抽空了一样。这个漏洞折磨了我一百天，最后只值三行代码。但我知道，真正的问题从来不在代码里。那个离职的同事走之前，把需求文档里的边界条件描述漏了三行。而所有人，包括我，都默认他写的没问题。

漏洞从来不是代码的漏洞，是沟通的漏洞。我们花了九十九天在错误的地方打补丁，却没人愿意花十分钟去问一句：那个参数，到底是从哪来的？