CVE-2026-84176 in Camel
Summary
by MITRE • 10/19/2026
Permissive Cross-domain Policy with Untrusted Domains vulnerability in Apache Camel Platform HTTP Vertx component.
This issue affects Apache Camel: from 4.0.0 before 4.18.5, from 4.19.0 before 4.22.1.
createCorsHandler() set Access-Control-Allow-Credentials: true outside the origin check, so the header went out on every response to a request carrying an Origin header, including responses to origins the handler had just decided not to allow. When camel.server.cors.origins is unset, the handler treats every origin as allowed and echoes the caller's own Origin back as Access-Control-Allow-Origin. Together those produce the credentialed any-origin configuration that the fetch specification refuses to express as a literal wildcard, which is precisely why reflecting the origin is the usual way around that rule. A page on any origin could therefore make credentialed cross-origin requests to the Camel endpoint and read the responses.
Upgrade to Apache Camel 4.23.0, which fixes the issue. Users on the 4.18.x LTS releases stream should upgrade to 4.18.5. Users on the 4.22.x LTS releases stream should upgrade to 4.22.1. Access-Control-Allow-Credentials is now sent only when the request origin matched an origin the operator actually configured. With no origin list the origin is still reflected, as before, but credentials are not granted, and Vary: Origin is now set whenever the origin is reflected so that a shared cache cannot serve one origin's response to another. For deployments that cannot upgrade immediately, set camel.server.cors.origins to the explicit list of origins that need access rather than leaving it unset.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 10/19/2026
The Apache Camel Platform HTTP Vertx component contains a critical cross-origin resource sharing misconfiguration vulnerability affecting versions from 4.0.0 up to but not including 4.18.5, and from 4.19.0 up to but not including 4.22.1. This flaw stems from an improper implementation of the CORS handler logic within the server component. Specifically, the function responsible for creating the cross-origin resource sharing handler sets the Access-Control-Allow-Credentials header to true before verifying whether the incoming request's Origin header matches a list of permitted origins. Consequently, this security-sensitive header is included in every response sent to any client that provides an Origin header, regardless of whether that origin has been explicitly authorized by the application configuration.
This architectural flaw results in a permissive cross-domain policy where untrusted domains can exploit credentialed requests against the vulnerable endpoint. According to web browser security specifications, such as those defined for the Fetch API, it is prohibited to use a wildcard value of asterisk for both Access-Control-Allow-Origin and Access-Control-Allow-Credentials simultaneously because this combination would allow any website to make authenticated requests on behalf of a user without restriction. To circumvent this limitation while maintaining functionality, developers often reflect the requesting origin back in the Access-Control-Allow-Origin header. However, when combined with an unconditional true value for credentials, this reflection mechanism effectively grants full cross-origin access to any domain that can initiate a request against the service.
The operational impact of this vulnerability is severe, as it enables unauthorized data exfiltration and potential session hijacking scenarios. An attacker hosting a malicious webpage on any arbitrary origin could craft JavaScript code using standard fetch or XMLHttpRequest APIs to send credentialed requests to the vulnerable Apache Camel endpoint. Because the server incorrectly responds with both reflecting the attacker's origin in Access-Control-Allow-Origin and setting Allow-Credentials to true, the browser will permit the script to read the response data. This allows attackers to access sensitive information protected by authentication cookies or HTTP headers that are automatically sent with cross-origin requests if credentials mode is set to include.
From a classification perspective, this vulnerability aligns closely with CWE-942, which describes Permissive Cross-domain Policy with Untrusted Domains, and maps to the MITRE ATT&CK technique T1506, specifically the sub-technique for Web Session Hijacking or Data Exfiltration via cross-origin requests. The failure lies in the logic flow where authentication context is not properly gated by authorization checks regarding origin validation. This represents a classic case of security controls being applied out of order or with insufficient granularity, leading to a bypass of intended access restrictions.
To remediate this issue, organizations must upgrade Apache Camel to version 4.23.0 for general users, or specifically to version 4.18.5 if operating on the 4.18.x Long Term Support release stream, and to version 4.22.1 if on the 4.22.x LTS stream. The corrected implementation ensures that Access-Control-Allow-Credentials is only included in responses when the request origin explicitly matches one of the configured allowed origins. Furthermore, the updated code sets the Vary: Origin header whenever an origin is reflected, which prevents shared caches from serving a response intended for one origin to another, thereby mitigating cache poisoning attacks related to CORS misconfigurations.
For deployments that cannot immediately upgrade due to operational constraints or compatibility requirements, a temporary mitigation strategy involves explicitly configuring the camel.server.cors.origins property with a strict whitelist of trusted origins rather than leaving it unset. Leaving this configuration empty previously caused the handler to treat all origins as allowed while still erroneously granting credentials. By defining an explicit list, administrators can restrict which domains are permitted to make requests, although they must ensure that their application logic correctly handles the credential headers only for those specific whitelisted sources if upgrading is not immediately feasible.