CVE-2026-46456: Apache Camel Information Disclosure Flaw

CVE-2026-46456 Overview

CVE-2026-46456 is an improper input validation vulnerability [CWE-20] in the Apache Camel camel-aws2-sqs component. The Sqs2HeaderFilterStrategy configured only an outbound filter and omitted an inbound filter, allowing sender-supplied Camel control headers to be copied unmodified from Amazon Simple Queue Service (SQS) messages into the Camel Exchange. Any principal with sqs:SendMessage on the consumed queue can inject headers such as CamelHttpUri, CamelFileName, or CamelSqlQuery to influence downstream producers in the route. The flaw affects Apache Camel versions 4.0.0 before 4.14.8, 4.15.0 before 4.18.3, and 4.19.0 before 4.21.0.

Critical Impact
A remote, unauthenticated attacker able to send messages to a consumed SQS queue can hijack downstream Camel producers to redirect HTTP requests, overwrite files, or override SQL queries.

Affected Products

Apache Camel 4.0.0 through 4.14.7
Apache Camel 4.15.0 through 4.18.2
Apache Camel 4.19.0 through 4.20.x (before 4.21.0)

Discovery Timeline

2026-07-06 - CVE-2026-46456 published to NVD
2026-07-08 - Last updated in NVD database

Technical Details for CVE-2026-46456

Vulnerability Analysis

Apache Camel uses a HeaderFilterStrategy to control which message headers cross the boundary between Camel and external systems. The camel-aws2-sqs component defines Sqs2HeaderFilterStrategy to govern this mapping for SQS messages. The strategy correctly set an outbound filter that blocks Camel*, breadcrumbId, and org.apache.camel.* headers from being written to the broker. However, no equivalent inbound filter was configured.

When Sqs2Consumer processes an incoming SQS message, it iterates through each MessageAttribute and calls HeaderFilterStrategy.applyFilterToExternalHeaders. With no inbound rule defined, DefaultHeaderFilterStrategy treats every attribute name as unfiltered and copies it directly onto the Camel Exchange. This includes Camel-internal control headers that route logic trusts to be set only by the framework itself.

Root Cause

The root cause is missing inbound header filtering in Sqs2HeaderFilterStrategy. The class relied on the default behavior of DefaultHeaderFilterStrategy for inbound mapping, which does not block the Camel header namespace. External attribute names collide with internal control headers, breaking the trust boundary between untrusted broker input and the Camel routing engine.

Attack Vector

Any principal holding sqs:SendMessage on the consumed queue - including cross-account senders and lower-privileged in-account components - can attach arbitrary message attributes named CamelHttpUri, CamelFileName, CamelSqlQuery, or similar. When the Camel consumer reads the message, these attributes become live Exchange headers and persist across internal direct, seda, and vm hops. Downstream producers then act on the attacker-controlled values. An HTTP producer can be redirected to an attacker-controlled URL, a file producer can be forced to write to arbitrary paths, and a SQL producer can execute an attacker-supplied query. The concrete impact depends on which producers the route uses after the SQS consumer.

Detection Methods for CVE-2026-46456

Indicators of Compromise

SQS messages containing MessageAttribute names matching Camel* or camel* (for example CamelHttpUri, CamelFileName, CamelSqlQuery, CamelExecCommandExecutable).
Camel route logs showing HTTP producers connecting to unexpected external hosts or file producers writing to unexpected paths.
SQS queue access patterns from cross-account principals or IAM roles that should not require sqs:SendMessage.

Detection Strategies

Inspect SQS message attribute names at the broker or through CloudTrail data events, and alert on any attribute name beginning with Camel or camel.
Review Apache Camel version inventories for instances of camel-aws2-sqs running versions below 4.14.8, 4.18.3, or 4.21.0.
Correlate SQS SendMessage API calls with downstream producer activity to identify anomalous URI, filename, or query values entering Camel routes.

Monitoring Recommendations

Enable CloudTrail data events for SQS queues consumed by Camel and forward them to your SIEM for header-name inspection.
Monitor outbound network connections from Camel workloads for destinations that fall outside the expected allowlist.
Track IAM policy changes that grant sqs:SendMessage on Camel-consumed queues to new principals.

How to Mitigate CVE-2026-46456

Immediate Actions Required

Upgrade Apache Camel to 4.21.0, or to the LTS patch releases 4.14.8 or 4.18.3, depending on the release stream in use.
Audit all Camel routes that consume from SQS and identify downstream producers whose behavior is controlled by headers (HTTP, file, SQL, exec).
Apply least-privilege sqs:SendMessage permissions on every consumed queue resource policy and remove unnecessary cross-account access.
Add removeHeaders('Camel*') and removeHeaders('camel*') at the start of every SQS-sourced route until patching is complete.

Patch Information

The fix adds an inbound HeaderFilterStrategy rule to Sqs2HeaderFilterStrategy that filters the Camel header namespace case-insensitively during inbound mapping. Sender-supplied Camel* and camel* headers are no longer copied into the Exchange. See the Apache Camel Security Advisory for full patch details.

Workarounds

Strip Camel control headers from inbound messages by placing removeHeaders('Camel*') and removeHeaders('camel*') immediately after the from('aws2-sqs:...') step in each route.
Restrict who may send to consumed SQS queues by applying least-privilege queue resource policies scoped to specific producing principals.
Where feasible, terminate cross-account SendMessage grants on Camel-consumed queues until upgrades are deployed.

bash

# Route-level workaround (Camel DSL)
from("aws2-sqs://myQueue")
    .removeHeaders("Camel*")
    .removeHeaders("camel*")
    .to("http://downstream-service/process");