CVE-2025-27636
Apache Camel 3.10.0 – 3.22.4
Raw vector
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:LSummary
CVE-2025-27636 is a medium-severity Improper Handling of Case Sensitivity (CWE-178) vulnerability in Apache Camel. Its CVSS base score is 5.6 (Medium).
Operationally, exploitation aligns with the MITRE ATT&CK technique Masquerading (T1036); ranked in the top 0.4% of CVEs by exploit likelihood; it is not currently listed in the CISA KEV catalog; a public proof-of-concept is referenced.
The strongest mitigations our analysis identified map to AC-24 (Access Control Decisions) and AC-3 (Access Enforcement) — see the control section below for these in your framework.
Deeper analysis AI-assisted summary
Synthesised by an AI model from the NVD description and linked references — a reading aid, not an authoritative source.
CVE-2025-27636 is a bypass and injection vulnerability in the default incoming header filter of Apache Camel, affecting versions 4.10.0 through 4.10.1, 4.8.0 through 4.8.4, and 3.10.0 through 3.22.3. The flaw stems from the filter only blocking headers starting with "Camel", "camel", or "org.apache.camel.", enabling attackers to inject Camel-specific headers with case variations that alter component behaviors. Vulnerable components using the default filter include camel-bean, camel-jms, camel-exec, and others such as camel-activemq, camel-http, camel-jetty, camel-kafka, camel-netty-http, camel-platform-http, camel-servlet, camel-undertow, and more.
Attackers can exploit this remotely with no privileges by injecting malicious headers through protocols like HTTP into Camel applications directly exposed to the internet. For instance, HTTP components such as camel-servlet, camel-jetty, camel-undertow, camel-platform-http, and camel-netty-http are vulnerable out-of-the-box, allowing attackers to forge header names that cause camel-bean to invoke unintended methods on beans, camel-jms to redirect messages to different queues on the same broker, or similar manipulations in camel-exec. The CVSS v3.1 base score is 5.6 (AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:L), reflecting moderate impact with high attack complexity.
Apache Camel advisories recommend upgrading to fixed versions: 4.10.2 for the 4.10.x LTS branch, 4.8.5 for 4.8.x LTS, and 3.22.4 for 3.x releases. As a workaround, applications can mitigate by removing suspicious headers in Camel routes using the removeHeaders EIP to filter variations like "cAmel" or "cAMEL", or generally stripping headers not starting with the protected prefixes; this can be applied globally or per route. Details are available in the official advisory at https://camel.apache.org/security/CVE-2025-27636.html and related JIRA ticket CAMEL-21828.
EU & UK References
- 🇪🇺 ENISA EUVD: EUVD-2025-6662
Vulnerability Data
Bypass/Injection vulnerability in Apache Camel components under particular conditions. This issue affects Apache Camel: from 4.10.0 through <= 4.10.1, from 4.8.0 through <= 4.8.4, from 3.10.0 through <= 3.22.3. Users are recommended to upgrade to version 4.10.2 for 4.10.x LTS,…
more
4.8.5 for 4.8.x LTS and 3.22.4 for 3.x releases. This vulnerability is present in Camel's default incoming header filter, that allows an attacker to include Camel specific headers that for some Camel components can alter the behaviours such as the camel-bean component, to call another method on the bean, than was coded in the application. In the camel-jms component, then a malicious header can be used to send the message to another queue (on the same broker) than was coded in the application. This could also be seen by using the camel-exec component The attacker would need to inject custom headers, such as HTTP protocols. So if you have Camel applications that are directly connected to the internet via HTTP, then an attacker could include malicious HTTP headers in the HTTP requests that are send to the Camel application. All the known Camel HTTP component such as camel-servlet, camel-jetty, camel-undertow, camel-platform-http, and camel-netty-http would be vulnerable out of the box. In these conditions an attacker could be able to forge a Camel header name and make the bean component invoking other methods in the same bean. In terms of usage of the default header filter strategy the list of components using that is: * camel-activemq * camel-activemq6 * camel-amqp * camel-aws2-sqs * camel-azure-servicebus * camel-cxf-rest * camel-cxf-soap * camel-http * camel-jetty * camel-jms * camel-kafka * camel-knative * camel-mail * camel-nats * camel-netty-http * camel-platform-http * camel-rest * camel-sjms * camel-spring-rabbitmq * camel-stomp * camel-tahu * camel-undertow * camel-xmpp The vulnerability arises due to a bug in the default filtering mechanism that only blocks headers starting with "Camel", "camel", or "org.apache.camel.". Mitigation: You can easily work around this in your Camel applications by removing the headers in your Camel routes. There are many ways of doing this, also globally or per route. This means you could use the removeHeaders EIP, to filter out anything like "cAmel, cAMEL" etc, or in general everything not starting with "Camel", "camel" or "org.apache.camel.".
- CWE(s)
Related Threats
MITRE ATT&CK Enterprise Techniques
CVEs Like This One
Affected Assets
Mitigating Controls
Mitigating Controls (NIST 800-53 r5) AI
Applying access control decisions to each request depends on accurate property determination that accounts for case differences.
Correct enforcement of authorizations for resource access structurally requires consistent case-sensitive handling of identifiers to avoid incorrect decisions.
Mitigating Controls (NIST CSF 2.0) AI
Derived directly from the weakness types (CWEs) cited in the NVD entry via our AI-authored CWE→CSF cross-walk (authority under review) — links open the control.
Secure SDLC practices can catch and prevent case-sensitivity flaws during code review or testing, but fixing one CWE achieves negligible coverage of the broad control.
Mitigating Controls (ISO/IEC 27001:2022 Annex A) AI
Derived directly from the weakness types (CWEs) cited in the NVD entry via our AI-authored CWE→ISO cross-walk (authority under review) — links open the control.
Secure SDLC practices should include case-sensitivity requirements in design and coding standards.
Application security requirements must specify case handling for identifiers and paths.
Architecture principles should enforce canonical, case-aware resource naming.
Secure coding guidelines must mandate explicit case handling to prevent inconsistent lookups.
Access-control rules that ignore case can allow unintended resource access.
Authentication logic must treat identifiers consistently to avoid bypass via case differences.