CVE-2025-27636

Published Mar 9, 2025

Last updated a year ago

CVSS medium 5.6
Apache Camel

Overview

AI description

Automated description summarized from trusted sources.

CVE-2025-27636 is a bypass/injection vulnerability found in the Apache Camel Bean component. This vulnerability affects Apache Camel versions 4.10.0 through 4.10.1, 4.8.0 through 4.8.4, and 3.10.0 through 3.22.3. The issue arises when specific HTTP servers (camel-servlet, camel-jetty, camel-undertow, camel-platform-http, or camel-netty-http) are used in conjunction with the camel-bean producer, and the targeted bean has multiple methods. Due to a flaw in the header filtering mechanism, an attacker can manipulate header names to invoke unintended methods on the bean. Exploitation of this vulnerability is possible when a bean has multiple methods and is invoked using the camel-bean component together with specific HTTP servers. The vulnerability stems from a bug in the default filtering mechanism, which only blocks headers starting with "Camel," "camel," or "org.apache.camel." By modifying the casing of these prefixes, an attacker can bypass the filter and inject arbitrary headers, leading to the execution of unintended methods within the bean. Users are advised to upgrade to Apache Camel versions 4.10.2, 4.8.5, or 3.22.4, depending on their current version branch. As a mitigation, headers can be removed within Camel routes using methods like the removeHeaders EIP to filter out headers not adhering to the standard prefixes.

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.".
Source
security@apache.org
NVD status
Analyzed
Products
camel

Risk scores

CVSS 3.1

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

Weaknesses

134c704f-9b21-4f2e-91b3-4a467353bcc0
CWE-178

Social media

