CVE-2025-27636VulnerabilityPublished 9 Mar 2025Updated 26 Feb 2026

CVE-2025-27636: Apache Camel · Bypass/Injection

Affects Apache CamelSource CVE Database V5

Not known to be exploited · 97% EPSS · CVSS 5.6 Medium · fixed in 4.10.2 : patch Apache Camel as a priority.

Data as of 25 Oct 2026, 19:02 UTC

CVSS 3.1 base score

5.6Medium

How severe the flaw is on the 0–10 CVSS scale.

EPSS: 97.0% chance of exploitation in 30 days – higher than 99% of CVEsExploit Prediction Scoring System: the likelihood attackers will use this flaw soon.
Patch: Available – fixed in 4.10.2

CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:L

Attack Vector: Network
Attack Complexity: High
Privileges Required: None
User Interaction: None
Scope: Unchanged
Confidentiality: Low
Integrity: Low
Availability: Low

Bold values are the worst case: easiest to exploit or largest impact.

Attack Vector: Network: The vulnerable component is bound to the network stack and the set of possible attackers extends beyond the other options listed, up to and including the entire Internet. Such a vulnerability is often termed 'remotely exploitable' and can be thought of as an attack being exploitable at the protocol level one or more network hops away (e.g., across one or more routers).
Attack Complexity: High: A successful attack depends on conditions beyond the attacker's control. That is, a successful attack cannot be accomplished at will, but requires the attacker to invest in some measurable amount of effort in preparation or execution against the vulnerable component before a successful attack can be expected. For example, a successful attack may require an attacker to: gather knowledge about the environment in which the vulnerable target/component exists; prepare the target environment to improve exploit reliability; or inject themselves into the logical network path between the target and the resource requested by the victim in order to read and/or modify network communications (e.g., a man in the middle attack).
Privileges Required: None: The attacker is unauthorized prior to attack, and therefore does not require any access to settings or files to carry out an attack.
User Interaction: None: The vulnerable system can be exploited without any interaction from any user.
Scope: Unchanged: An exploited vulnerability can only affect resources managed by the same security authority. In this case, the vulnerable component and the impacted component are either the same, or both are managed by the same security authority.
Confidentiality: Low: There is some loss of confidentiality. Access to some restricted information is obtained, but the attacker does not have control over what information is obtained, or the amount or kind of loss is limited. The information disclosure does not cause a direct, serious loss to the impacted component.
Integrity: Low: Modification of data is possible, but the attacker does not have control over the consequence of a modification, or the amount of modification is limited. The data modification does not have a direct, serious impact on the impacted component.
Availability: Low: Performance is reduced or there are interruptions in resource availability. Even if repeated exploitation of the vulnerability is possible, the attacker does not have the ability to completely deny service to legitimate users. The resources in the impacted component are either partially available all of the time, or fully available only some of the time, but overall there is no direct, serious consequence to the impacted component.

Definitions: FIRST CVSS v3.1 specification.

Exploitation evidence

Disclosed: evidence found.
CVE published 9 Mar 2025
Detectable: no evidence on record.
No public nuclei template indexed
Weaponised: no evidence on record.
No public exploit code indexed in Metasploit or Exploit-DB
Exploited in the wildExploited: no evidence on record.
Not in CISA KEV and no source reports exploitation
Observed by OffSeq MirageSeen by Mirage: no evidence on record.
No attack traffic recorded by OffSeq Mirage sensors

A missing step is not evidence of safety. Sources: cve.org (opens in a new tab), the Metasploit, Exploit-DB and nuclei-templates index as of 2026-10-25.

Disclosed: The CVE record is public on cve.org. Its publication is t = 0.
Detectable: A public nuclei template can find exposed instances, for defenders and attackers alike.
Weaponised: Public exploit code exists in Metasploit or Exploit-DB, or CISA SSVC reports a public proof of concept.
Exploited in the wild: CISA KEV lists it, CISA SSVC rates exploitation active, or a source reports attacks.
Observed by OffSeq Mirage: OffSeq Mirage honeypot sensors recorded attack traffic for this CVE, or found exposed hosts without attack traffic.

Moments are spaced evenly, not to scale; a dashed line marks a gap of six months or more. Deltas count from t = 0. Sources that give only a date (CISA KEV, Exploit-DB, or a time of exactly 00:00Z) read “same day” rather than hours. Metasploit modules carry the flaw’s disclosure date, not their release date, and nuclei templates carry no date, so both appear above but not on the timeline.

What to do

Affected software

Product	Affected	Fixed in
Mavenorg.apache.camel/camel-core`pkg:maven/org.apache.camel/camel-core`Other threats	Affected =3.10.0 <=3.22.3 =4.8.0 <=4.8.4 =4.10.0 <=4.10.1	Fixed in–

Check your own hosts for these packages with threat-finder (opens in a new tab), our free open-source scanner.

