Detecting and Mitigating the Apache Camel Vulnerability CVE-2025-27636
Executive summary
On March 9, 2025, Apache Camel disclosed CVE-2025–27636, a vulnerability that stems from incorrect filtering of request headers that can lead to remote code execution.
This vulnerability lies in a library, creating both direct and indirect dependency and complicating detection and mitigation.
In this blog post, Akamai researchers provide in-depth details about the vulnerability, exploitation techniques, and detection strategies.
An Akamai Adaptive Security Engine Rapid Rule is automatically providing protection for Akamai App & API Protector customers.
We also provide an Akamai Guardicore Segmentation Insight query for detection.
Akamai Hunt customers who were affected have already received detailed mapping of vulnerable assets.
Introduction
On March 9, 2025, a vulnerability was fixed in Apache Camel, which is a widely used Java library. The vulnerability was addressed by Apache, and is fixed in versions 4.10.2, 4.8.5, and 3.22.4. Although initial reports claimed that the vulnerability could have a critical impact, the developer team assigned it a moderate severity level.
Despite that severity rating, it is highly recommended that you patch as quickly as possible if your environment runs the versions that are fixed. However, applications running versions 4.10.0, 4.10.1, 4.8.0 to 4.8.4, and 3.10.0 to 3.22.3 can still be affected.
To be exploited, the vulnerable application has to meet some specific prerequisites (which we will explore later in this post). Despite this, the impact could still be significant. The vulnerability is trivial to exploit and could lead to devastating results, including remote code execution.
The ubiquity of Camel, along with the embedded nature of vulnerabilities in libraries, speaks to the severity of this discovery. This blog post aims to help organizations with their response process.
We will examine the vulnerability and explain its potential impact on applications, analyze its exploitation to build detections, and tackle what is perhaps the most difficult challenge with this vulnerability and others hiding in libraries — that is, identifying the vulnerable applications.
What is Apache Camel?
Apache Camel is a widely used open source integration framework that enables seamless data exchange among different systems, applications, and cloud services. It simplifies message routing, transformation, and connectivity across diverse enterprise environments. Many organizations rely on Camel for critical business workflows, API integrations, and microservices orchestration.
Analyzing CVE-2025-27636
Apache Camel uses DefaultHeaderFilterStrategy.java to block internal headers from being forwarded externally. This prevents headers from leaking sensitive routing information that could be abused by attackers. Examples of these headers include:
- CamelHttpResponseCode
- CamelHttpUri
- CamelContextId
- org.apache.camel.SomeInternalHeader
This filtering is applied when HTTP-based components process requests, such as:
- camel-http and camel-http4 (standard HTTP processing)
- camel-rest (REST DSL handling)
- camel-cxf (Apache CXF web services)
The vulnerability stems from Camel’s incorrect filtering of request headers. Before the fix, Apache Camel used a case-sensitive filtering rule (Figure 1).
Fig. 1: Vulnerable filtering logic in Apache Camel DefaultHeaderFilterStrategy.java
This logic only matched headers that started with Camel or org.apache.camel (exactly as shown). If an attacker changed the case and used CAmelHttpUri or cAMELHttpResponseCode, for example, the header would not be filtered.
This means that an attacker could inject arbitrary headers into our requests, and have Camel forward them to internal components. It's important to note, as Apache mentions in their advisory, that the vulnerability doesn’t allow access to arbitrary internal methods, but rather only to ones that are in the same bean declared in the bean URI. This is one of the specific prerequisites for exploitation, meaning that simply running a vulnerable version of Apache Camel doesn’t automatically make an application vulnerable.
Testing the threat
To demonstrate the vulnerability, we created a sample vulnerable application that could be exploited remotely. The application listens on HTTP port 80, and upon receiving a request, uses the Camel “Exec” component to execute the whoami command and echo the result to the client.
Invoking a simple request using curl returns the expected result: being exposed to the vulnerability (Figure 2).
Fig. 2: Normal application operation that returns the result of the whoami command
As we can see in the code, the whoami command is defined statically, making the code seem relatively safe. The problems arise when we inspect the possible internal message headers supported by Exec. When we examine the CamelExecCommandExecutable header, we see that it overrides the executable defined in the static URI in the code (Figure 3).
Fig. 3: Apache Camel Exec component documentation
Apache Camel would filter out internal headers that matched the letter case, such as CamelExecCommandExecutable. However, CVE-2025–27636 would allow for a bypass of the filter by inputting CAmelExecCommandExecutable (or some other letter case difference) and would execute arbitrary commands on the server (Figure 4).
Fig. 4: Exploiting CVE-2025-27636 by including the CAmelExecCommandExecutable header
In a similar manner, we can also specify the CAmelExecCommandArgs to supply parameters to the executed command (Figure 5).
Fig. 5: Using the CAmelExecCommandArgs header to specify command-line arguments
This is a simple example that demonstrates how the exploitation of this vulnerability might look. The ability to inject arbitrary internal headers can allow attackers to compromise a variety of applications, depending on the Camel components used by the server.
How did Apache Camel address CVE-2025-27636?
The issue was addressed by forcing letter case uniformity. This removes the ability for a threat actor to manipulate the letter case to bypass the filter. For example, CAmelHttpUri becomes camelhttpuri, which now matches the filter and thus would be caught.
Introducing .toLowerCase()
The GitHub commit updated the header filtering logic in DefaultHeaderFilterStrategy.java to include toLowerCase(Locale.ENGLISH) to ensure all header names are converted to lowercase before applying the filter (Figure 6).
Fig. 6: The fix to CVE-2025-27636, implementing case-insensitive filtering
In addition to protection against the injection, the fix also maintains efficiency with an optimized check. The first check handles normal "Camel" and "camel" cases quickly. The .toLowerCase() check only runs if needed, preventing unnecessary performance costs.
Detecting vulnerable applications
Identifying every vulnerable instance of Apache Camel across a network can be challenging. Security teams must assess a wide range of assets as Apache Camel is integrated in numerous places. This can include applications in which the libraries are being used that defenders are unaware of.
The library may be present as an indirect dependency, meaning it is not explicitly included in the source code but is instead introduced through another software package. This adds a layer of complexity for detection and, of course, mitigation.
Apache Camel can often be identified within Java applications by recursively scanning directories for JAR files containing "camel" in their names. Once a Camel-related JAR file is located, its manifest file can be examined to determine the version in use.
With the extracted version, security teams can cross-reference it against Apache’s security advisory to assess potential vulnerabilities. The following versions are affected:
- 4.10.0 — vulnerable prior to 4.10.2
- 4.8.0 — vulnerable prior to 4.8.5
- 3.10.0 — vulnerable prior to 3.22.4
Automating detection
To facilitate the identification of vulnerable applications, we have developed PowerShell and Bash scripts that recursively scan directories, detect Apache Camel JAR files, and output potentially vulnerable applications. We have included options for both Windows and Linux. Affected Akamai Hunt customers have already received a detailed mapping of their vulnerable assets.
Detection with Akamai Guardicore Segmentation
For Akamai Guardicore Segmentation customers, we have built an Insight query that can identify vulnerable assets. In cases in which the query result for the file version is “Version not found,” the returned hash can be either checked in VirusTotal or through the manifest file inside the jar to get to the correct version.
Windows
WITH relevant_cwds as (
SELECT DISTINCT
proc.pid,
proc.path,
proc.cmdline,
proc.cwd,
mmap.path AS mmap_path
FROM process_memory_map AS mmap
LEFT JOIN processes AS proc USING(pid)
WHERE mmap_path LIKE "%jvm%"
UNION
SELECT DISTINCT
proc.pid,
proc.path,
proc.cmdline,
proc.cwd,
proc.path AS placeholder_path
FROM processes AS proc
WHERE proc.name IN ("java", "javaw", "java.exe", "javaw.exe")
),
RELEVANT_JAR_PATHS AS (
SELECT file.path as lib_path, cwd, cwd || '..\%\%\camel-core%.jar' AS jar_path, sha256
FROM file INNER JOIN relevant_cwds ON file.path LIKE jar_path
INNER JOIN hash on file.path = hash.path
UNION
SELECT file.path as lib_path, cwd, cwd || '..\%\camel-core%.jar' AS jar_path, sha256
FROM file INNER JOIN relevant_cwds ON file.path LIKE jar_path
INNER JOIN hash on file.path = hash.path
UNION
SELECT file.path as lib_path, cwd, cwd || '%\%\camel-core%.jar' AS jar_path, sha256
FROM file INNER JOIN relevant_cwds ON file.path LIKE jar_path
INNER JOIN hash on file.path = hash.path
)
SELECT lib_path, relevant_cwds.path as proc_path,
CASE WHEN lib_path LIKE '%camel-core-2%' OR lib_path LIKE '%camel-core-3%' OR lib_path LIKE '%camel-core-4%' THEN SUBSTR(lib_path, INSTR(lib_path, 'camel-core-') + 11, INSTR(lib_path, '.jar') - (INSTR(lib_path, 'camel-core-') + 11))
WHEN lib_path like '%camel-core.jar' THEN 'Version not found' ELSE NULL END as version, cmdline, sha256 FROM RELEVANT_JAR_PATHS
INNER JOIN relevant_cwds ON relevant_cwds.cwd = RELEVANT_JAR_PATHS.cwd
WHERE
version is not null
Linux
WITH relevant_cwds as (
SELECT DISTINCT
proc.pid,
proc.path,
proc.cmdline,
proc.cwd,
mmap.path AS mmap_path
FROM process_memory_map AS mmap
LEFT JOIN processes AS proc USING(pid)
WHERE mmap_path LIKE "%jvm%"
UNION
SELECT DISTINCT
proc.pid,
proc.path,
proc.cmdline,
proc.cwd,
proc.path AS placeholder_path
FROM processes AS proc
WHERE proc.name IN ("java", "javaw", "java.exe", "javaw.exe")
),
RELEVANT_JAR_PATHS AS (
SELECT file.path as lib_path, cwd, cwd || '/../%/%/camel-core%.jar' AS jar_path, sha256
FROM file INNER JOIN relevant_cwds ON file.path LIKE jar_path
INNER JOIN hash on file.path = hash.path
UNION
SELECT file.path as lib_path, cwd, cwd || '/../%/camel-core%.jar' AS jar_path, sha256
FROM file INNER JOIN relevant_cwds ON file.path LIKE jar_path
INNER JOIN hash on file.path = hash.path
UNION
SELECT file.path as lib_path, cwd, cwd || '/%/%/camel-core%.jar' AS jar_path, sha256
FROM file INNER JOIN relevant_cwds ON file.path LIKE jar_path
INNER JOIN hash on file.path = hash.path
)
SELECT lib_path, relevant_cwds.path as proc_path,
CASE WHEN lib_path LIKE '%camel-core-2%' OR lib_path LIKE '%camel-core-3%' OR lib_path LIKE '%camel-core-4%' THEN SUBSTR(lib_path, INSTR(lib_path, 'camel-core-') + 11, INSTR(lib_path, '.jar') - (INSTR(lib_path, 'camel-core-') + 11))
WHEN lib_path like '%camel-core.jar' THEN 'Version not found' ELSE NULL END as version, cmdline, sha256 FROM RELEVANT_JAR_PATHS
INNER JOIN relevant_cwds ON relevant_cwds.cwd = RELEVANT_JAR_PATHS.cwd
WHERE
version is not null
Mitigating with Akamai App & API Protector
On Friday, March 7, 2025, Akamai’s Threat Research Team deployed an Adaptive Security Engine Rapid Rule for App & API Protector customers:
3000911 v2 - Apache Camel (CVE-2025-27636) Attack Detected - Default Action: Deny
Customers who have Rapid Rules enabled with the default action set to “Akamai Managed” are automatically protected against this threat. Customers who are using Rapid Rules with the default action set to “Alert” should evaluate any rule triggers and set the rule action to deny.
Rapid Rule 3000911 is designed to trigger on headers that would have otherwise evaded Camel’s internal filtering logic (Figure 7). The rule will not trigger on normal Camel headers to prevent any impact to legitimate customer operations.
Fig. 7: Rapid Rule 3000911 triggering on attack payload
Observed attack traffic
The current attack payloads observed by Akamai Security Intelligence Group are only attempting to confirm the vulnerability rather than exploit it. The majority of the observed payloads are using two different strategies to confirm the vulnerability.
First, we have seen use of the CAmELDestinationOverrideUrl header name where the payload is an out-of-band (OOB) beaconing domain. This traffic is originating from a commercial vulnerability scanning vendor and the payload URL is beaconing back to their domain (Figure 8).
Fig. 8: Rapid Rule 3000911 blocking payload attempting to perform server-side request forgery
Second, we’ve seen payloads use the CAmelHttpResponseCode header in an attempt to elicit a specific HTTP response status code from the server (Figure 9). If the payload was successful, the HTTP response status code returned from the server would match the one provided in the payload.
Fig. 9: Rapid Rule 3000911 blocking payload attempting to override HTTP response status code
Finally, we have seen both of the above payloads attempt to evade detection by using simple URL encoding such as ca%4d%45%6cHttpResponseCode (Figure 10). However, these attempts are still being detected and blocked by Adaptive Security Engine.
Fig. 10: Rapid Rule 3000911 blocking obfuscated payload
Summary
Vulnerabilities within libraries not only have direct implications to applications but also can hide in unknown places, which makes their detection and mitigation extremely difficult. Not only is Apache Camel widely used, but an attacker with the correct set of tools can also leverage it to execute code remotely, which adds to the severity. It is recommended that you follow Apache’s suggested course of action and patch as quickly as possible for your environment.
The Akamai Security Intelligence Group will continue to monitor, report on, and create mitigations for threats such as these for both our customers and the security community at large. To keep up with more breaking news from the Akamai Security Intelligence Group, check out our research home page and follow us on social media.