2010年，银行一名普通IT工程师在澳大利亚联邦银行的系统一台ATM前蹲了不到十分钟，用一部诺基亚手机和一根USB线，漏洞就让机器开始无限制吐钞。案例这不是银行电影桥段，是系统真实发生的案子。漏洞出在ATM的漏洞固件更新机制——银行把加密密钥硬编码在系统里，而且所有机器共用同一个。案例工程师没入侵核心数据库，银行只是系统找到了后门。

银行系统漏洞往往不是漏洞“被黑客攻破”，而是案例“自己把门开着”。2016年孟加拉国央行那起8100万美元盗窃案，银行攻击者没用什么零日漏洞，系统他们只是漏洞伪造了SWIFT转账指令，而银行的后台系统居然没有校验交易金额与账户余额的匹配逻辑。一笔笔转账指令被发送出去时，系统连“这个账户里有没有这么多钱”都没问。漏洞不在防火墙，在业务逻辑。

我翻过几份公开的银行漏洞报告，发现一个规律：最要命的问题通常出现在系统升级或接口对接阶段。2019年，某国内城商行上线新手机银行App，为了兼容老版本，保留了旧的API接口。结果这个旧接口没有做频率限制和身份二次校验。攻击者用脚本批量尝试手机号加默认密码，一夜之间撞开了三千多个账户。银行第二天才发现，因为风控系统只监控“异常大额转账”，对这种小额、多笔、分散的操作毫无反应。

技术层面之外，人的因素更直接。某股份制银行曾发生一起内部人员利用测试环境漏洞案。开发人员在测试服务器上留了一个万能登录后门，方便调试。这个后门没有在投产前删除。一名外包运维人员发现后，用它在三个月内修改了上百个客户的预留手机号，配合外部团伙拦截短信验证码，盗刷金额超过两百万。银行直到客户投诉“收不到验证码”才排查到问题。漏洞不是技术不够强，是流程管不住人。

再说一个细节。很多银行的核心交易系统还在用COBOL写的批处理程序，每天凌晨跑一次对账。这意味着，如果有人在白天利用漏洞转走一笔钱，只要在日终对账前把账面做平，系统就不会报警。2018年，某外资行香港分行就吃了这个亏。攻击者利用一个未授权的SWIFT操作员账号，在下午四点转走一笔资金，同时修改了临时台账。直到第二天凌晨对账时，系统才发现两个数据库的流水不一致。钱早就到了境外。

这些案例指向同一个事实：银行漏洞的修复速度，往往赶不上攻击者的学习速度。一个补丁从发现到全行部署，平均需要三到六个月。而攻击者利用公开漏洞的时间窗口，现在缩短到不到一周。更麻烦的是，很多银行的分支机构还在用Windows 7甚至XP系统，因为柜面外设的驱动只兼容老版本。你没法要求一个每天处理几百笔存取款的柜员去理解“永恒之蓝”是什么。

我个人观察，银行安全最大的悖论在于：越是不影响客户体验的漏洞，越容易被忽略。比如某个查询接口没有做越权校验，攻击者能查到别人的账户余额。这不算“资金损失”，所以优先级排得很低。但正是这种低危漏洞，往往成为攻击者拼图的最后一块。2017年，一个黑客团队就是先用一个越权漏洞拿到了客户信息，再结合社工库里的密码，撞开了网银账户。银行直到资金被转走，才回头去修那个“不重要”的查询接口。

漏洞不会消失。系统越复杂，接口越多，逻辑越绕，藏污纳垢的地方就越多。银行能做的，不是追求零漏洞，而是让漏洞被利用的成本高到攻击者觉得不划算。可惜，大多数时候，他们连这个都没做到。