CamelFileName）针对 Apache Camel 漏洞的可运行概念验证复现程序，该漏洞中 Tika 生产者将提交文档中解析出的每个元数据键映射为 Exchange 上的一个头，且未应用任何过滤。文档元数据是攻击者可控的内容：提供文件的一方决定其携带的元数据键。因此，精心构造的文档可以设置路由其余部分所依赖的 Exchange 头，包括 CamelFileName 等 Camel 命名空间头，下游组件使用这些头来决定内容的写入位置。这与消费者公告中的头注入属于同一类别，此处是通过解析的文件内容而非协议头实现的。
| 运行时 | 目录 | 技术栈 |
|---|---|---|
| Camel Spring Boot | camel-spring-boot/ | Spring Boot 3.5.13 + camel-tika 4.22.0（受影响；修复版本 4.22.1） |
| Camel Quarkus | camel-quarkus/ | Quarkus 3.39.0 + camel-quarkus-tika（Camel 4.22.0，受影响；修复对照 CQ 3.40.0 / Camel 4.22.1） |
两个模块均演示了受影响和修复后的行为。
攻击者提交一个 HTML 文档——HTML <meta name="..."> 属性会原样进入 Tika 的元数据，因此文档决定了头名称：
<meta name="CamelFileName" content="ATTACKER-SET-../../pwned.txt"/>
<meta name="author" content="legitimate-metadata"/>
路由就是简单的 from(...).to("tika:parse")。解析完成后，会检查 Exchange 的头部信息。
CamelFileName（Exchange.FILE_NAME）被设置为文档中攻击者提供的值。下游的文件生产者会使用这个由攻击者选择的值来决定内容写入的位置。CamelFileName 被过滤掉（不再从文档中设置），而诸如 author 之类的普通元数据仍会被映射——该过滤器仅拦截 Camel 内部命名空间。# Camel Spring Boot
cd camel-spring-boot
mvn clean package
docker compose up -d --build
curl -s http://localhost:8080/exploit/attack # affected: document sets CamelFileName; >>> PROVEN
docker compose down
# Patched control
mvn clean package -Dcamel.version=4.22.1
java -jar target/cve-2026-85249-tika-header-injection-0.0.1-SNAPSHOT.jar &
curl -s http://localhost:8080/exploit/attack # fixed: CamelFileName filtered; >>> Not exploited
# Camel Quarkus
cd camel-quarkus
mvn clean package
docker compose up -d --build
curl -s http://localhost:8080/exploit/attack # affected (Camel 4.22.0): document sets CamelFileName
docker compose down
# Patched control: CQ 3.40.0 ships Camel 4.22.1
mvn clean package -Dcamel-quarkus.version=3.40.0 -Dquarkus.platform.version=3.40.0
java -jar target/quarkus-app/quarkus-run.jar &
curl -s http://localhost:8080/exploit/attack # fixed: CamelFileName filtered
| 属性 | 值 |
|---|---|
| 组件 | camel-tika（TikaProducer.convertMetadataToHeaders） |
| CWE | CWE-20（输入验证不当） |
| 严重性 | 中危 |
| 攻击向量 | 提交的文档其解析后的元数据声明了 Camel 内部头名称（例如通过 HTML <meta name="CamelFileName">） |
| 影响 | 头注入：文档设置了路由所依赖的 Exchange 头，例如 CamelFileName，它决定下游组件将内容写入何处 |
| 受影响版本 | 从 4.0.0 起至 4.18.5 之前，从 4.19.0 起至 4.22.1 之前 |
| 修复版本 | 4.18.5、4.22.1、4.23.0 |
| JIRA | CAMEL-24423 |
| 致谢 | Claude Security Scan Tool |
公告：https://camel.apache.org/security/CVE-2026-85249.html
TikaProducer.convertMetadataToHeaders 现在会通过 HeaderFilterStrategy（配置为 inFilterStartsWith("Camel", "camel", "org.apache.camel.")，不区分大小写）对每个解析后的元数据名称进行过滤，然后再将其映射到 Exchange 上——这与消费者过滤外部发送方提供的名称的方式相同——因此文档无法声明落入 Camel 内部命名空间的元数据名称。该命名空间之外的元数据仍会被映射。
在 Tika 生产者之后、任何会依据这些头执行操作的组件之前，使用 removeHeaders("Camel*") 剥离 Camel 命名空间。
本仓库出于教育和防御目的发布：帮助 Apache Camel 用户理解该漏洞、验证自身是否受影响，并确认升级可解决该问题。构造的文档和注入的文件名均为无实际危害的本地测试样本。请勿将本材料用于您不拥有或运营的系统。