[
https://issues.apache.org/jira/browse/CAMEL-21880?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17936556#comment-17936556
]
Andrea Cosentino edited comment on CAMEL-21880 at 3/18/25 5:01 PM:
-------------------------------------------------------------------
If you expose an http endpoint you can append a request parameter and having
that translated to an header, if you explicitly send an header malformed you
must know the subsequent component, you have to do on purpose and you should
have access to the entrypoint. To me this is a different case. and also how do
you know what is the downstream component you're sending the header to? With an
HTTP endpoint is quite different. The cve clear state you have to use HTTP
endpoint as consumer. If you send a malformed header you must:
- have access to the environment running camel or at least access the entry
point
- know the downstream component
- know what is the URI of the configured downstream component
To me is a completely different context. Nevertheless I'll go through the
strategies and add lowercase, but I think we are not in the case described in
the CVE, because the original condition is using one of the HTTP components.
was (Author: ancosen):
If you expose an http endpoint you can append a request parameter and having
that translated to an header, if you explicitly send an header malformed you
must know the subsequent component and you have to do on purpose. To me this is
a different case. and also how do you know what is the downstream component
you're sending the header to? With an HTTP endpoint is quite different. The cve
clear state you have to use HTTP endpoint as consumer. If you send a malformed
header you must:
- have access to the environment running camel or at least access the entry
point
- know the downstream component
- know what is the URI of the configured downstream component
To me is a completely different context. Nevertheless I'll go through the
strategies and add lowercase, but I think we are not in the case described in
the CVE, because the original condition is using one of the HTTP components.
> camel-kafka - add lowerCase to header filter strategy
> -----------------------------------------------------
>
> Key: CAMEL-21880
> URL: https://issues.apache.org/jira/browse/CAMEL-21880
> Project: Camel
> Issue Type: Improvement
> Components: camel-kafka
> Affects Versions: 3.22.3, 4.10.2
> Reporter: Jens Kordowski
> Priority: Major
>
> Due to [https://www.cve.org/CVERecord?id=CVE-2025-27636] the following
> extension has been implemented:
> https://issues.apache.org/jira/browse/CAMEL-21828
> This has an effect on
> [https://github.com/apache/camel/blob/main/components/camel-http-common/src/main/java/org/apache/camel/http/common/HttpHeaderFilterStrategy.java]
> as it sets lowerCase to true. The same is not true for
> [https://github.com/apache/camel/blob/main/components/camel-kafka/src/main/java/org/apache/camel/component/kafka/KafkaHeaderFilterStrategy.java]
> Very old implementations of the same
> ([https://github.com/apache/camel/blob/camel-2.25.4/components/camel-kafka/src/main/java/org/apache/camel/component/kafka/KafkaHeaderFilterStrategy.java])
> were using patterns, which were explicitly marked case-insensitive and this
> changed thereafter. Following this recent CVE and the changes, I assume this
> was not desired, hence I marked it as bug.
>
> There might be other header filter strategies out there that do not set
> lowerCase to true.
>
> Best regards
> Jens
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
