CVE-2025-29891

Published Mar 12, 2025

Last updated 2 years ago

CVSS medium 4.8
Apache Camel

Overview

AI description

Automated description summarized from trusted sources.

CVE-2025-29891 is a bypass/injection vulnerability that affects Apache Camel versions 4.10.0 before 4.10.2, 4.8.0 before 4.8.5, and 3.10.0 before 3.22.4. It exists in Camel's default incoming header filter, which allows attackers to include Camel-specific headers that can alter the behavior of certain Camel components, such as camel-bean or camel-exec. This vulnerability can be exploited if Camel applications are directly connected to the internet via HTTP. An attacker can include parameters in HTTP requests, either as request parameters or within the request payload, which are then translated into headers. Due to incorrect case-sensitive filtering, attackers can bypass the intended header restrictions by altering the casing of the header names (e.g., using "CAmelExecCommandExecutable" instead of "CamelExecCommandExecutable"). This allows the injection of arbitrary headers, potentially leading to the execution of internal Camel methods.

Description
Bypass/Injection vulnerability in Apache Camel. This issue affects Apache Camel: from 4.10.0 before 4.10.2, from 4.8.0 before 4.8.5, from 3.10.0 before 3.22.4. 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, or the camel-exec component. If you have Camel applications that are directly connected to the internet via HTTP, then an attacker could include parameters in the HTTP requests that are sent to the Camel application that get translated into headers.  The headers could be both provided as request parameters for an HTTP methods invocation or as part of the payload of the HTTP methods invocation. 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. This CVE is related to the CVE-2025-27636: while they have the same root cause and are fixed with the same fix, CVE-2025-27636 was assumed to only be exploitable if an attacker could add malicious HTTP headers, while we have now determined that it is also exploitable via HTTP parameters. Like in CVE-2025-27636, exploitation is only possible if the Camel route uses particular vulnerable components.
Source
security@apache.org
NVD status
Analyzed
Products
camel

Risk scores

CVSS 3.1

Type
Secondary
Base score
4.8
Impact score
2.5
Exploitability score
2.2
Vector string
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:L
Severity
MEDIUM

Weaknesses

security@apache.org
CWE-164

Social media

