CVE-2026-95664 json
Apache Camel: Camel-AWS2-S3 Producer Evaluates Untrusted S3 Object Keys From the CamelAwsS3Key Header as Simple Expressions
published 2026-10-26 14 d ago modified 2026-11-02 6 d ago also EUVD-2026-109668
- cvss
- 5.4
- version 3.1, CNA
- cisa kev
- Not listed
- not in CISA's catalog
- epss
- 0.8%
- EPSS 0.8% chance of exploitation in 30 days, percentile 57%
- public exploits
- 0
- none known
Summary
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.
Patch / fix
- Apache Software Foundation Apache Camel 4.18.5, 4.22.2
- github.com/apache/camel#26746 pull request
- github.com/apache/camel#26840 pull request
- github.com/apache/camel#26842 pull request
- github.com/apache/camel#26841 pull request
- github.com/apache/camel#26889 pull request
Vendor advisories
What the vendors themselves say about their products: affected, fixed or not affected, and what to do.
red hat product security vex CVE-2026-95664 updated cvss 5.4
org.apache.camel/camel-aws2-s3: camel-aws2-s3: Expression language injection via untrusted S3 object keys
-
Red Hat OpenShift Serverless openshift-serverless-1/kn-eventing-integrations-aws-s3-sink-rhel9, openshift-serverless-1/kn-eventing-integrations-aws-s3-source-rhel9 Red Hat build of Apache Camel 4 for Quarkus 3 camel-aws2-s3 4.18.4.redhat-00007 Red Hat build of Apache Camel for Spring Boot 4 camel-aws2-s3 4.18.4.redhat-00007affected: workaround, no fix available “Fix deferred”
-
Red Hat Fuse 7 camel-aws2-s3 4.18.4.redhat-00007not affected: vulnerable code not present
Red Hat CSAF VEX © Red Hat, Inc., from https://security.access.redhat.com/data/csaf/v2/vex/; changed: reduced to product statuses and remediations. CC BY 4.0 · csaf
CISA SSVC
- Exploitation
- none
- Automatable
- no
- Technical impact
- partial
- Assessed
- 6 d ago
Exploit prediction
0.84% chance of exploitation in the next 30 days, higher than 57% of all scored CVEs (FIRST EPSS, 2026-11-08).
CVSS scores
| assigned by | version | score | vector |
|---|---|---|---|
| CNA | 3.1 | 5.4 | CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N |
| CISA ADP | 3.1 | 5.4 | CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N |
Affected products
- Apache Software Foundation Apache Camel
Classification
- Weakness
-
- CWE-917 Improper Neutralization of Special Elements used in an Expression Language Statement
References
-
github.com
/apache/camel/pull/26746
patch, issue-tracking
-
github.com
/apache/camel/pull/26840
patch, issue-tracking
-
github.com
/apache/camel/pull/26842
patch, issue-tracking
-
github.com
/apache/camel/pull/26841
related, issue-tracking, patch
-
github.com
/apache/camel/pull/26889
related, issue-tracking, patch
-
camel.apache.org
/security/CVE-2026-95664.html
vendor-advisory
-
issues.apache.org
/jira/browse/CAMEL-24901
issue-tracking
-
issues.apache.org
/jira/browse/CAMEL-20971
related, issue-tracking
-
camel.apache.org
/security/CVE-2026-78164.html
related, not-applicable
-
camel.apache.org
/security/CVE-2026-83531.html
related, not-applicable
-
camel.apache.org
/security/CVE-2025-27636.html
related, not-applicable
Sources
- CVE List CVE-2026-95664
- NVD CVE-2026-95664
Fencer Vulns keeps one entry per vulnerability: the CVE id wins, then GHSA, and records that alias each other are merged, except that two CVEs always keep separate entries. The same data is available as JSON.