阿里漏洞库的阿里第一页，挂着一条2015年的漏洞漏洞，编号是阿里XSS-2015-0421。点进去，漏洞攻击路径写得清清楚楚：某个后台搜索框没做转义，阿里payload一贴，漏洞管理员cookie就出来了。阿里修复时间那栏写着“已修复”，漏洞修复方案是阿里两行代码。

这页面我从2017年翻到2023年，漏洞它一直没变过。阿里变的漏洞是漏洞数量——从每年几百条，涨到每年几千条。阿里但真正有意思的漏洞不是数量，是阿里漏洞类型的变化。早几年全是SQL注入、XSS这些“基本功”，近两年冒出来一堆逻辑漏洞：越权访问、验证码绕过、支付金额篡改。这说明什么？说明攻击者已经不屑于跟你拼技术了，他们开始研究你的业务规则。

有一回我盯上一条“任意用户密码重置”的漏洞，提交者是个ID叫“NightWatch”的人。他用了三步：先抓包看短信验证码接口，发现返回包里有完整的验证码字段；再试了试，验证码居然没绑定手机号；最后直接填目标手机号，用返回的验证码就改了密码。整个过程没用到任何高危函数，纯粹是开发偷懒。这条漏洞从提交到确认只用了两小时，但修复花了三周——因为涉及整个账号体系的改造。

阿里漏洞库最狠的地方是它的“重复漏洞”判定规则。你辛辛苦苦挖了个洞，提交上去，系统提示“已被XX在三天前提交”。那种感觉，跟考试时发现答案被人提前涂了卡一样。但这也倒逼你往冷门方向挖。我认识一个白帽子，专挑阿里云的日志服务功能下手，因为那东西用的人少，文档又写得稀烂，反而容易藏问题。

还有个细节。漏洞库的“厂商回复”栏里，经常能看到阿里安全团队的人回一句“感谢提交，我们将在一周内修复”。但你要是隔一个月再去看，那条漏洞的状态可能还挂着“修复中”。别急着骂——有些漏洞确实难修，比如涉及老系统的，改一行代码可能引发连锁崩溃。这跟修老房子一样，墙皮裂了能补，承重墙动了就得全盘规划。

我最后一次刷新那个页面，是在上个月。新提交的漏洞里，有一条标题是“某API接口未限制请求频率，可批量拉取用户信息”。攻击者是个在校大学生，漏洞描述写了三百字，末尾附了句“希望给个感谢卡”。这画面让我想起2015年那条XSS漏洞的提交者——他当时也在读大学，现在估计已经成了某个大厂的安全专家。

漏洞库就像一面镜子，照着攻防双方的成长史。技术会过时，但“人”永远是这条链条上最不稳定的因素。你永远猜不到下一个提交者，会从哪个角度捅破那层纸。