Hype score
Not currently trending
  1. 🚨CVE-2025–27636 & CVE-2025-29891: Apache Camel PoC affecting versions: 4.10.0-4.10.1, 4.8.0-4.8.4, 3.10.0-3.22.3. Exploitation of these vulnerabilities can enable attackers to execute internal Camel methods. GitHub: https://t.co/1H4pj4Bxb8 Advisory: https://t.co/USF4Ly

    @DarkWebInformer

    19 Oct 2025

    9147 Impressions

    17 Retweets

    87 Likes

    36 Bookmarks

    1 Reply

    0 Quotes

  2. CVE-2025-29891: Command injection vulnerability reported in Apache Camel via camel-exec routes. Impact: Unauthorized command execution via HTTP Patchable versions: 4.10.2, 4.8.5, 3.22.4 Details: https://t.co/saljhlec2m #CyberSecurity #CVE202529891 #ApacheCamel #infosec https://

    @SeReacher

    1 Sept 2025

    9 Impressions

    1 Retweet

    1 Like

    0 Bookmarks

    0 Replies

    0 Quotes

  3. Dragon Drop: NEW Releases 🚨🐉 🛡️ New GRC modules: → Cyber Compliance In Practice: https://t.co/U1cIrvaryZ → AI and Emerging Cyber GRC Trends: https://t.co/2towA6R4m8 🪲 New CVE labs: → CVE-2025-46191: https://t.co/7sXbgV6WAa → CVE-2025-29891: https://t.co/16

    @offsectraining

    14 Aug 2025

    2368 Impressions

    0 Retweets

    7 Likes

    3 Bookmarks

    0 Replies

    0 Quotes

  4. CVE-2025-29891 – #Apache #Camel #Exploit via #CAmelExecCommandArgs #Header_Injection https://t.co/2HKRoLrid2 https://t.co/b47rn23uxP

    @omvapt

    9 Aug 2025

    46 Impressions

    0 Retweets

    0 Likes

    0 Bookmarks

    0 Replies

    0 Quotes

  5. Deep Dive: CVE-2025-29891 (Apache Camel Header Injection) ⚠️ CVSS 4.8 | EPSS 0.24% See how the exploit works and how to secure your routes!

    @offsectraining

    8 Aug 2025

    2981 Impressions

    4 Retweets

    17 Likes

    6 Bookmarks

    1 Reply

    0 Quotes

  6. Deep Dive: CVE-2025-29891 (Apache Camel Header Injection) ⚠️ CVSS 4.8 | EPSS 0.24% See how the exploit works and how to secure your routes: https://t.co/1tSOzRlTBL

    @offsectraining

    8 Aug 2025

    1 Impression

    0 Retweets

    0 Likes

    0 Bookmarks

    0 Replies

    0 Quotes

  7. CVE-2025-29891 – Apache Camel Exploit via CAmelExecCommandArgs Header Injection https://t.co/aB2fWr3aUr

    @evanderburg

    8 Aug 2025

    64 Impressions

    0 Retweets

    0 Likes

    0 Bookmarks

    0 Replies

    0 Quotes

  8. CVE-2025-29891 – Apache Camel Exploit via CAmelExecCommandArgs Header Injection https://t.co/Ex3sNiPKrV

    @DemolisherDigi

    8 Aug 2025

    25 Impressions

    0 Retweets

    0 Likes

    0 Bookmarks

    0 Replies

    0 Quotes

  9. This article delves into security risks posed by unpatched Apache Tomcat and Camel instances. We present an in-depth analysis of CVE-2025-24813 and CVE-2025-27636 and CVE-2025-29891 as well as findings from our telemetry (including exploit payloads). https://t.co/FogfF5t2xU https

    @Unit42_Intel

    15 Jul 2025

    4223 Impressions

    22 Retweets

    62 Likes

    14 Bookmarks

    0 Replies

    0 Quotes

  10. 【脆弱性分析】Apacheが提供する主要製品に深刻な脆弱性が相次いで発見された。TomcatのCVE-2025-24813と、CamelのCVE-2025-27636、CVE-2025-29891の3つが2025年3月に公開され、いずれもリモートコード実行を可能にする。 Tom

    @nakajimeeee

    5 Jul 2025

    264 Impressions

    0 Retweets

    0 Likes

    0 Bookmarks

    0 Replies

    0 Quotes

  11. #threatreport #LowCompleteness Apache Under the Lens: Tomcats Partial PUT and Camels Header Hijack | 04-07-2025 Source: https://t.co/SrPVxXbswl Key details below ↓ 🧑‍💻Actors/Campaigns: Atlas_lion 🎯Victims: Apache tomcat users, Apache camel users 🔓CVEs: CVE-2025

    @rst_cloud

    5 Jul 2025

    53 Impressions

    0 Retweets

    0 Likes

    0 Bookmarks

    0 Replies

    0 Quotes

  12. "Apache disclosed critical RCE bugs: CVE-2025-24813 in Tomcat, CVE-2025-27636 & CVE-2025-29891 in Camel. Millions of developers at risk. Patch ASAP."

    @Tudorel92659164

    4 Jul 2025

    21 Impressions

    0 Retweets

    0 Likes

    0 Bookmarks

    0 Replies

    0 Quotes

  13. Critical vulnerabilities in Apache Tomcat (CVE-2025-24813) & Camel (CVE-2025-27636, CVE-2025-29891) exposed millions to remote code execution. Widespread scans and exploits highlight the urgent need for patches. 🚨 #SecurityAlert #OpenSource #UK https://t.co/Tp9rRTLiPD

    @TweetThreatNews

    3 Jul 2025

    19 Impressions

    0 Retweets

    0 Likes

    0 Bookmarks

    0 Replies

    0 Quotes

  14. 🚨 Attention all security professionals and IT leaders! Apache Camel vulnerabilities (CVE-2025-27636 and CVE-2025-29891) patched three weeks ago can still pose a significant risk if not addressed properly.

    @fynn_JourX

    2 Apr 2025

    13 Impressions

    0 Retweets

    0 Likes

    0 Bookmarks

    1 Reply

    0 Quotes

  15. Apache Camel Exploit Attempt by Vulnerability Scan (CVE-2025-27636, CVE-2025-29891) https://t.co/TsVyvm5Mq8 https://t.co/EuAX5I4DRa

    @sans_isc

    31 Mar 2025

    1440 Impressions

    1 Retweet

    7 Likes

    1 Bookmark

    0 Replies

    0 Quotes

  16. CVE-2025-29891 - Bypass/Injection vulnerability in Apache Camel https://t.co/IrjZqtmzgx https://t.co/fOLZR5oKwI

    @SirajD_Official

    27 Mar 2025

    16 Impressions

    0 Retweets

    0 Likes

    0 Bookmarks

    0 Replies

    0 Quotes

  17. CVE-2025-29891 impacts Apache Camel #ApacheCamel #CVE-2025-29891 https://t.co/gLwLiX2wYK

    @pravin_karthik

    19 Mar 2025

    19 Impressions

    0 Retweets

    0 Likes

    0 Bookmarks

    0 Replies

    0 Quotes

  18. 🚨Alleged disclosure of Apache Camel CVE-2025–27636 & CVE-2025-29891​ affecting versions 4.10.0-4.10.1, 4.8.0-4.8.4, 3.10.0-3.22.3 https://t.co/ClAgJhhFEX

    @DarkWebInformer

    13 Mar 2025

    2300 Impressions

    0 Retweets

    8 Likes

    2 Bookmarks

    0 Replies

    0 Quotes

  19. PoC para Apache Camel ⚠️ CVE-2025–27636 ⚠️ CVE-2025-29891 https://t.co/DEermvnCjQ https://t.co/fp4hCE1IEG

    @elhackernet

    12 Mar 2025

    2558 Impressions

    2 Retweets

    6 Likes

    2 Bookmarks

    0 Replies

    0 Quotes

