凌晨两点十七分，漏洞出现手机屏幕在床头柜上亮了。漏洞出现一条推送，漏洞出现来自公司内部监控系统：核心API响应时间突破800毫秒阈值。漏洞出现我翻了个身，漏洞出现没点开。漏洞出现三分钟后，漏洞出现电话响了。漏洞出现

是漏洞出现运维老张。他声音哑得像砂纸：“登录接口挂了，漏洞出现用户全卡在验证码那步。漏洞出现”我坐起来，漏洞出现打开笔记本，漏洞出现连上VPN。漏洞出现日志刷得飞快，漏洞出现但有个东西不对劲——某个内部服务在疯狂重试，每秒两千次。正常情况这个数字是两位数。

我顺着调用链往上翻，发现所有异常请求都来自同一个IP段，指向我们两周前上线的“推荐引擎”微服务。那服务是我写的。准确说，是我和另一个同事赶工拼出来的。当时为了赶季度目标，我们把鉴权逻辑简化了——内部调用不校验token，只靠网络隔离。运维那边给这组机器划了独立子网，理论上外部碰不到。

但理论这东西，半夜最容易碎。

我点开那台机器的SSH，看进程列表。有个奇怪的Python脚本在跑，文件名是`sync_data.py`，但内容被替换了。它每隔几秒就向一个外部IP发心跳包，同时扫描内网所有可达的Redis实例。我查了下那个外部IP，归属地是东欧某家云服务商。再往下挖，发现这脚本是三天前通过一个叫`deploy_hotfix`的 Jenkins 任务部署的。那个任务原本只该更新配置文件，但有人往构建脚本里塞了一行`curl | bash`。

谁干的？我翻了Jenkins的审计日志。操作人账号是`li.wei`，我们组的前端。但他上周就提了离职，昨天最后一天。我给他发微信，没回。打电话，关机。

老张在语音里喊：“先别管谁干的，把服务停了！”我敲下`kill -9`，但那个脚本有守护进程，三秒后又活了。更糟的是，它开始往数据库写垃圾数据——用户表里出现大量乱码邮箱，密码字段被替换成随机字符串。我意识到这不是普通漏洞，是有人在离职前埋了后门，专门挑凌晨动手。

我们花了四十分钟才彻底清掉那台机器。期间推荐引擎完全不可用，首页推荐位空白，用户刷不出内容。早上六点，CTO在群里问怎么回事。我写了段简短说明，附上日志截图。他没回。中午开会，安全团队的人说那个IP段上周就被标记过异常扫描，但没触发告警——因为规则只监控外网入口，内网横向移动不在覆盖范围。

漏洞从来不是单一代码错误。它是一个链条：赶工留下的鉴权缺口、宽松的部署权限、缺失的内网监控、还有那个离职前没交还VPN密钥的前端。每个环节都“差不多能用”，连起来就成了凌晨两点十七分的电话。

后来我们复盘，发现那个`curl | bash`其实在代码评审时被点过“待确认”，但没人跟进。评审记录里写着“后续处理”，然后就没有后续了。这种事太常见。开发觉得运维会管，运维觉得安全团队会扫，安全团队以为开发已经修了。球在三个人之间传，最后掉在地上。

我删掉了那段简化鉴权的代码，重写了部署流程。但我知道，下一个漏洞已经在某个人的待办列表里躺着，标注着“低优先级”。它不会消失，只会等一个合适的凌晨，亮起来。