CVE-2025-27636

What it actually does

This is an input-validation bypass in Apache Camel routes that accept HTTP input through camel-servlet, camel-jetty, camel-undertow, camel-platform-http, or camel-netty-http and then route the exchange to a camel-bean producer. Under those conditions, if the target bean exposes more than one method, an attacker can craft HTTP header names using case variations that bypass Camel’s default header filtering. The forged header can influence bean method selection and cause Camel to invoke a different method on the same bean than the application intended. The practical impact depends on what additional methods exist on the bean: it may result in unauthorized business actions, logic bypass, state changes, data access, or invocation of internal helper methods exposed within the same bean class.

Why it matters to the business

Applications using affected Apache Camel versions may allow unauthenticated or low-privileged HTTP callers to trigger unintended application behavior if vulnerable route and bean patterns are present. This can disrupt workflows, cause unauthorized transactions or data changes, expose sensitive information through unintended methods, or undermine application-level access controls. Although it is not listed in CISA KEV and no ransomware association is reported, the EPSS value is high, so internet-facing Camel HTTP routes should be treated as a priority for review and patching.

How an attack unfolds

An attacker first identifies an HTTP endpoint backed by an affected Apache Camel component such as servlet, Jetty, Undertow, platform-http, or netty-http. The attacker then sends requests containing specially cased Camel-related header names that are not blocked by the default header filter, for example using mixed-case variants rather than the exact blocked prefixes. If the route passes the exchange to a camel-bean producer and the bean has multiple methods, the forged header can alter the bean invocation metadata. Camel may then call another method on the same bean instead of the intended route method. The attacker repeats this with different header values and request bodies to discover callable behavior and trigger methods that perform sensitive operations, return internal data, or change application state.

How to fix it

Upgrade Apache Camel to a fixed release: 4.10.2 or later for the 4.10.x LTS line, 4.8.5 or later for the 4.8.x LTS line, and 3.22.4 or later for 3.x releases. For source-based deployments, include the upstream fix associated with Apache Camel commit 63b0ee312c7e42e8a154447d80b939b0e533aa7b or a later release containing it. For packaged Red Hat OpenShift 4.8 artifacts listed as affected, apply vendor-fixed builds such as cri-o 0:1.21.5-3.rhaos4.8.gitaf64931 for el7/el8 variants and jenkins-2-plugins 0:4.8.1646993358-1.el8 where applicable. As an immediate mitigation, remove or tightly allowlist inbound headers before camel-bean invocation. Use Camel removeHeaders or equivalent route/global filters to remove suspicious mixed-case Camel header variants and, preferably, strip all externally supplied headers except an explicit allowlist required by the route. Review routes that combine HTTP server components with camel-bean and refactor beans so externally reachable routes invoke a single explicit method rather than relying on attacker-influenced method-selection metadata.

How to confirm the fix worked

Confirm dependency versions by inspecting build manifests, SBOMs, container images, application libraries, and runtime classpaths for Apache Camel versions in the affected ranges: 4.9.0 through 4.10.1, 4.0.0-M1 through 4.8.4, and 3.10.0 through 3.22.3. Validate that deployed versions are upgraded to 4.10.2, 4.8.5, 3.22.4, or later as appropriate. Review Camel route definitions for use of camel-servlet, camel-jetty, camel-undertow, camel-platform-http, or camel-netty-http followed by camel-bean endpoints. Confirm that vulnerable routes either no longer exist, use fixed Camel libraries, or remove/allowlist inbound headers before bean invocation. Perform a controlled test by sending mixed-case Camel-style headers to the HTTP route and confirming that they are removed, ignored, or do not affect invoked bean methods. Check application behavior and logs to ensure only the intended bean method is reachable from external requests.

Typical attack path

1. Find an HTTP endpoint implemented with an affected Apache Camel HTTP component.
2. Send probe requests containing unusual mixed-case Camel-style headers.
3. Determine whether responses, errors, timing, or side effects indicate bean method-selection behavior.
4. Craft a header value that causes camel-bean to invoke a non-default or unintended method on the target bean.
5. Supply request parameters or body content compatible with the unintended method.
6. Use the invoked method to perform unauthorized actions, access data, or bypass intended application flow.
7. Repeat against other Camel routes or beans with multiple methods.

How to detect it

Investigate HTTP access logs, reverse proxy logs, WAF logs, API gateway logs, and application logs for requests containing mixed-case variants of Camel internal header names, especially against endpoints backed by Apache Camel. Focus on routes that forward HTTP exchanges to camel-bean and beans with more than one public method. Look for unusual 4xx/5xx responses, method-not-found or ambiguous-method errors, unexpected bean invocation names, conversion/type-binding errors, and business actions that do not match the intended endpoint. In application logs, search for Camel bean component errors, unexpected method names, and exceptions related to method resolution or parameter binding around suspicious HTTP requests. If tracing or audit logs record route headers, inspect whether externally supplied headers with mixed-case Camel prefixes were present. Correlate suspicious requests with subsequent state changes, unusual data access, or execution of administrative or helper methods on route beans.

• cAmel
• cAMEL
• CaMel
• CAMel
• CAmel
• caMel
• camEl
• cameL
• org.apache.camel.
• CamelBeanMethodName
• CamelBeanMultiParameterArray
• CamelBeanMethod
• CamelHttpUri
• CamelHttpUrl
• CamelHttpPath
• CamelHttpQuery
• CamelHttpMethod
• AmbiguousMethodCallException
• MethodNotFoundException
• BeanInvocation
• org.apache.camel.component.bean
• No method could be found
• Ambiguous method call
• bean method
• removeHeaders

What your security team should do

• Prioritize internet-facing or partner-facing Camel HTTP routes for immediate inventory and exposure review because the EPSS score indicates elevated likelihood of exploitation activity despite the absence of KEV listing.
• Upgrade affected Apache Camel deployments to 4.10.2, 4.8.5, 3.22.4, or later, depending on the release branch.
• Search code and route definitions for camel-servlet, camel-jetty, camel-undertow, camel-platform-http, or camel-netty-http routes that forward to camel-bean.
• Add defensive header stripping or explicit header allowlists before all camel-bean producer calls, especially for routes accepting untrusted HTTP traffic.
• Review beans reachable from Camel routes and remove, privatize, split, or otherwise protect methods that should not be invocable by external input.
• Add regression tests that send mixed-case Camel header names and verify they cannot influence bean method selection.
• Review HTTP access logs and application logs for prior requests containing mixed-case Camel-related headers or unexpected bean method invocation errors.
• Update WAF, API gateway, or reverse proxy rules to alert on suspicious Camel header variants while patching is underway.