Executive brief
Apache Camel's NATS messaging component fails to filter inbound message headers, allowing a client that can publish to a NATS subject to inject arbitrary Camel control headers (such as CamelHttpUri, CamelFileName, or CamelSqlQuery). An attacker exploiting this can redirect HTTP requests, modify file names, override SQL queries, or manipulate other downstream behavior depending on the route configuration. This is particularly dangerous because these injected headers persist across internal message hops and require no authentication when the NATS server uses default settings.
Technical details
The camel-nats component maps inbound NATS message headers into the Camel Exchange without proper filtering. The DefaultHeaderFilterStrategy used in NatsConfiguration lacks inbound filtering rules (no inFilter, inFilterPattern, or inFilterStartsWith configured), causing NatsConsumer to copy all NATS message headers unmodified, including internal Camel control headers. A remote attacker able to publish to the consumed NATS subject can inject arbitrary Camel control headers such as CamelHttpUri, CamelFileName, or CamelSqlQuery that influence downstream producer behavior—for example, redirecting HTTP requests, changing file output paths, or overriding SQL queries. These injected headers persist across internal routing hops (direct, seda, vm). The vulnerability is reachable without credentials when the NATS server is configured without authentication (the default). NATS message headers require NATS 2.2 or later. The fix introduces a dedicated NatsHeaderFilterStrategy that filters the Camel* / camel* header namespace case-insensitively on inbound mapping, preventing client-supplied control headers from being copied into the Exchange.
Affected products
- Apache Camel 4.0.0 to 4.14.7, 4.15.0 to 4.18.2, 4.19.0 to 4.20.x (camel-nats component)
Timeline
- 2026-07-06: disclosed: Vulnerability published to GitHub Advisory Database
- 2026: patched: Fixed in Apache Camel 4.14.8, 4.18.3, and 4.21.0