AI-suggested

1. Upgrade Apache Camel to the fixed versions: 4.10.2 for 4.10.x LTS, 4.8.5 for 4.8.x LTS, or 3.22.4 for 3.x releases as soon as possible. 2. If immediate upgrade is not feasible, implement explicit header filtering in Camel routes using the removeHeaders EIP to remove all headers that could be malicious, including those with case variations of "Camel" prefixes (e.g., "cAmel", "cAMEL"). 3. Apply global header filtering policies to reject or sanitize incoming headers before processing, especially on HTTP-exposed routes. 4. Restrict network access to Camel HTTP endpoints by using firewalls, API gateways, or reverse proxies to limit exposure to trusted clients only. 5. Monitor logs and message flows for unusual header names or unexpected method invocations on beans to detect exploitation attempts. 6. Conduct code reviews and security testing of Camel routes to ensure no unintended header processing or method exposure exists. 7. Educate developers and operators about this vulnerability and the importance of strict header validation and filtering in integration applications. 8. Consider implementing additional application-layer security controls such as authentication, authorization, and input validation on HTTP endpoints to reduce attack surface.

Description

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, 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.".

Impact

The vulnerability allows attackers to manipulate message routing and processing logic within Apache Camel integrations by injecting unauthorized headers. This can lead to unauthorized method invocations on application beans, potentially causing unintended application behavior or data manipulation. In messaging components like camel-jms, attackers can redirect messages to unauthorized queues, potentially causing data leakage, message interception, or denial of service by disrupting message flows. Since many Camel applications are used in enterprise integration scenarios connecting critical systems, this can compromise data integrity and confidentiality. The ability to inject headers remotely via HTTP endpoints increases the risk for internet-facing applications. Although the impact on confidentiality, integrity, and availability is rated as limited, the manipulation of business logic and message routing can have significant operational consequences, including data corruption, unauthorized access to internal systems, and disruption of service workflows. Organizations relying on Apache Camel for critical integrations, especially those exposing HTTP interfaces, face risks of targeted attacks exploiting this vulnerability to bypass security controls and alter application behavior.

Summary

CVE-2025-27636 is a vulnerability in Apache Camel's default incoming header filtering mechanism that allows an attacker to bypass intended header restrictions and inject malicious Camel-specific headers. Apache Camel is an integration framework widely used to route and transform messages across various protocols and systems. The vulnerability affects multiple versions: 3.10.0 through 3.22.3, 4.8.0 through 4.8.4, and 4.10.0 through 4.10.1. The root cause is that the default header filter only blocks headers starting exactly with "Camel", "camel", or "org.apache.camel.", ignoring case variations or other crafted header names. This allows attackers to inject headers that can alter the behavior of components such as camel-bean, camel-jms, and camel-exec. For example, in camel-bean, an attacker can cause the invocation of unintended methods on a bean, potentially leading to unauthorized actions. In camel-jms, malicious headers can redirect messages to different queues on the same broker, violating message routing policies. The vulnerability is exploitable when Camel applications expose HTTP endpoints through components like camel-servlet, camel-jetty, camel-undertow, camel-platform-http, and camel-netty-http, which accept HTTP requests from potentially untrusted sources. An attacker can send crafted HTTP headers to inject malicious Camel headers. Exploitation does not require authentication or user interaction but does require network access to the vulnerable HTTP endpoints. The CVSS v3.1 base score is 5.6 (medium), reflecting network attack vector, high attack complexity, no privileges required, no user interaction, and limited confidentiality, integrity, and availability impacts. Mitigation includes upgrading to fixed versions (4.10.2, 4.8.5, or 3.22.4) or applying header filtering in Camel routes using the removeHeaders Enterprise Integration Pattern (EIP) to remove suspicious headers, including those with case variations of "Camel" prefixes. This can be done globally or per route to prevent malicious header injection. The vulnerability affects a broad range of Camel components that use the default header filter strategy, including messaging, HTTP, cloud, and protocol adapters, increasing the attack surface.

CWE-178Improper Handling of Case Sensitivity (opens in a new tab)
Base weakness
The product does not properly account for differences in case sensitivity when accessing or determining the properties of a resource, leading to inconsistent results.
Architecture and Design · Input Validation
Avoid making decisions based on names of resources (e.g. files) if those resources can have alternate names.
Implementation · Input Validation
Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does.
Implementation · Input Validation
Inputs should be decoded and canonicalized to the application's current internal representation before being validated (CWE-180). Make sure that the application does not decode the same input twice (CWE-174).
From MITRE CWE, MITRE CAPEC and OWASP (Top 10, OpenCRE).

References

Community reviews

Loading reviews…

Exploitation evidence

What to do

Affected software

Description

AI analysisMachine-generated, updated 26 Feb 2026, 23:59 UTC

WeaknessesCWE-178

Technical details

References

Community reviews

Related threats