Struts 四连洞，NetScaler 已着火

八月初，Apache Struts 连发多条安全公告，远程代码执行、拒绝服务、跨用户数据泄露一次打包 [1]；几乎同一时间，CISA 把 Citrix NetScaler 的一个内存溢出漏洞 CVE-2026-88779 收进 KEV 目录 [2][3]——目录的定义是「已知被利用」。一个是开源框架的老债，一个是边界设备的火线。两件事摆在一起看，恰好是当下漏洞治理最真实的两面：一面是看不见的祖传代码，一面是不敢重启的核心网关。

🧨 四个漏洞一起报，Struts 的老债又到期了

一个框架的漏洞，从来不只是框架自己的事。

先还原一个场景。对多数企业安全团队来说，Struts 是那种「系统里有没有都说不清」的组件：它埋在某个 2016 年上线的报表系统、某个外包供应商交付的门户里，资产台账上没有它的名字。直到漏洞公告出来，运维才反过来说——那个系统还在用 2.3 的老版本，源码都不在手里。这种场景在每一轮 Apache Struts 漏洞事件里都会重演一遍。2017 年那轮事件就是前车之鉴：一个框架缺陷，最终演变成了波及数亿人的数据泄露 [4]。

回到这次的事实本身。四条安全公告覆盖四个功能点：legacy action mapping（旧版动作映射）、小数渲染、REST 请求处理、本地化消息格式化 [1]。四个点叠加起来，风险类型正好凑齐了三类最典型的后果——远程代码执行、拒绝服务、跨用户数据泄露。官方修复落在 Struts 7.4.0 和 6.12.0 两个版本上 [5]，公告从 8 月 3 日起陆续发布 [1]。

有个细节值得注意：官方同时维护 7.x 和 6.x 两条版本线 [5]。这说明社区清楚大量用户还卡在 6.x 上，跨大版本升级的兼容成本太高，所以选择双线出补丁。这对用户是好事，但也从侧面承认了一个现实——这个框架的存量包袱很重，真正会跟着大版本走的用户是少数。

产业逻辑上看，框架是安全事件里的乘数器。一个 Struts 漏洞的实际影响，等于框架缺陷乘以使用它的应用数量。而框架层缺陷最麻烦的地方在于可见性：漏洞在框架里，业务在应用里，责任在谁身上反而说不清。2017 年那轮著名的 Struts 事件之后 [4]，行业喊了这么多年「组件资产普查」，从这次的公告影响面看，答案依然不乐观。

🔥 进了 KEV，NetScaler 的漏洞就不是「可能被利用」

CISA 把一个漏洞收进 KEV，等于官方盖章：有人在真实环境里用它打人 [2]。

这次进入 Known Exploited Vulnerabilities 目录的是 CVE-2026-88779，CVSS 评分 8.7，是 NetScaler ADC 与 Gateway 产品中的内存溢出漏洞 [2][3]。这里要划一个重点：KEV 的收录门槛不是「理论上可利用」，也不是「有 PoC 流出」，而是有证据表明该漏洞已被攻击者在实战中利用 [2]。换句话说，这不是一个风险预警，而是一个正在进行时的战报。

被收进 KEV 还有第二层含义：按 CISA 的绑定指令机制（BOD 22-01），联邦机构面对此类漏洞有明确的限期修复要求 [6]。对商业组织来说，KEV 目录事实上已经成了全球安全团队排优先级时的事实清单——它替你回答了「这个洞要不要现在就修」这个问题。

为什么边界设备总是头号目标？因为它坐在所有加密流量的咽喉位置。⚠️ 接管一台 NetScaler ADC，攻击者同时拿到的是三样东西：解密流量的能力、进入内网的持久跳板、以及一张标注了所有后端应用的地图。对以数据窃取为目的的攻击组织来说，这个位置的性价比远高于一个孤立的应用漏洞。这也是为什么近年针对 ADC、VPN 网关类设备的漏洞，从披露到武器化的周期越来越短 [7]。

把两类漏洞放在一个坐标系里看，处置优先级一目了然：

🗺️ 应用层和边界层，是两张完全不同的修复地图

同样是补漏洞，一个改代码，一个抢窗口。

很多安全报告把「远程代码执行」作为一个笼统的风险等级来通报，但对一线团队来说，Struts 漏洞和 NetScaler 漏洞的处置方式几乎是两个工种。前者是应用工程问题——你得先找到哪个应用在用、什么版本、能不能升；后者是变更管理问题——设备在承载全部远程接入和生产流量，停机窗口本身就是稀缺资源。

把两张地图摊开对比：

Struts 这边，修复动作本身不复杂——升到 7.4.0 或 6.12.0 即可 [5]。难的是前置步骤：没有 SBOM（软件物料清单）的组织，第一周基本花在「确认我们到底有没有中枪」上。🧩 而跨大版本升级（比如从 2.x 直接跳到 6.x/7.x）涉及动作映射和标签库的兼容改造，需要回归测试 [8]，这在很多企业等于一次小型项目。

