CVE-2026-55993

Analyzed Analyzed - Analysis Complete

Server-Side Request Forgery in Apache Camel

Publication date: 2026-07-06

Last updated on: 2026-07-09

Assigner: Apache Software Foundation

Description

Improper Input Validation, Exposure of Sensitive Information to an Unauthorized Actor, Server-Side Request Forgery (SSRF) vulnerability in Apache Camel in Atmosphere Websocket Component. The camel-atmosphere-websocket consumer mapped inbound WebSocket query parameters into the Camel Exchange header map without applying any HeaderFilterStrategy (WebsocketConsumer.sendEventNotification() iterates the query-string map collected in WebsocketConsumer.service() and copies each entry into the Exchange). 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 consumer apply the HeaderFilterStrategy it already inherits from the HTTP/servlet stack, filtering 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.

CVSS Scores

EPSS Scores

Probability:
Percentile:

Meta Information

Published

2026-07-06

Last Modified

2026-07-09

Generated

2026-07-26

AI Q&A

2026-07-06

EPSS Evaluated

2026-07-25

NVD

CVE-2026-55993

EUVD

EUVD-2026-41849

Affected Vendors & Products

Vendor	Product	Version / Range
apache	camel	From 4.0.0 (inc) to 4.14.8 (exc)
apache	camel	From 4.15.0 (inc) to 4.18.3 (exc)
apache	camel	From 4.19.0 (inc) to 4.21.0 (exc)

Helpful Resources

Exploitability

CWE

KEV

CWE ID	Description
CWE-918	The web server receives a URL or similar request from an upstream component and retrieves the contents of this URL, but it does not sufficiently ensure that the request is being sent to the expected destination.
CWE-200	The product exposes sensitive information to an actor that is not explicitly authorized to have access to that information.
CWE-20	The product receives input or data, but it does not validate or incorrectly validates that the input has the properties that are required to process the data safely and correctly.

Attack-Flow Graph

Executive Summary

CVE-2026-55993 is a security vulnerability in the Apache Camel camel-atmosphere-websocket component. It occurs because the WebSocket consumer maps inbound query parameters directly into the Camel Exchange header map without filtering. This allows an attacker to inject Camel control headers, such as CamelHttpUri, by supplying them as query parameters.

When the WebSocket consumer is connected to a downstream HTTP producer, the injected CamelHttpUri can redirect server-side HTTP requests to attacker-chosen destinations, enabling server-side request forgery (SSRF). Additionally, the HTTP producer resolves property placeholders in the attacker-controlled URI, which can expose sensitive information like environment variables, application properties, and vault secrets.

This vulnerability can be exploited by an unauthenticated remote attacker if the WebSocket endpoint is exposed without authentication.

Detection Guidance

Detection of this vulnerability involves monitoring WebSocket endpoints for inbound query parameters that include Camel control headers such as CamelHttpUri or other headers starting with 'Camel' or 'camel'. Since the vulnerability arises from these headers being mapped into the Camel Exchange without filtering, inspecting WebSocket requests for such headers can indicate potential exploitation attempts.

While no specific commands are provided in the available resources, a general approach would be to capture and analyze WebSocket traffic to identify query parameters containing Camel control headers. For example, using network traffic capture tools like tcpdump or Wireshark to filter WebSocket upgrade requests and subsequent messages, or using application-level logging to record inbound WebSocket query parameters.

Use tcpdump or tshark to capture WebSocket traffic on the relevant port, e.g., `tcpdump -i eth0 port 80 or port 443 -w capture.pcap`.
Analyze captured traffic with Wireshark or tshark to filter WebSocket handshake requests and inspect query parameters for headers starting with 'Camel' or 'camel'.
Enable detailed logging in Apache Camel to log inbound WebSocket query parameters and check for suspicious Camel header injections.

For immediate mitigation, users are advised to upgrade to fixed versions or strip Camel headers from inbound messages, which also helps prevent exploitation.

Impact Analysis

This vulnerability can have serious impacts including unauthorized exposure of sensitive information and server-side request forgery (SSRF).

Attackers can redirect server-side HTTP requests to internal services or cloud metadata endpoints, potentially accessing restricted resources.
Sensitive data such as environment variables, application properties, and vault secrets can be disclosed to attackers due to the resolution of property placeholders in attacker-controlled URIs.
If the WebSocket endpoint is exposed without authentication, attackers can exploit this vulnerability remotely without any credentials.

Compliance Impact

This vulnerability allows unauthorized exposure of sensitive information such as environment variables, application properties, and vault secrets to attackers via server-side request forgery (SSRF). Such exposure of sensitive data can lead to non-compliance with data protection regulations like GDPR and HIPAA, which require strict controls over the confidentiality and integrity of sensitive information.

If the WebSocket endpoint is exposed without authentication, an unauthenticated remote attacker can exploit this vulnerability, increasing the risk of unauthorized data access and potential data breaches.

Therefore, organizations using affected Apache Camel versions may face compliance risks unless they apply the recommended fixes or mitigations, such as upgrading to patched versions, enforcing authentication, and filtering headers to prevent sensitive data leakage.

Mitigation Strategies

To mitigate this vulnerability immediately, users should upgrade Apache Camel to a fixed version: 4.14.8, 4.18.3, or 4.21.0 depending on their release stream.

If upgrading immediately is not possible, apply the following mitigations:

Strip Camel control headers from inbound messages before they reach any downstream HTTP producer by removing headers matching 'Camel*' and 'camel*' at the start of the route.
Require authentication on the WebSocket endpoint to prevent unauthenticated remote attackers from exploiting the vulnerability.
Avoid bridging an untrusted WebSocket consumer directly into an HTTP producer whose target URI can be influenced by message headers.

Hi! I’m here to help you understand CVE-2026-55993. Ask me anything about the vulnerability, its impact, or mitigation strategies.

0/70