Apache Camel security advisory

CVE-2026-56140

Camel-AWS2-SNS: An inbound Camel-namespace filter was added to Sns2HeaderFilterStrategy to align it with sibling components; because camel-aws2-sns is producer-only (no consumer) there is no reachable inbound header-injection path, so this is a defense-in-depth hardening change related to the camel-aws2-sqs issue CVE-2026-46456

Description

The camel-aws2-sns component filters Camel headers through a component-specific HeaderFilterStrategy, Sns2HeaderFilterStrategy. Like the sibling Sqs2HeaderFilterStrategy, it originally configured only an outbound filter (setOutFilterPattern, which blocks Camel*, breadcrumbId and org.apache.camel.* headers from being written out) and did not configure an inbound filter rule. For the related camel-aws2-sqs component this inbound gap was exploitable, because the Sqs2Consumer maps inbound SQS message attributes into the Camel Exchange via HeaderFilterStrategy.applyFilterToExternalHeaders, allowing a message sender to inject Camel control headers (tracked as CVE-2026-46456). camel-aws2-sns, by contrast, is producer-only: Sns2Endpoint does not support consumers (createConsumer throws UnsupportedOperationException, 'You cannot receive messages from this endpoint'), so no externally-supplied message attributes are ever mapped inbound into a Camel Exchange through SNS, and the missing inbound filter rule on Sns2HeaderFilterStrategy was therefore not reachable by an attacker. As part of the same fix (CAMEL-23506), an inbound filter rule (setInFilterStartsWith for the Camel namespace) was added to Sns2HeaderFilterStrategy so that its configuration matches the corrected Sqs2HeaderFilterStrategy and the other sibling strategies. This is a defense-in-depth alignment with no known exploit path in camel-aws2-sns.

Mitigation

This is a defense-in-depth hardening change with no known exploit path in camel-aws2-sns, which is producer-only, so no urgent action or workaround is required. Users who want the aligned behaviour can upgrade to version 4.21.0, or to 4.14.8 on the 4.14.x LTS releases stream, or to 4.18.3 on the 4.18.x releases stream, which contain the change. As a general best practice, operators should continue to apply least-privilege IAM permissions on their SNS topics.

Credit

This issue was reported by Yu Bao from PayPal, alongside the related camel-aws2-sqs issue (CVE-2026-46456)

Notes

The JIRA ticket: https://issues.apache.org/jira/browse/CAMEL-23506 refers to the various commits that resolved the issue, and have more details. The fix was merged on main in https://github.com/apache/camel/pull/23221 (commit 5f57258fb33d33ef99df10594f8fe9f11d7c2b7e) and backported to camel-4.18.x (commit 7b334be0419839097a132d4ff3427fc4083e695e) and camel-4.14.x (commit b7f78292e747a28dbf5da444265557b5f9f3c1a1). The change adds setInFilterStartsWith for the Camel namespace to Sns2HeaderFilterStrategy, aligning its inbound direction with the sibling component strategies (Kafka, Mail, CoAP, Google Pub/Sub, and the corrected Sqs2HeaderFilterStrategy); the existing outbound filter is unchanged. The issue is classified as CWE-20 (Improper Input Validation). Because camel-aws2-sns is producer-only and has no consumer, there is no reachable inbound header-injection path, so the practical impact is defense-in-depth only; the exploitable, consumer-side variant of this pattern is the camel-aws2-sqs issue CVE-2026-46456, with which this change shares the same fix (CAMEL-23506). It belongs to the same Camel message-header-injection family as CVE-2025-27636, CVE-2025-29891, CVE-2025-30177, CVE-2026-40453, CVE-2026-46454 and CVE-2026-47323, all of which stem from Camel components mapping inbound message headers into the Exchange without a HeaderFilterStrategy that blocks the Camel header namespace.

References

CVE-2026-56140.txt.asc — PGP signed advisory data cve.org/CVERecord?id=CVE-2026-56140