Configurations

  1. Improper Neutralization of Special Elements used in an Expression Language Statement ('Expression Language Injection') vulnerability in Apache Camel AWS2-s3 component. This issue affects Apache Camel: from 4.8.0 before 4.18.5, from 4.19.0 before 4.22.2. For the object it uploads, reads or deletes, the camel-aws2-s3 producer takes the key from the CamelAwsS3Key message header and falls back to the keyName option configured on the endpoint only when that header is absent. Since 4.8.0, AWS2S3Utils.determineKey() also passed the resulting value to the Simple language whenever it contained ${ or $simple{, so that a route could use a dynamic key, and the evaluation applied to a value taken from the header as well as to the configured option. The header is not route configuration, however: the aws2-s3 consumer sets CamelAwsS3Key on the exchanges it creates to the key of the object it read, that is, the name of the object in the bucket. In a route that does nothing more than consume from one aws2-s3 endpoint and produce to another, the name of each consumed object therefore reached the producer, and a name containing either marker was evaluated as an expression, although the route author never asked for any evaluation, and configuring keyName on the producer did not prevent it, because the header took precedence. A key that a route copied into the header from other message content was evaluated in the same way. Anyone able to choose the name of an object in a bucket that such a route consumes, typically a principal allowed to upload to that bucket, could therefore have Simple expressions of their choosing evaluated in the Camel process. The Simple language can read JVM system properties, environment variables and configuration properties, which commonly carry credentials, and, where camel-bean is on the classpath, invoke methods on beans in the registry. The evaluated result became the key the producer used, so reading a value back additionally required the ability to see object names in the destination bucket, while a method invocation took effect without it; together with the need to name an object in a consumed bucket, this is why the severity is assessed medium. The bucket name went through the same evaluation, but the consumer only ever places the bucket configured on its own endpoint in a bucket header, never a value derived from a remote object, so the bucket name was not reachable in this way. Releases before 4.8.0 used the key from the header as given and are not affected. Users are recommended to upgrade to version 4.23.0, which fixes the issue. If users are on the 4.22.x releases stream, then they are suggested to upgrade to 4.22.2. If users are on the 4.18.x releases stream, then they are suggested to upgrade to 4.18.5. The 4.8.x to 4.17.x and 4.19.x to 4.21.x release lines reached end of life before this issue was resolved and will not receive a fix, so deployments on them must move to a supported release. After upgrading, a key or bucket name supplied through a message header is used literally, so a route that put an unevaluated Simple expression in the CamelAwsS3Key or CamelAwsS3OverrideBucketName header must evaluate it in the route instead, for example with setHeader and simple(), or configure it as the keyName or bucketName option of the endpoint. For deployments that cannot upgrade immediately, do not let a key derived from an object name or from other untrusted message content reach an aws2-s3 producer unchecked: in routes that pass exchanges from an aws2-s3 consumer to an aws2-s3 producer, either remove the CamelAwsS3Key header before the producer with removeHeader(“CamelAwsS3Key”), so that the keyName configured on the endpoint is used, or reject exchanges whose CamelAwsS3Key header contains ${ or $simple{. Configuring keyName alone is not a workaround, because the header takes precedence over it. As defence in depth, allow only trusted principals to write to buckets that Camel routes consume.•CVE-2026-95664
  2. Improper input validation vulnerability in Apache Camel Undertow component. This issue affects Apache Camel: from 4.11.0 before 4.14.9, from 4.15.0 before 4.18.4, from 4.19.0 before 4.22.0. UndertowEndpoint defaulted its headerFilterStrategy field to the base HttpHeaderFilterStrategy and pushed that instance into the UndertowHttpBinding it creates lazily, overwriting the UndertowHeaderFilterStrategy that DefaultUndertowHttpBinding installs in its own constructor. Unless a deployment supplied a custom binding or an explicit headerFilterStrategy, the undertow-specific filtering therefore never executed on endpoint-configured routes: the strategy object was constructed and immediately replaced before it could be consulted. The consequence is that the legacy websocket. Exchange-header prefix was not filtered at the undertow transport boundary in either direction, so an undertow HTTP consumer mapped inbound wire headers of that form onto the Exchange, where an undertow WebSocket producer reads them as dispatch directives and can be made to deliver to a peer other than the one the route selected; and header names that undertow itself does not accept were mapped onto the Exchange rather than being skipped. Rest DSL consumers were never affected, because UndertowComponent assigns UndertowRestHeaderFilterStrategy explicitly, which extends the undertow strategy. This is not a regression of CVE-2025-30177: the base HttpHeaderFilterStrategy configures the inbound Camel-prefix filter itself, so the protection introduced by that advisory continued to work through the base class and was never lost. What the change did was leave the undertow strategy orphaned on the endpoint path, with the effect that two subsequent corrections written into it - one skipping header names undertow rejects, one filtering the legacy websocket. prefix in both directions - were applied to a class the endpoint no longer used and never took effect in the releases that shipped them. Users are recommended to upgrade to version 4.22.0, which fixes the issue. If users are on the 4.14.x LTS releases stream, then they are suggested to upgrade to 4.14.9. If users are on the 4.18.x releases stream, then they are suggested to upgrade to 4.18.4. For deployments that cannot upgrade immediately, configure the strategy explicitly rather than relying on the default, for example by binding an UndertowHeaderFilterStrategy in the registry and referencing it on the endpoint as undertow:http://0.0.0.0:8080/foo?headerFilterStrategy=#myStrategy, and additionally strip the dispatch headers at the trust boundary with removeHeaders(“websocket.*”). Note a residual limitation that upgrading does not remove: the undertow component deliberately keeps the websocket. values as part of its externally visible API contract, and UndertowProducer reads them with in.getHeader, which does not consult a HeaderFilterStrategy at all. The restored filtering is therefore defence in depth at the undertow transport boundary only. A route that carries an untrusted message from a non-undertow consumer into an undertow producer is not protected by this fix and must strip those headers itself.•CVE-2026-78329