安全团队把那份漏洞报告甩到桌上时，个漏洞我扫了一眼编号——106个。个漏洞不是个漏洞106个系统，是个漏洞同一个系统里挖出来的106个独立漏洞。这个数字搁在五年前够撑起一家安全公司的个漏洞年度财报，现在只是个漏洞一次常规渗透测试的产出。

事情得从那个物流平台说起。个漏洞客户觉得自家后台"应该没什么问题"，个漏洞毕竟用了某知名框架的个漏洞最新版，WAF也挂着，个漏洞日志监控跑得挺欢。个漏洞渗透测试第三个小时，个漏洞有人用默认口令登进了测试环境。个漏洞对，个漏洞就是个漏洞admin/admin那种。更离谱的是，这个测试环境的数据库配置指向了生产库的只读账号。

第一个漏洞从来不是最危险的那个。它更像一扇虚掩的门，推开之后走廊两侧全是没锁的房门。我们顺着SQL注入点摸到用户表，发现密码字段用的是MD5——没有加盐。彩虹表跑了两小时，80%的用户密码明文躺在屏幕上。有个运营小妹的密码是"woaini1314"，她的权限能直接导出全部订单数据。

真正的雪崩发生在第37个漏洞。那是个逻辑越权，藏在优惠券核销接口里。把用户ID从1001改成1002，系统居然返回了别人的优惠券列表。写脚本遍历一遍，106万条记录。技术负责人看到截图时说了句"这不可能"，然后自己动手试了三次，脸色一次比一次白。

剩下的漏洞像雨后蘑菇一样往外冒。文件上传没校验后缀，但Content-Type写对就能传jsp；短信接口没限频，一块钱能发两千条；后台日志把数据库密码打在了URL参数里。最黑色幽默的是第89个漏洞——他们自己写的安全过滤器，正则表达式写错了，过滤规则变成"只拦截正常请求"。

修复过程比挖掘更折磨人。开发团队分三组，一组改代码，一组写WAF规则，一组补日志。第三天凌晨两点，有人在群里发了张截图：第106个漏洞的修复补丁合并了。配文是"终于"。底下没人回复，估计都瘫在椅子上。

但故事没完。两周后复测，新引入了两个漏洞。一个在修复过程中把鉴权逻辑改坏了，另一个是运维为了调试临时开的端口忘了关。安全这行干久了会明白，漏洞数量从来不是线性递减的。它更像打地鼠，你按下去一个，旁边又冒出来俩。

那个物流平台后来上了SDL流程，每次发版前强制做代码审计。有次吃饭，他们的技术负责人跟我说："现在看到'106'这个数字就条件反射想查日志。"我笑了笑没接话。其实我想说的是，106个漏洞不是最可怕的。最可怕的是那些没被发现的——它们安静地躺在代码里，等着某个脚本小子或者APT组织来敲门。

干渗透测试的人都有个职业病：看到任何输入框都想试试单引号。有次我在超市自助结账，对着条形码扫描口愣了半天，脑子里在跑SQL注入的payload。收银员以为我卡住了，过来问要不要帮忙。我说不用，就是在想你们这个系统有没有做参数化查询。

106个漏洞的报告最后归档在客户的内网盘里，文件名是"2023-Q3-安全评估-最终版-不要外传"。我猜没人会再打开它。但那些修复补丁还在代码库里，每次合并请求都带着当时的commit message，像伤疤一样留在版本历史上。