Critical vulnerability under “massive” attack imperils high-impact sites - Ars Technica OpenForum
与 Windows 缺陷或 OpenSSL 缺陷不同，Struts 不是操作系统或 Linux 发行版提供的系统库。使用操作系统库，维护相对简单：您点击 Windows Update 或运行 apt-get update，或者您的平台的任何情况，并安装固定库。快速重启以重新启动应用程序，一切顺利；您的所有软件现在都在使用库的固定版本，您可以继续前进。
相反，Struts 是一个与应用程序捆绑在一起的库. 通常，系统上每个使用 Struts 的 Web 应用程序都会嵌入它自己的 Struts JAR 副本。从技术上讲，这不是绝对必要的。原则上，您可以将 Struts JAR 放在共享的 JBoss/Tomcat/Websphere/etc 中。位置并让每个部署的应用程序使用类路径中的共享 JAR，但由于这会导致版本控制问题，因此很少这样做。这意味着更新 Struts 不在典型 IT 部门的控制范围内；系统管理员无法解决此问题。相反，他们必须让应用程序开发人员参与进来。
一个组织可能有数十个或数百个使用 Struts 的小型 Web 应用程序，所有应用程序都嵌入了自己的 Struts JAR。其中许多应用程序可能基本上被放弃了；最早受影响的 Struts 版本是在 2012 年 10 月发布的，我敢打赌，从那时起开发的许多应用程序都“完成”了。它们仍在使用和部署，但没有得到持续维护；他们的开发人员已经转移到其他项目，甚至其他公司。
修复这些应用程序意味着获取源代码，更新构建脚本以将 Struts 依赖项更改为最新版本（2.3.32 或 2.5.10.1），然后重新构建应用程序。对于当前开发的代码，这可能很容易，但对于一个已经有一段时间没有接触过的三年前的应用程序呢？就是有点毛。您可能不得不挖掘旧的 JDK 版本来构建它，找到一个旧的内部 JAR 的旧副本，该副本不知何故丢失了，当您尝试重建旧应用程序时会发生所有常见问题。当然，这是假设您拥有源代码和构建脚本，而仅此一项还远远不能保证。我敢打赌，会有开发人员发现源代码控制中的版本由于某种原因与部署的版本不完全匹配，
因此，您的开发人员必须更新他们的 Maven 或 gradle 或（上帝保佑）Ant 构建脚本并增加 Struts 依赖项的版本号以获取新版本。
然后你必须希望没有任何东西被破坏。如果您使用的是 Struts 2.3.5，那么理论上 Struts 2.3.32 不会破坏任何东西。理论上它只是错误修复和安全更新，因为major.minor 版本没有改变。理论上。
在实践中，我认为任何没有 QA 周期的从 2.3.5 到 2.3.32 的开发人员都非常勇敢，或者非常鲁莽，或者两者兼而有之。当然，您将进行单元测试（也许），但您可能需要部署到您的 QA 环境中并进行某种集成测试。当然，这是假设您有一个兼容的 QA 环境，您可以在其中部署旧的、可能已废弃的应用程序。
然后，您必须安排更新应用程序的实际部署。如果应用程序是面向世界的，那可能意味着延迟到周末或晚上或类似时间。
所有这一切都假设您的开发人员甚至知道这个问题。对于 IT 而言，确定哪些应用程序正在使用哪些版本的 Struts 并不是（必然）超级简单，因此 IT 很可能不知道。无论如何，开发人员很可能不会跟踪这些东西。十多年前，当我在编写 Java 时，Struts 被认为是过时和落后的；我敢说它现在更不性感了。因此，您的开发人员可能取消了 Struts 邮件列表的订阅，并且可能没有阅读每个新 Struts 版本的发行说明。他们已经转向更好、更新的框架。
这种错误是 IT 将难以识别的问题，并且 IT 无法自行修复。开发人员很可能不知道该缺陷，但开发人员和 QA 将负责修复它。像这样的问题不可能在 48 小时内引起任何广泛的反应。轮子只是没有转得那么快。这是一个毛茸茸的大混乱。