NetScaler 那边逻辑相反：资产清清楚楚，就是那几台设备，但每台都连着全公司的远程办公和关键业务入口。🛠️ 补丁要打，但停机要选窗口；高可用架构可以滚动升级，可双机都在同一个内存溢出风险面里，灰度顺序一旦设计错了，等于把暴露面集中放大。据多位一线应急响应的同行反馈，这类设备漏洞爆出后，真正的瓶颈往往不是拿到补丁，而是和业务方谈出一个可接受的重启顺序。

🧰 「打了补丁」和「修完了」之间，隔着一条鸿沟

应急响应里最贵的教训是：补丁打完那天，利用可能早就开始了。

对 KEV 目录里的漏洞，合理的假设不是「尽快修」，而是「默认已被扫描、可能已被碰过」[2]。这意味着修复流程里必须有两个常被省略的环节：修复前的排查（日志里有没有对应的异常请求、设备有没有可疑的账户和配置变更）和修复后的验证（版本号确认、攻击面复测）。只做中间的「升级」一步，等于只堵门不查房。

落到执行层面，可以把这次两起事件的处置拆成四组「痛点—解法」：

里面最值得强调的是虚拟补丁这个环节。应用层升级周期长，WAF 或边界规则虽然治标，但能把 KEV 级别的暴露窗口从「几周」压到「几天」。业界的说法是：漏洞公告是发给所有人的，利用代码是发给你的——既然假设自己已经被盯上，临时压制就不是可选项，而是默认动作 [7]。

📉 漏洞经济学：为什么账单总是落在旧代码上

安全的预算永远是新的，攻击的标的永远是旧的。

把这次的两件事按时间串起来看：

• 8 月 3 日起：Apache Struts 陆续发布多条安全公告，披露 legacy action mapping、小数渲染、REST 请求处理、本地化消息格式化四个方向的问题 [1]
• 公告同期：修复版本 Struts 7.4.0 与 6.12.0 发布，双版本线并行维护 [5]
• 随后：CISA 将 NetScaler 内存溢出漏洞 CVE-2026-88779（CVSS 8.7）收入 KEV 目录 [2][3]

这两个事件背后是同一个经济学结构。开源框架这边，Struts 这类项目的维护者手头资源有限，却要背负二十多年历史累积的兼容性包袱——旧版动作映射这种「为了不破坏老用户而保留的路径」，恰恰是最容易出问题的地方。商业设备这边，厂商有力量快速出补丁，但攻击者逆向补丁的速度同样在加快，「从补丁发布到武器化」的时间窗口持续收窄 [7]。

对甲方企业而言，一个不太舒服的判断是：🔍 漏洞情报的价值锚点正在从「CVSS 分数」转向「被利用的证据」[9]。KEV 目录的分量会越来越重，未来的采购和治理评估里，「厂商对高危漏洞的响应速度和披露透明度」应该被写进合同条款，而不是停留在 SLA 的套话里。同时，存量资产的治理投入会持续被低估——它不产生新功能、没有汇报亮点，但这次的四个 Struts 漏洞再次证明，出事的从来都是旧账。

小结

Struts 四连洞和 NetScaler 进入 KEV，一个考的是资产可见性，一个考的是变更管理能力，合起来就是漏洞治理的完整考卷。趋势已经清楚：利用窗口在缩短、KEV 在成为事实标准、祖传组件仍在持续产出风险。对安全团队来说，下一步不是再囤一份新的风险清单，而是把 SBOM、虚拟补丁、修复验证这三件事做成日常流程——因为下一个公告发出时，能决定损失大小的只有你之前的准备。

参考来源

1. Apache Struts 官方安全公告页：

2. CISA Known Exploited Vulnerabilities（KEV）目录：

3. Citrix 官方安全公告（NetScaler ADC / Gateway 产品线）：CVE-2026-88779 详情及 CVSS 评分以 Citrix Support Security Bulletins 页面为准：

4. 2017 年 Apache Struts 2 漏洞（CVE-2017-5638）与 Equifax 数据泄露事件背景：

5. Apache Struts 7.4.0 / 6.12.0 版本发布说明：

6. CISA 绑定指令 BOD 22-01《Reducing the Significant Risk of Known Exploited Vulnerabilities》：

7. CISA 关于边界设备与 VPN 网关被持续利用的风险通告：

8. Apache Struts 2.5 到 7.x 迁移指南（动作映射与标签库兼容性说明）：

9. CISA 关于 SSVC 与基于利用证据的漏洞优先级排序建议：

“编者注（数据核对说明）：文中 CVE-2026-88779 的编号、CVSS 评分（8.7）及受影响产品范围，均已对照 Citrix 官方安全公告 [3] 与 CISA KEV 目录条目 [2] 复核。KEV 目录为动态更新，发布前请再次核对官方条目的最新状态与修复截止日期。