CVE-2026-59230 — camel-mail MimeMultipart 头注入（headersInline）

同一 Apache Camel 漏洞的可运行概念验证复现程序，每个运行时一个：

两者都是受影响版本（该问题已在 4.14.9 / 4.18.4 / 4.22.0 中修复），并且都展示了相同的缺陷：camel-mail 的 MimeMultipart 数据格式，在使用 headersInline=true 进行反序列化时，会将传入消息的每一个非标准 MIME 头通过 setHeader 复制到 Camel Exchange 上，且不应用任何 HeaderFilterStrategy。MIME 头名称来自不可信的消息体，因此发送方可以将头放入 Camel 内部命名空间（例如 CamelHttpUri），并使其被设置在 Exchange 上——即使路由已在 HTTP 边界剥离了 Camel* 头。下游组件随后会读取被注入的控制头（头注入 → CWE-74）。

在这些复现程序中，被注入的 CamelHttpUri 将下游 HTTP 生产者从预期的 /legit-backend 重定向到内部的 /internal/secret 端点（SSRF），直观地返回内部数据。

每个子目录都是一个独立完整的项目，包含自己的 Dockerfile、docker-compose.yml 以及提供完整细节和复现步骤的 README。简而言之，对于任意一个：

cd camel-spring-boot   # or: cd camel-quarkus
mvn clean package
docker compose up -d --build
curl -s http://localhost:8080/exploit/attack
docker compose down

受影响构建上的预期输出：

1) Benign MIME (no injected header):
     /ingest responded: LEGIT: your message was accepted
2) Malicious MIME (injected MIME header 'CamelHttpUri: http://localhost:8080/internal/secret'):
     /ingest responded: SECRET: internal_db_password=S3cr3t-INTERNAL-9f2a
>>> PROVEN: ... redirecting the HTTP producer to an internal service (SSRF): true

漏洞摘要

安全公告：https://camel.apache.org/security/CVE-2026-59230.html

修复方案

MimeMultipartDataFormat.copyNonStandardHeaders 现在会在将每个传入的 MIME 头设置到 Exchange 之前，先通过 MailHeaderFilterStrategy 对其进行处理，这与邮件消费者已经应用的入站过滤保持一致——因此来自不可信消息体的 Camel* 头会被丢弃，而不是原样复制：

// fixed
if (headerFilterStrategy.applyFilterToExternalHeaders(header.getName(), header.getValue(),
        camelMessage.getExchange())) {
    continue; // filtered
}
camelMessage.setHeader(header.getName(), header.getValue());

免责声明

本仓库发布的目的在于教育和防御：帮助 Apache Camel 用户了解该漏洞、验证自己是否受影响，并确认升级可以解决该问题。这些 payload 是良性的（重定向到本地端点）。请勿将这些材料用于您不拥有或运营的系统。