漏洞名称

凌晨三点，漏洞名某电商平台的漏洞名数据库管理员被手机震醒。告警短信显示：用户表异常批量导出，漏洞名总计四百七十万条记录。漏洞名他揉着眼睛登录服务器，漏洞名发现攻击者用的漏洞名居然是一个三个月前就公开的漏洞——CVE-2024-21762，一个存在于Apache Struts2框架里的漏洞名OGNL表达式注入点。补丁早就发了，漏洞名公司运维群里也转过公告，漏洞名但没人想到生产环境还跑着老版本。漏洞名

这个漏洞的漏洞名原理说穿了很简单。Struts2在处理某些HTTP参数时会调用OGNL表达式求值，漏洞名如果开发者没有严格过滤用户输入，漏洞名攻击者就能在参数里塞一段精心构造的漏洞名表达式，让服务器执行任意命令。漏洞名不是0day，不是内核级攻击，甚至不需要什么高深技巧——网上随便搜搜就有现成的POC脚本。可它就是能打穿那些“以为没人会注意到”的角落。

我见过太多这样的案例。去年帮一家制造业客户做渗透测试，他们的ERP系统用的是Tomcat 8.0.24，一个2015年就停止维护的版本。系统管理员跟我说：“这服务器在内网，外网访问不到，应该没事吧？”结果我通过他们办公区的Wi-Fi，绕过防火墙直接连到了那台服务器——因为有人把ERP的管理端口映射到了公网，只为了出差时能远程查库存。CVE-2017-12615，Tomcat的PUT方法任意文件写入漏洞，三分钟就拿到了webshell。

漏洞这东西有个反直觉的特性：越老的漏洞，往往越致命。不是因为老漏洞技术含量高，而是因为系统里藏着太多“历史遗留”的代码。新系统上线时没人记得清理旧组件，员工离职后他部署的服务没人接手维护，供应商提供的第三方库从未被纳入版本管理——这些角落里堆满了“技术债”，而漏洞就是债务的利息。

有个安全圈的老前辈跟我说过一句话，我一直记着：“漏洞不是黑客发现的，是系统自己暴露的。”想想确实如此。每次漏洞爆发，真正被攻击的往往不是那些用了最新版本的公司，而是那些连资产清单都列不全的团队。他们不知道自己有哪些服务器，不知道每台服务器上跑着什么软件，更不知道这些软件存在什么已知问题——这种情况下，哪怕漏洞公开十年，对他们来说依然是“未知的0day”。

前阵子Log4j2的漏洞（CVE-2021-44228）闹得沸沸扬扬时，我认识的一个安全工程师在客户现场连续干了三天三夜。他说最崩溃的不是修漏洞本身，而是客户根本说不清自己有多少个应用用了Log4j2。有人从网上下载了个开源项目，里面嵌了老版本的Log4j，然后这个项目又被其他三个系统引用——最后他们不得不用网络流量分析来反向排查哪些服务器在往外发奇怪的DNS请求。

写到这里，我想起那个被凌晨电话吵醒的数据库管理员。他后来告诉我，修复过程其实只花了二十分钟——升级Struts2到最新版，重启服务。但接下来的两周，他都在做同一件事：梳理公司所有系统的组件清单，建立版本台账，配置自动扫描工具。他说：“漏洞本身不可怕，可怕的是你永远不知道自己还有多少个漏洞等着被触发。”

这大概就是漏洞的本质——它像一面镜子，照出的是系统管理上的疏漏，而非技术上的短板。补丁永远追着漏洞跑，但如果你连自己有什么都不知道，这场追逐赛就根本没法开始。