Hype score
Not currently trending
  1. A PoC/exploit has been discovered for vulnerability CVE-2026-40453 PT ID: PT-2026-35370 Vendor: Apache Software Foundation Product: Apache Camel JMS Description: The fix for CVE-2025-27636 added setLowerCase(true) to HttpHeaderFilterStrategy so that case-variant header names

    @ptdbugs

    10 Jul 2026

    482 Impressions

    0 Retweets

    1 Like

    0 Bookmarks

    0 Replies

    0 Quotes

  2. 🚨 CVE-2026-40453 · CVSS 9.9 · CRITICAL CVE-2026-40453 — The fix for CVE-2025-27636 added setLowerCase(true) to HttpHeaderFilterStrategy so that case-variant header names such as 'CAmelExecCommandE… Patch guidance &amp; affected systems: https://t.co/96FrD5Eq8W

    @Antibrute_com

    3 May 2026

    0 Impressions

    0 Retweets

    0 Likes

    0 Bookmarks

    0 Replies

    0 Quotes

  3. CVE-2026-40453 The fix for CVE-2025-27636 added setLowerCase(true) to HttpHeaderFilterStrategy so that case-variant header names such as 'CAmelExecCommandExecutable' are filtered ou… https://t.co/MJYPMxy8HX

    @CVEnew

    27 Apr 2026

    176 Impressions

    0 Retweets

    0 Likes

    0 Bookmarks

    0 Replies

    0 Quotes

  4. [1day1line] CVE-2025-27636: RCE via Case-Sensitive Header Filtering Bypass in Apache Camel Today’s 1day1line covers a vulnerability found in Apache Camel’s header filtering logic. Camel attempts to protect internal routing metadata by filtering headers such as “Camel…”

    @hackyboiz

    26 Nov 2025

    715 Impressions

    2 Retweets

    7 Likes

    3 Bookmarks

    0 Replies

    0 Quotes

  5. Dragon Drop: this week's NEW releases 🐉🚨🔥 🪲 New CVE labs: → CVE-2025-27636_Attack: https://t.co/EG3buL6TEt → Defend CVE-2025-27636: https://t.co/cuuNIy5eiu → CraftStorm_Attack: https://t.co/qxxJugjUqS → Defend CraftStorm: https://t.co/M5KcMl9bya 🧪

    @offsectraining

    18 Jul 2025

    2557 Impressions

    2 Retweets

    16 Likes

    7 Bookmarks

    0 Replies

    0 Quotes

  6. 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

  7. CVE-2025-27636 – #Remote_Code_Execution in #Apache_Camel via Case-Sensitive Header Filtering #Bypass https://t.co/YeqTJkqXVD https://t.co/cFLWeXvxrL

    @omvapt

    13 Jul 2025

    32 Impressions

    0 Retweets

    0 Likes

    0 Bookmarks

    0 Replies

    0 Quotes

  8. Deep Dive: CVE-2025-27636 (RCE in Apache Camel via Header Filter Bypass) ⚠️ CVSS 5.6 | EPSS 35.5% A case-sensitive header check + exec functionality = remote command execution. Attackers can bypass Camel’s security filters by capitalizing key HTTP headers and execute syst

    @offsectraining

    10 Jul 2025

    4805 Impressions

    7 Retweets

    29 Likes

    13 Bookmarks

    0 Replies

    1 Quote

  9. 【脆弱性分析】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

  10. 🛡️ RCE flaws in Apache Tomcat (CVE-2025-24813) &amp; Camel (CVE-2025-27636/29891) under active attack. 🚨 Exploits use partial PUT &amp; header case tricks. 🔧 Patch now. Over 125K attempts detected. Read more: https://t.co/tO1iixhgQb #Apache #CVE2025 #CyberSecurity

    @threatsbank

    5 Jul 2025

    34 Impressions

    0 Retweets

    0 Likes

    0 Bookmarks

    0 Replies

    0 Quotes

  11. "Apache disclosed critical RCE bugs: CVE-2025-24813 in Tomcat, CVE-2025-27636 &amp; 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

  12. Critical vulnerabilities in Apache Tomcat (CVE-2025-24813) &amp; 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

  13. 1/6 1/ 🚨 #Apache bajo ataque: Vulnerabilidades en Tomcat (Partial PUT CVE-2025-24813) y Camel (Header Hijack CVE-2025-27636) revelan riesgos críticos. Descubiertos recientemente, pueden ser explotados para comprometer sistemas. 🌐 Detalles: https://t.co/DlFPoXSyxT

    @x_sentinel99263

    3 Jul 2025

    13 Impressions

    0 Retweets

    0 Likes

    0 Bookmarks

    1 Reply

    0 Quotes

  14. #Vulnerability #ApacheCamel Apache Camel Vulnerability (CVE-2025-27636) Exposes Applications to RCE, PoC Releases https://t.co/mDViNR0s9U

    @Komodosec

    4 Jun 2025

    19 Impressions

    0 Retweets

    0 Likes

    0 Bookmarks

    0 Replies

    0 Quotes

  15. .@Akamai researchers have created detection scripts and additional details for the Apache Camel vulnerability CVE-2025-27636. Learn more. #AkamaiSecurity https://t.co/Ds9z7hVl2e https://t.co/2sn06EPJYF

    @dholland64

    10 Apr 2025

    20 Impressions

    0 Retweets

    1 Like

    0 Bookmarks

    0 Replies

    0 Quotes

  16. 🚨 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

  17. 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

  18. .@Akamai researchers have created detection scripts and additional details for the Apache Camel vulnerability CVE-2025-27636. Learn more. #AkamaiSecurity https://t.co/AakyYkdATh https://t.co/3YVZA3IwDl

    @epichol

    27 Mar 2025

    2 Impressions

    0 Retweets

    0 Likes

    0 Bookmarks

    0 Replies

    0 Quotes

  19. .@Akamai researchers have created detection scripts and additional details for the Apache Camel vulnerability CVE-2025-27636. Learn more. #AkamaiSecurity https://t.co/UQyz9LM5vs https://t.co/mYb8xSA25V

    @RaghuNain

    18 Mar 2025

    11 Impressions

    0 Retweets

    0 Likes

    0 Bookmarks

    0 Replies

    0 Quotes

  20. .@Akamai researchers have created detection scripts and additional details for the Apache Camel vulnerability CVE-2025-27636. Learn more. #AkamaiSecurity https://t.co/I5t80Mlh9W https://t.co/wok8zdTioM

    @ArminBolenius

    13 Mar 2025

    26 Impressions

    0 Retweets

    0 Likes

    0 Bookmarks

    0 Replies

    0 Quotes

  21. .@Akamai researchers have created detection scripts and additional details for the Apache Camel vulnerability CVE-2025-27636. Learn more. #AkamaiSecurity https://t.co/RqnoLmFYvt https://t.co/Ljg5dZJsLP

    @AngeloAkamai

    13 Mar 2025

    35 Impressions

    0 Retweets

    0 Likes

    0 Bookmarks

    0 Replies

    0 Quotes

  22. Is your Apache Camel app vulnerable? Critical RCE risk disclosed! Apache Camel CVE-2025-27636 exposes RCE via header filtering bypass; patch ASAP. TL;DR: • Apache Camel disclosed CVE-2025-27636 vulnerability. • Incorrect header filtering leads to remote code execution. •… https

    @TweekFawkes

    12 Mar 2025

    88 Impressions

    0 Retweets

    0 Likes

    0 Bookmarks

    1 Reply

    0 Quotes

  23. Akamai researchers have created detection scripts and additional details for the Apache Camel vulnerability CVE-2025-27636. Learn more. https://t.co/SyiMXWtHz7 https://t.co/Md0rpqY1jL

    @Akamai

    12 Mar 2025

    518 Impressions

    1 Retweet

    4 Likes

    0 Bookmarks

    0 Replies

    0 Quotes

  24. GitHub - akamai/CVE-2025-27636-Apache-Camel-PoC https://t.co/QN8hMeAxWH

    @akaclandestine

    11 Mar 2025

    2374 Impressions

    11 Retweets

    42 Likes

    15 Bookmarks

    0 Replies

    0 Quotes

  25. GitHub - akamai/CVE-2025-27636-Apache-Camel-PoC - https://t.co/b37g3BDuEF

    @piedpiper1616

    10 Mar 2025

    3634 Impressions

    16 Retweets

    39 Likes

    17 Bookmarks

    0 Replies

    0 Quotes

  26. 🚨 CVE-2025-27636 ❓ 🏢 Apache Software Foundation - Apache Camel 🏗️ 4.10.0 🔗 https://t.co/723OXUGK4N 🔗 https://t.co/P4TeBfS7pN #CyberCron #VulnAlert #InfoSec https://t.co/67WeHwPfQB

    @cybercronai

    10 Mar 2025

    81 Impressions

    0 Retweets

    1 Like

    0 Bookmarks

    0 Replies

    0 Quotes

  27. New post from https://t.co/uXvPWJy6tj (CVE-2025-27636 | Apache Camel up to 3.22.3/4.8.4/4.10.1 Default Header Filtering injection) has been published on https://t.co/YqWz6yJ60f

    @WolfgangSesin

    9 Mar 2025

    103 Impressions

    0 Retweets

    0 Likes

    0 Bookmarks

    0 Replies

    0 Quotes

  28. CVE-2025-27636: Apache Camel: Camel Message Header Injection via Improper Filtering https://t.co/k7sAAYugRT Default filtering mechanism only blocks headers starting with "Camel", "camel", or "org.apache.camel.". Attackers can bypass this filter by altering the casing of letters.

    @oss_security

    9 Mar 2025

    438 Impressions

    0 Retweets

    0 Likes

    2 Bookmarks

    0 Replies

    0 Quotes

  29. CVE-2025-27636 Header Injection Vulnerability in Apache Camel Enabling Arbitrary Method Invocation https://t.co/aMgUkgVl8R

    @VulmonFeeds

    9 Mar 2025

    279 Impressions

    0 Retweets

    1 Like

    1 Bookmark

    0 Replies

    0 Quotes

  30. CVE-2025-27636 Bypass/Injection vulnerability in Apache Camel. This issue affects Apache Camel: from 4.10.0 through &lt;= 4.10.1, from 4.8.0 through &lt;= 4.8.4, from 3.10.0 through &lt;= 3… https://t.co/lahkvOompC

    @CVEnew

    9 Mar 2025

    1010 Impressions

    0 Retweets

    1 Like

    0 Bookmarks

    0 Replies

    1 Quote

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. Insufficient Session Expiration vulnerability in Apache Camel Keycloak component. This issue affects Apache Camel: from 4.16.0 before 4.18.5, from 4.19.0 before 4.22.2. When token introspection is enabled on the camel-keycloak KeycloakSecurityPolicy (useTokenIntrospection=true), the security processor validates the access token of a request by sending it to Keycloak's OAuth 2.0 token introspection endpoint, and accepts the token while the response reports it as active. The introspection endpoint reports a token as inactive once its exp (expiration) time has passed, so on this path the active flag is what enforces token expiry. Introspection results are cached by default (introspectionCacheEnabled=true, introspectionCacheTtl=60 seconds), and both cache implementations shipped with the component, ConcurrentMapTokenCache and CaffeineTokenCache, expired an entry a fixed time after it was inserted, without bounding that lifetime by the exp claim that the cached response already carried. KeycloakSecurityProcessor in turn checked only the active flag of the result, on every path that uses introspection, and never compared exp with the current time. A response cached shortly before the token expired was therefore served to later requests carrying the same token for up to the configured time-to-live after the token's expiry, and those requests were admitted with the roles and permissions the expired token had carried, although RFC 7662, which defines token introspection, states that a response containing exp must not be cached beyond that time. The access token is supplied by the caller with each request, typically as a bearer token in the Authorization header, so a caller holding a token that was valid moments earlier could keep using it after it expired, for as long as the cached entry lived. The window is bounded by introspectionCacheTtl, which is 60 seconds by default and 300 to 600 seconds where the documentation's recommendation for internal services was followed, and it opens only for a token that the same Camel process introspected and cached while the token was still active. The issue grants nothing beyond what the token already carried: it allows no token forgery and no privilege escalation, and token introspection is not enabled by default, which is why the severity is assessed medium. The local JWT verification path, used when introspection is disabled, is not affected by this issue. 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.16.x, 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. For deployments that cannot upgrade immediately, set introspectionCacheEnabled=false on the KeycloakSecurityPolicy, so that every request is checked against the introspection endpoint, which reports an expired token as inactive, at the cost of one introspection call per request. Lowering introspectionCacheTtl only narrows the window and does not close it.•CVE-2026-95663
  3. Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal') vulnerability in Apache Camel Docling component. This issue affects Apache Camel: from 4.15.0 before 4.18.5, from 4.19.0 before 4.22.2. DoclingProducer runs the external docling tool in CLI mode, the default, and tells it where to write the converted document through the --output flag. When the CamelDoclingOutputFilePath header was set, addOutputDirectoryArguments handed its value to that flag verbatim: the value was not normalized, an absolute path or a path containing .. segments was accepted as given, and no endpoint option could confine it to a directory. The custom-argument validation added by the fix for CVE-2026-40047 refuses the --output and -o flags in the CamelDoclingCustomArguments header and tells callers to choose the output directory with this header instead, so the one value that decides where docling writes reached the command line without any of the checks applied to custom arguments. Docling writes the conversion result, as Markdown, HTML, JSON or text, into that directory, naming the file after the input file, and the producer afterwards removes only its own temporary directory, so the file is left in place. A party able to set the header could therefore have conversion output created in any directory the Camel process can write to. The content of such a file is the conversion of the document carried by the message, so it is shaped by whoever supplies that document without being written byte for byte, and when the document content arrives in the message body the producer stores it under a random temporary name, which the output file then carries. The header belongs to the Camel header namespace, which consumers applying Camel's default header filtering, such as the JMS and Kafka consumers, remove from incoming messages, so the issue is reached where a route forwards externally influenced values into the header or where a consumer maps incoming headers without that filtering. The docling-serve mode does not use the header. 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 fix adds an outputBaseDirectory endpoint option that is unset by default, so after upgrading, set it on every docling endpoint whose CamelDoclingOutputFilePath header can carry a value influenced from outside the deployment; without it the header is normalized but can still name any directory. The 4.15.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. For deployments that cannot upgrade immediately, do not build the CamelDoclingOutputFilePath header from values that originate outside the deployment, remove that header from messages that arrive from outside before they reach a docling endpoint, and make sure that consumers which map incoming message headers drop the Camel header namespace, so that only the route itself chooses the output directory.•CVE-2026-95629
  4. Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal') vulnerability in Apache Camel Docling component. This issue affects Apache Camel: from 4.15.0 before 4.18.5, from 4.19.0 before 4.22.2. DoclingProducer builds the command line of the external docling tool and appends to it the custom arguments supplied in the CamelDoclingCustomArguments header, a list of strings whose flags the fix for CVE-2026-40047 restricted to an allowlist. That fix also introduced validatePathSafety to keep path-like argument values inside the intended directory, but the method only looked for relative traversal: it rejected a value containing a traversal sequence such as ../ and a value whose normalized form still held a .. element. It never checked whether a value was an absolute path, and an absolute path without traversal segments contains neither, so it passed unchanged. Every path-like value went through this check, whether it was a separate list element following its flag or was attached to the flag after an equals sign, so an absolute path was accepted in either form, for example as the directory given to the allowlisted --artifacts-path flag, which tells docling where to find its model artifacts. Such a value reached the docling command line as given, so a party able to choose the custom arguments could point the docling process at any directory the Camel process can access, outside the working directory that the check was meant to keep path values in, which is the outcome the CVE-2026-40047 fix set out to prevent. Only the CLI mode, which is the default, passes custom arguments to docling. The header belongs to the Camel header namespace, which consumers applying Camel's default header filtering, such as the JMS and Kafka consumers, remove from incoming messages, so the issue is reached where a route forwards externally influenced values into the header or where a consumer maps incoming headers without that filtering. 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.15.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. For deployments that cannot upgrade immediately, do not build the CamelDoclingCustomArguments header from values that originate outside the deployment, remove that header from messages that arrive from outside before they reach a docling endpoint, and make sure that consumers which map incoming message headers drop the Camel header namespace, so that only the route itself chooses the custom arguments.•CVE-2026-95628
  5. Generation of Error Message Containing Sensitive Information vulnerability in Apache Camel CoAP component. This issue affects Apache Camel: from 4.0.0 before 4.18.5, from 4.19.0 before 4.22.2. When the CoAP consumer could not build its response once the route had completed, CamelCoapResource caught the resulting exception and sent its message back to the CoAP client as the payload of a 5.00 Internal Server Error response. The typical case is a type conversion failure: the consumer converts the final message body to the byte[] payload, and the CamelCoapMaxAge and CamelCoapETag headers to their types, after the route has returned, and therefore outside the route's error handler. On the affected releases the message of such a failure names the class of the value being converted, carries the value's string form, and ends with the class name and message of the underlying cause, so a remote CoAP client could read internal detail about the deployment: class and package names, the string form of the value, such as the path of a file body, and whatever the cause carries, which in practice can include paths, host names and connection detail of a backend. The consumer had no option to suppress this, unlike the HTTP consumers, which offer a muteException option for that purpose. The exception raised by a failing route was not sent: the consumer did not check whether the exchange had failed, and answered a route failure with 2.05 Content and whatever body the message held at that point. Reaching the disclosure therefore requires a route whose completed response a remote client can make unconvertible, which depends on how the route is written. 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.14.x releases stream and earlier, and the 4.15.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. The upgrade is enough on its own: the new muteException consumer option defaults to true on all three fixed release lines, so the error response carries no payload without any configuration change. For deployments that cannot upgrade immediately, make sure the response can always be built once the route has completed: convert the body to byte[] or String as the last step of each route that consumes from a coap endpoint, for example with convertBodyTo, give the CamelCoapMaxAge and CamelCoapETag headers only values of their own types, and add an onException handler that marks the failure as handled and sets the response body explicitly, so that a conversion failure is raised and replaced inside the route rather than in the consumer.•CVE-2026-101259