CVE-2026-46726: Apache Camel Vertx Websocket: The inbound consumer maps externally-supplied WebSocket query and path parameters into the Exchange without a HeaderFilterStrategy, allowing injection of Camel control headers

Published Jul 5, 2026
·
Updated

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.HTTPURI) - 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.

Affected Software

4 affected components
Apache Camel>4.0.0<=4.14.8, >4.15.0<=4.18.3, >4.19.0<4.21.0
Apache Camel>=4.0.0<4.14.8
Apache Camel>=4.15.0<4.18.3
Apache Camel>=4.19.0<4.21.0

Remediation

Recommended actions to resolve this vulnerability, in priority order.

  1. Upgrade

    Upgrade Apache Camel (camel-vertx-websocket) to a version that resolves this vulnerability.

    Fixed in 4.14.8
  2. Upgrade

    Upgrade Apache Camel (camel-vertx-websocket) to a version that resolves this vulnerability.

    Fixed in 4.18.3
  3. Upgrade

    Upgrade Apache Camel (camel-vertx-websocket) to a version that resolves this vulnerability.

    Fixed in 4.21.0
  4. Configuration

    For deployments that cannot upgrade immediately, strip Camel control headers from the inbound WebSocket message before any downstream producer by adding removeHeaders('Camel*') and removeHeaders('camel*') at the start of the route.

    Apache Camel route (Vertx WebSocket consumer -> downstream HTTP producer) removeHeaders('Camel*') and removeHeaders('camel*') at the start of the route = removeHeaders('Camel*'); removeHeaders('camel*')
  5. Configuration

    Require authentication on the WebSocket endpoint so an unauthenticated remote attacker cannot reach the vulnerable inbound consumer.

    Vertx WebSocket endpoint authentication requirement = required
  6. Compensating control

    Avoid bridging an untrusted WebSocket consumer directly into an HTTP producer whose target URI can be driven from message headers (so injected Camel control headers cannot redirect downstream HTTP requests).

Event History

Jul 6, 2026
CVE Published
via MITRE·08:05 AM
Data Sourced
via MITRE·08:05 AM
DescriptionWeakness
Data Sourced
via Red Hat·09:02 AM
DescriptionSeverityAffected Software
Data Sourced
via NVD·09:16 AM
DescriptionSeverityWeaknessAffected Software
Free Weekly Intel

Don't miss critical vulnerabilities

Join thousands of security professionals who receive our weekly digest of trending CVEs, zero-days, and exploited vulnerabilities.

No spam. Unsubscribe anytime.

Frequently Asked Questions

1

What is the severity of CVE-2026-46726?

The severity of CVE-2026-46726 is rated as high with a CVSS score of 7.5.

2

How do I fix CVE-2026-46726?

To fix CVE-2026-46726, ensure that the WebSocket inbound consumer uses a HeaderFilterStrategy to prevent injection of Camel control headers.

3

What type of vulnerabilities does CVE-2026-46726 include?

CVE-2026-46726 includes vulnerabilities related to improper input validation, exposure of sensitive information, and server-side request forgery (SSRF).

4

Which software is affected by CVE-2026-46726?

CVE-2026-46726 affects the Apache Camel software, specifically the Vertx Websocket component.

5

What can attackers do with CVE-2026-46726?

Attackers can exploit CVE-2026-46726 to inject Camel control headers, potentially leading to unauthorized access and manipulation of the Camel Exchange.

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203