CVE-2026-46726 in Camel
Summary
by MITRE • 07/06/2026
Improper Input Validation, Exposure of Sensitive Information to an Unauthorized Actor, Server-Side Request Forgery (SSRF) vulnerability in Apache Camel in Vertx Websocket component.
The camel-vertx-websocket consumer mapped inbound WebSocket query and path parameters into the Camel Exchange header map without applying any HeaderFilterStrategy (VertxWebsocketConsumer.populateExchangeHeaders()). Because nothing blocked the Camel header namespace, a client connecting to the WebSocket endpoint could set Camel-internal control headers - including CamelHttpUri (Exchange.HTTP_URI) - simply by supplying them as query parameters. In a route where the WebSocket consumer feeds a downstream HTTP producer, the injected CamelHttpUri redirects the server-side HTTP request to an attacker-chosen destination (server-side request forgery - for example to an internal service or a cloud metadata endpoint). In addition, the HTTP producer resolves Camel property placeholders on the resulting (attacker-controlled) URI, so placeholders embedded in the injected value - such as an environment-variable reference, an application property, or a vault reference - are resolved to their real values and sent to the attacker, disclosing environment variables, application properties and vault secrets. When the WebSocket endpoint is exposed without authentication, this is reachable by an unauthenticated remote attacker. This issue affects Apache Camel: from 4.0.0 before 4.14.8, from 4.15.0 before 4.18.3, from 4.19.0 before 4.21.0.
Users are recommended to upgrade to version 4.21.0, which fixes the issue. If users are on the 4.14.x LTS releases stream, then they are suggested to upgrade to 4.14.8. If users are on the 4.18.x releases stream, then they are suggested to upgrade to 4.18.3. The fix makes the affected consumers apply a HeaderFilterStrategy that filters the Camel header namespace case-insensitively on inbound mapping, so externally-supplied Camel* / camel* headers are no longer copied into the Exchange. For deployments that cannot upgrade immediately, strip the Camel control headers from the inbound message before they reach any downstream producer (for example removeHeaders('Camel*') and removeHeaders('camel*') at the start of the route), require authentication on the WebSocket endpoint, and avoid bridging an untrusted consumer directly into an HTTP producer whose target URI can be driven from message headers.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 07/06/2026
The vulnerability described represents a critical security flaw in Apache Camel's Vertx Websocket component that combines multiple serious issues including improper input validation, exposure of sensitive information, and server-side request forgery. This flaw stems from the VertxWebsocketConsumer's failure to implement proper header filtering when mapping inbound WebSocket query and path parameters into the Camel Exchange header map. The absence of a HeaderFilterStrategy allows malicious clients to inject internal Camel control headers directly through query parameters, creating an attack vector that can be exploited by unauthenticated remote attackers.
The technical implementation of this vulnerability occurs through the VertxWebsocketConsumer.populateExchangeHeaders() method which indiscriminately maps all inbound WebSocket parameters without filtering out Camel-specific headers. When a client supplies a CamelHttpUri parameter in the WebSocket query string, this value gets injected into the Exchange HTTP_URI header, enabling an attacker to redirect HTTP requests to arbitrary destinations. This creates a classic server-side request forgery scenario where internal services or cloud metadata endpoints become accessible to external attackers. The vulnerability is particularly dangerous because it leverages the existing Camel routing infrastructure to create unauthorized network access patterns.
The exposure of sensitive information occurs when the injected CamelHttpUri value contains property placeholders that get resolved by the HTTP producer component. This means that environment variables, application properties, and vault secrets referenced within attacker-controlled URIs are automatically expanded and transmitted back to the attacker. The vulnerability affects multiple version streams of Apache Camel including 4.0.0 through 4.14.7, 4.15.0 through 4.18.2, and 4.19.0 through 4.20.9, making it widespread across several major releases. This issue aligns with CWE-20: Improper Input Validation and CWE-94: Improper Control of Generation of Code, while also mapping to ATT&CK techniques including T1566.002: Phishing: Spearphishing Attachment and T1071.004: Application Layer Protocol: DNS.
The security implications extend beyond simple information disclosure to include potential system compromise through internal network reconnaissance and access to sensitive backend services. Attackers can leverage this vulnerability to map internal networks, discover running services, and potentially gain access to cloud metadata services that contain credentials and configuration data. The impact is particularly severe in containerized environments or cloud deployments where internal service discovery and credential management systems are exposed through metadata endpoints. Organizations using Apache Camel's Vertx Websocket component without proper authentication mechanisms face significant risk exposure.
The recommended mitigation strategy involves upgrading to the patched versions of Apache Camel, specifically version 4.21.0 for the main release stream, or the corresponding LTS patches 4.14.8 and 4.18.3 for affected release streams. The fix implemented in these versions applies a case-insensitive HeaderFilterStrategy that prevents Camel-specific headers from being copied into the Exchange when processing inbound WebSocket messages. For organizations unable to upgrade immediately, defensive measures include implementing route-level header filtering using removeHeaders('Camel') and removeHeaders('camel') operations at the beginning of affected routes, enforcing authentication on WebSocket endpoints, and avoiding direct bridging between untrusted WebSocket consumers and HTTP producers that can be influenced by message headers. These mitigations align with security best practices for preventing information leakage and unauthorized access patterns in enterprise integration frameworks.
The vulnerability demonstrates the importance of input validation and header filtering in distributed systems where components may be exposed to untrusted inputs from external sources. It highlights how seemingly innocuous parameter mapping operations can create significant security risks when proper sanitization and filtering mechanisms are not implemented. The attack vector specifically targets the intersection of WebSocket protocol handling and Camel's internal header management, creating a unique exploitation scenario that requires careful attention to both network-level and application-level security controls.