CVE-2026-59230: Apache Camel XSS Vulnerability

CVE-2026-59230 Overview

CVE-2026-59230 is an improper input validation vulnerability [CWE-20] in the Apache Camel camel-mail component. The MimeMultipart data format copies MIME headers from incoming messages onto the Camel Exchange without applying a HeaderFilterStrategy when headersInline is set to true. A remote sender can inject headers in the Camel-internal namespace and influence downstream route behavior, such as overriding the SQL statement executed by the camel-sql producer. The vulnerability affects Apache Camel from 2.17.0 before 4.14.9, from 4.15.0 before 4.18.4, and from 4.19.0 before 4.22.0.

Critical Impact
A sender able to influence a MIME multipart message can inject Camel control headers that redirect downstream route sinks, potentially altering SQL, HTTP, or file operations performed after the unmarshal step.

Affected Products

Apache Camel 2.17.0 through 4.14.8
Apache Camel 4.15.0 through 4.18.3
Apache Camel 4.19.0 through 4.21.x (fixed in 4.22.0)

Discovery Timeline

2026-08-24 - CVE-2026-59230 published to NVD
2026-08-27 - Last updated in NVD database

Technical Details for CVE-2026-59230

Vulnerability Analysis

The camel-mail component ships a MimeMultipart data format for unmarshalling MIME multipart messages. When headersInline is enabled, the unmarshal path enumerates every MIME header on the incoming message except Message-ID, MIME-Version, and Content-Type. It calls setHeader for each remaining header on the Camel Exchange.

No HeaderFilterStrategy is applied during this copy. Header names come directly from the untrusted message. A sender can craft a MIME message containing headers whose names fall inside the Camel-internal namespace (typically prefixed with Camel).

Downstream Camel components read these control headers to override configured behavior at runtime. The camel-sql producer, for example, takes the SQL statement to execute from a Camel header when one is present. An injected header can redirect what a subsequent processor or producer does with data the route author never intended to source from the message.

The reachable sinks and impact depend entirely on the route topology after the unmarshal step. The parallel camel-mail consumer path already applied a header filter, so this fix extends the same hardening to the data format path.

Root Cause

The root cause is missing input filtering during MIME header propagation. The unmarshal routine trusts header names supplied by the remote sender and writes them directly into a namespace used for internal control signaling.

Attack Vector

The attack requires an attacker to control or influence a MIME multipart message that is unmarshalled by a Camel route configured with headersInline=true. The default value is false, so only explicitly reconfigured deployments are exposed. When the default is used, MIME headers surface as attachments rather than as Exchange headers. See the Apache Camel security advisory for technical details.

Detection Methods for CVE-2026-59230

Indicators of Compromise

Presence of MIME headers with names starting with Camel (for example CamelSqlQuery, CamelHttpUri, CamelFileName) on messages arriving from external senders.
Unexpected SQL statements, HTTP URIs, or file paths executed by Camel producers immediately downstream of a MimeMultipart unmarshal step.
Route logs showing Exchange header keys in the Camel* namespace that were not set by any preceding processor.

Detection Strategies

Inventory Camel routes that use the MimeMultipart data format and inspect each for the headersInline setting.
Enable Camel tracing or interceptors around unmarshal steps to log Exchange header names before downstream processors run.
Review application dependencies for org.apache.camel:camel-mail versions between 2.17.0 and 4.21.x that predate the fixes in 4.14.9, 4.18.4, and 4.22.0.

Monitoring Recommendations

Alert on Exchange header keys matching the Camel* prefix that originate from inbound MIME messages.
Monitor camel-sql, camel-http, and camel-file producers for statement, URI, or path values that deviate from route defaults.
Correlate mail ingestion events with downstream data store or outbound HTTP activity to identify redirection attempts.

How to Mitigate CVE-2026-59230

Immediate Actions Required

Upgrade Apache Camel to 4.22.0 on current release lines.
Upgrade to 4.14.9 for the 4.14.x LTS stream or to 4.18.4 for the 4.18.x stream.
Audit all routes for MimeMultipart unmarshal steps and confirm the value of headersInline.
Restrict MIME ingestion endpoints to trusted senders where feasible.

Patch Information

Apache has released fixed versions 4.14.9, 4.18.4, and 4.22.0. The fix applies a HeaderFilterStrategy on the MimeMultipart unmarshal path, aligning it with the existing filter already applied by the camel-mail consumer. Refer to the Apache Camel CVE-2026-59230 advisory and the OpenWall OSS-Security discussion for release details.

Workarounds

Leave headersInline at its default value of false when inline headers are not required; the vulnerable copy is only reached when it is enabled.
Where headersInline=true must remain, strip Camel-internal headers immediately after unmarshal using removeHeaders("Camel*") before any processor or producer that reads control headers.
Do not unmarshal MIME content from untrusted senders into routes that dispatch on header values.
As defense in depth, treat all header names from MIME messages crossing a trust boundary as untrusted input.

bash

# Configuration example: remove Camel-internal headers after unmarshal
from("direct:mimeIn")
  .unmarshal().mimeMultipart()
  .removeHeaders("Camel*")
  .to("sql:select * from orders where id = :#id");