Refine your search
97 vulnerabilities found for Apache Camel by Apache Software Foundation
CVE-2026-90885 (GCVE-0-2026-90885)
Vulnerability from cvelistv5
Published
2026-10-26 14:47
Modified
2026-10-26 15:35
Severity ?
VLAI Severity ?
EPSS score ?
CWE
- CWE-611 - Improper Restriction of XML External Entity Reference
Summary
Improper Restriction of XML External Entity Reference vulnerability in Apache Camel Saxon component.
This issue affects Apache Camel: from 4.0.0 before 4.18.5, from 4.19.0 before 4.22.2.
XQueryBuilder in camel-saxon, which evaluates expressions for the xquery language and the xquery component, built its default Saxon Configuration with parse options that set only a whitespace stripping rule, leaving the XML parser at its defaults, under which a DOCTYPE declaration is accepted and external entities are resolved. A message body of type String or byte[], or any body read as an InputStream, is first turned into a javax.xml.transform.Source by Camel's own XML type converters, which configure the parser against external entities, so those bodies were not affected. A body that was already a Source, however, was handed to Saxon unchanged, and when that Source still had to be parsed, as a stream-based Source does, Saxon parsed it with that Configuration, bypassing the protection applied to the other body types. Such a body arises, for example, after a route converts the message with convertBodyTo(Source.class), or when a component or processor earlier in the route sets the body to a stream-based Source. A DOCTYPE with an external subset, or an external entity, declared in that body was therefore resolved and expanded into the document the expression was evaluated against. An external sender whose XML reaches an XQuery expression or an xquery endpoint in that form could read files readable by the Camel process and cause the process to issue requests to hosts the document names. No non-default option is required, since the default Configuration is used whenever the route does not supply one of its own.
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, as well as 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 evaluate XQuery over a message body that is already a javax.xml.transform.Source when that body carries XML from an untrusted sender, or set the configuration option of the xquery endpoint or language to a Saxon Configuration whose parse options refuse a DOCTYPE declaration and disable external entities and external DTD loading, which is what the fixed releases now apply by default.
References
| URL | Tags | |
|---|---|---|
|
|
||
Impacted products
| Vendor | Product | Version | ||
|---|---|---|---|---|
| Apache Software Foundation | Apache Camel |
Version: 4.0.0 Version: 4.19.0 |
{
"containers": {
"adp": [
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2026-90885",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "yes"
},
{
"Technical Impact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-10-26T15:29:02.992870Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-10-26T15:35:49.414Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"collectionURL": "https://repo.maven.apache.org/maven2",
"defaultStatus": "unaffected",
"packageName": "org.apache.camel:camel-saxon",
"packageURL": "pkg:maven/org.apache.camel/camel-saxon",
"product": "Apache Camel",
"vendor": "Apache Software Foundation",
"versions": [
{
"lessThan": "4.18.5",
"status": "affected",
"version": "4.0.0",
"versionType": "maven"
},
{
"lessThan": "4.22.2",
"status": "affected",
"version": "4.19.0",
"versionType": "maven"
}
]
}
],
"credits": [
{
"lang": "en",
"type": "finder",
"value": "Leon Zlobecki"
},
{
"lang": "en",
"type": "remediation developer",
"value": "Andrea Cosentino"
}
],
"descriptions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eImproper Restriction of XML External Entity Reference vulnerability in Apache Camel Saxon component.\u003c/p\u003e\u003cp\u003eThis issue affects Apache Camel: from 4.0.0 before 4.18.5, from 4.19.0 before 4.22.2.\u003c/p\u003e\u003cp\u003eXQueryBuilder in camel-saxon, which evaluates expressions for the xquery language and the xquery component, built its default Saxon Configuration with parse options that set only a whitespace stripping rule, leaving the XML parser at its defaults, under which a DOCTYPE declaration is accepted and external entities are resolved. A message body of type String or byte[], or any body read as an InputStream, is first turned into a javax.xml.transform.Source by Camel\u0027s own XML type converters, which configure the parser against external entities, so those bodies were not affected. A body that was already a Source, however, was handed to Saxon unchanged, and when that Source still had to be parsed, as a stream-based Source does, Saxon parsed it with that Configuration, bypassing the protection applied to the other body types. Such a body arises, for example, after a route converts the message with convertBodyTo(Source.class), or when a component or processor earlier in the route sets the body to a stream-based Source. A DOCTYPE with an external subset, or an external entity, declared in that body was therefore resolved and expanded into the document the expression was evaluated against. An external sender whose XML reaches an XQuery expression or an xquery endpoint in that form could read files readable by the Camel process and cause the process to issue requests to hosts the document names. No non-default option is required, since the default Configuration is used whenever the route does not supply one of its own.\u003c/p\u003e\u003cp\u003eUsers 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, as well as 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 evaluate XQuery over a message body that is already a javax.xml.transform.Source when that body carries XML from an untrusted sender, or set the configuration option of the xquery endpoint or language to a Saxon Configuration whose parse options refuse a DOCTYPE declaration and disable external entities and external DTD loading, which is what the fixed releases now apply by default.\u003c/p\u003e"
}
],
"value": "Improper Restriction of XML External Entity Reference vulnerability in Apache Camel Saxon component.\n\n\n\nThis issue affects Apache Camel: from 4.0.0 before 4.18.5, from 4.19.0 before 4.22.2.\n\n\n\nXQueryBuilder in camel-saxon, which evaluates expressions for the xquery language and the xquery component, built its default Saxon Configuration with parse options that set only a whitespace stripping rule, leaving the XML parser at its defaults, under which a DOCTYPE declaration is accepted and external entities are resolved. A message body of type String or byte[], or any body read as an InputStream, is first turned into a javax.xml.transform.Source by Camel\u0027s own XML type converters, which configure the parser against external entities, so those bodies were not affected. A body that was already a Source, however, was handed to Saxon unchanged, and when that Source still had to be parsed, as a stream-based Source does, Saxon parsed it with that Configuration, bypassing the protection applied to the other body types. Such a body arises, for example, after a route converts the message with convertBodyTo(Source.class), or when a component or processor earlier in the route sets the body to a stream-based Source. A DOCTYPE with an external subset, or an external entity, declared in that body was therefore resolved and expanded into the document the expression was evaluated against. An external sender whose XML reaches an XQuery expression or an xquery endpoint in that form could read files readable by the Camel process and cause the process to issue requests to hosts the document names. No non-default option is required, since the default Configuration is used whenever the route does not supply one of its own.\n\n\n\nUsers 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, as well as 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 evaluate XQuery over a message body that is already a javax.xml.transform.Source when that body carries XML from an untrusted sender, or set the configuration option of the xquery endpoint or language to a Saxon Configuration whose parse options refuse a DOCTYPE declaration and disable external entities and external DTD loading, which is what the fixed releases now apply by default."
}
],
"metrics": [
{
"cvssV3_1": {
"attackComplexity": "LOW",
"attackVector": "NETWORK",
"availabilityImpact": "NONE",
"baseScore": 7.5,
"baseSeverity": "HIGH",
"confidentialityImpact": "HIGH",
"integrityImpact": "NONE",
"privilegesRequired": "NONE",
"scope": "UNCHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
"version": "3.1"
},
"format": "CVSS",
"scenarios": [
{
"lang": "en",
"value": "GENERAL"
}
]
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-611",
"description": "CWE-611 Improper Restriction of XML External Entity Reference",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-10-26T14:47:03.155Z",
"orgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
"shortName": "apache"
},
"references": [
{
"name": "Apache Camel Security Advisory - CVE-2026-90885",
"tags": [
"vendor-advisory"
],
"url": "https://camel.apache.org/security/CVE-2026-90885.html"
},
{
"name": "CAMEL-24691",
"tags": [
"issue-tracking"
],
"url": "https://issues.apache.org/jira/browse/CAMEL-24691"
},
{
"name": "Fix on main, released in 4.23.0 (commit 9c23b6868bb92cb19c2b5a7ee624421d760cda8f)",
"tags": [
"patch"
],
"url": "https://github.com/apache/camel/pull/26344"
},
{
"name": "Backport to camel-4.22.x for 4.22.2 (commit 0d0ed8bbe38fdae6e778c4f719e80c2e2d0e51b2)",
"tags": [
"patch"
],
"url": "https://github.com/apache/camel/pull/26728"
},
{
"name": "Backport to camel-4.18.x, released in 4.18.5 (commit ed513f3a7117c3343a9e31e22e5627498f2fcdb6)",
"tags": [
"patch"
],
"url": "https://github.com/apache/camel/pull/26730"
},
{
"name": "CVE-2026-85250, the camel-xpath documentType=InputSource XXE, distinct from this issue",
"tags": [
"related"
],
"url": "https://camel.apache.org/security/CVE-2026-85250.html"
}
],
"solutions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eUsers 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. XQueryBuilder now builds its default Saxon Configuration with parse options that refuse a DOCTYPE declaration and disable external general entities, external parameter entities and external DTD loading, aligning a body that is already a javax.xml.transform.Source with the hardened parser configuration that Camel\u0027s XmlConverter applies to String, byte[] and InputStream bodies. A body that reaches XQuery as an already-built Source and carries a DOCTYPE declaration is now rejected with a parse error. A Configuration supplied through the configuration option of the xquery endpoint or language is used as is and is not modified. The 4.14.x releases stream and earlier, as well as 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.\u003c/p\u003e"
}
],
"value": "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. XQueryBuilder now builds its default Saxon Configuration with parse options that refuse a DOCTYPE declaration and disable external general entities, external parameter entities and external DTD loading, aligning a body that is already a javax.xml.transform.Source with the hardened parser configuration that Camel\u0027s XmlConverter applies to String, byte[] and InputStream bodies. A body that reaches XQuery as an already-built Source and carries a DOCTYPE declaration is now rejected with a parse error. A Configuration supplied through the configuration option of the xquery endpoint or language is used as is and is not modified. The 4.14.x releases stream and earlier, as well as 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."
}
],
"source": {
"discovery": "UNKNOWN"
},
"title": "Apache Camel: Camel-Saxon XML External Entity Processing - XQueryBuilder Parsed a Message Body That Was Already a javax.xml.transform.Source With Saxon\u0027s Default Parser Settings, so an External Entity Declared in That Body Was Resolved",
"workarounds": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eFor deployments that cannot upgrade immediately, do not evaluate XQuery over a message body that is already a javax.xml.transform.Source when that body carries XML from an untrusted sender. Alternatively, set the configuration option of the xquery endpoint or language to a Saxon Configuration whose parse options refuse a DOCTYPE declaration and disable external entities and external DTD loading, which is what the fixed releases now apply by default.\u003c/p\u003e"
}
],
"value": "For deployments that cannot upgrade immediately, do not evaluate XQuery over a message body that is already a javax.xml.transform.Source when that body carries XML from an untrusted sender. Alternatively, set the configuration option of the xquery endpoint or language to a Saxon Configuration whose parse options refuse a DOCTYPE declaration and disable external entities and external DTD loading, which is what the fixed releases now apply by default."
}
],
"x_generator": {
"engine": "Vulnogram 1.0.3"
}
}
},
"cveMetadata": {
"assignerOrgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
"assignerShortName": "apache",
"cveId": "CVE-2026-90885",
"datePublished": "2026-10-26T14:47:03.155Z",
"dateReserved": "2026-09-14T08:19:08.798Z",
"dateUpdated": "2026-10-26T15:35:49.414Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2026-94386 (GCVE-0-2026-94386)
Vulnerability from cvelistv5
Published
2026-10-26 14:46
Modified
2026-10-26 15:35
Severity ?
VLAI Severity ?
EPSS score ?
CWE
- CWE-524 - Use of Cache Containing Sensitive Information
Summary
Use of Cache Containing Sensitive Information vulnerability in Apache Camel Oauth component.
This issue affects Apache Camel: from 4.19.0 before 4.22.2.
OAuthClientCredentialsTokenResolver obtains OAuth 2.0 bearer tokens through the client credentials grant on behalf of the components that authenticate their outbound calls with a named OAuth profile, such as camel-openai, camel-langchain4j-agent, camel-huggingface, camel-docling, camel-a2a, camel-spring-ai-chat and the IBM watsonx components, and of applications that call the OAuthClientAuthenticationFactory SPI directly. It kept the tokens it obtained in a static cache shared by every resolver instance and every CamelContext in the JVM, and keyed that cache on the token endpoint and the client ID only, although the token request also carries the client secret and the requested scope. Two profiles that share a token endpoint and a client ID but request different scopes, or authenticate with different client secrets, therefore mapped to the same cache entry: the profile that resolved a token first populated the entry, and the other profile was then handed that token, with no token request made under its own configuration, for as long as the token remained valid. Token caching is enabled by default, and pointing several profiles at one identity provider client is an ordinary use of the profile support rather than an opt-in to an insecure setting. The outcome is an outbound request that carries a token issued for another profile's scope, which can grant broader authority than the calling profile was configured for, or reach a service the token was not issued for; with identity providers that derive a token's audience from the requested scope, a different scope can mean a token for a different service altogether. A profile configured with a different client secret was likewise served the token obtained with the other secret, without authenticating with its own. The profiles are configured by the deployment, which is trusted, so no untrusted input reaches the cache: the party that gains is the service that receives a token it was not meant to receive, which, if hostile or compromised, can replay that token within its scope. Reaching the issue requires a deployment that defines more than one profile sharing a token endpoint and client ID while differing in scope or client secret.
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. The 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, disable token caching on every OAuth profile that shares a token endpoint and client ID with another profile, by setting camel.oauth.NAME.cache-tokens=false for a named profile or camel.oauth.cache-tokens=false for the default one, so that each resolution requests a token with that profile’s own scope and client secret, at the cost of a token request on every resolution. Alternatively, register a separate client at the identity provider for each profile that needs a different scope or client secret, so that no two such profiles share a client ID.
References
| URL | Tags | |
|---|---|---|
Impacted products
| Vendor | Product | Version | ||
|---|---|---|---|---|
| Apache Software Foundation | Apache Camel |
Version: 4.19.0 |
{
"containers": {
"adp": [
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2026-94386",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "no"
},
{
"Technical Impact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-10-26T15:29:39.655802Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-10-26T15:35:49.712Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"collectionURL": "https://repo.maven.apache.org/maven2",
"defaultStatus": "unaffected",
"packageName": "org.apache.camel:camel-oauth",
"packageURL": "pkg:maven/org.apache.camel/camel-oauth",
"product": "Apache Camel",
"vendor": "Apache Software Foundation",
"versions": [
{
"lessThan": "4.22.2",
"status": "affected",
"version": "4.19.0",
"versionType": "maven"
}
]
}
],
"credits": [
{
"lang": "en",
"type": "finder",
"value": "Andrea Cosentino from Apache Software Foundation"
},
{
"lang": "en",
"type": "remediation developer",
"value": "Andrea Cosentino from Apache Software Foundation"
}
],
"descriptions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eUse of Cache Containing Sensitive Information vulnerability in Apache Camel Oauth component.\u003c/p\u003e\u003cp\u003eThis issue affects Apache Camel: from 4.19.0 before 4.22.2.\u003c/p\u003e\u003cp\u003eOAuthClientCredentialsTokenResolver obtains OAuth 2.0 bearer tokens through the client credentials grant on behalf of the components that authenticate their outbound calls with a named OAuth profile, such as camel-openai, camel-langchain4j-agent, camel-huggingface, camel-docling, camel-a2a, camel-spring-ai-chat and the IBM watsonx components, and of applications that call the OAuthClientAuthenticationFactory SPI directly. It kept the tokens it obtained in a static cache shared by every resolver instance and every CamelContext in the JVM, and keyed that cache on the token endpoint and the client ID only, although the token request also carries the client secret and the requested scope. Two profiles that share a token endpoint and a client ID but request different scopes, or authenticate with different client secrets, therefore mapped to the same cache entry: the profile that resolved a token first populated the entry, and the other profile was then handed that token, with no token request made under its own configuration, for as long as the token remained valid. Token caching is enabled by default, and pointing several profiles at one identity provider client is an ordinary use of the profile support rather than an opt-in to an insecure setting. The outcome is an outbound request that carries a token issued for another profile\u0027s scope, which can grant broader authority than the calling profile was configured for, or reach a service the token was not issued for; with identity providers that derive a token\u0027s audience from the requested scope, a different scope can mean a token for a different service altogether. A profile configured with a different client secret was likewise served the token obtained with the other secret, without authenticating with its own. The profiles are configured by the deployment, which is trusted, so no untrusted input reaches the cache: the party that gains is the service that receives a token it was not meant to receive, which, if hostile or compromised, can replay that token within its scope. Reaching the issue requires a deployment that defines more than one profile sharing a token endpoint and client ID while differing in scope or client secret.\u003c/p\u003e\u003cdiv\u003eUsers 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. The 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, disable token caching on every OAuth profile that shares a token endpoint and client ID with another profile, by setting camel.oauth.NAME.cache-tokens=false for a named profile or camel.oauth.cache-tokens=false for the default one, so that each resolution requests a token with that profile\u2019s own scope and client secret, at the cost of a token request on every resolution. Alternatively, register a separate client at the identity provider for each profile that needs a different scope or client secret, so that no two such profiles share a client ID.\u003c/div\u003e"
}
],
"value": "Use of Cache Containing Sensitive Information vulnerability in Apache Camel Oauth component.\n\n\n\nThis issue affects Apache Camel: from 4.19.0 before 4.22.2.\n\n\n\nOAuthClientCredentialsTokenResolver obtains OAuth 2.0 bearer tokens through the client credentials grant on behalf of the components that authenticate their outbound calls with a named OAuth profile, such as camel-openai, camel-langchain4j-agent, camel-huggingface, camel-docling, camel-a2a, camel-spring-ai-chat and the IBM watsonx components, and of applications that call the OAuthClientAuthenticationFactory SPI directly. It kept the tokens it obtained in a static cache shared by every resolver instance and every CamelContext in the JVM, and keyed that cache on the token endpoint and the client ID only, although the token request also carries the client secret and the requested scope. Two profiles that share a token endpoint and a client ID but request different scopes, or authenticate with different client secrets, therefore mapped to the same cache entry: the profile that resolved a token first populated the entry, and the other profile was then handed that token, with no token request made under its own configuration, for as long as the token remained valid. Token caching is enabled by default, and pointing several profiles at one identity provider client is an ordinary use of the profile support rather than an opt-in to an insecure setting. The outcome is an outbound request that carries a token issued for another profile\u0027s scope, which can grant broader authority than the calling profile was configured for, or reach a service the token was not issued for; with identity providers that derive a token\u0027s audience from the requested scope, a different scope can mean a token for a different service altogether. A profile configured with a different client secret was likewise served the token obtained with the other secret, without authenticating with its own. The profiles are configured by the deployment, which is trusted, so no untrusted input reaches the cache: the party that gains is the service that receives a token it was not meant to receive, which, if hostile or compromised, can replay that token within its scope. Reaching the issue requires a deployment that defines more than one profile sharing a token endpoint and client ID while differing in scope or client secret.\n\nUsers 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. The 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, disable token caching on every OAuth profile that shares a token endpoint and client ID with another profile, by setting camel.oauth.NAME.cache-tokens=false for a named profile or camel.oauth.cache-tokens=false for the default one, so that each resolution requests a token with that profile\u2019s own scope and client secret, at the cost of a token request on every resolution. Alternatively, register a separate client at the identity provider for each profile that needs a different scope or client secret, so that no two such profiles share a client ID."
}
],
"metrics": [
{
"cvssV3_1": {
"attackComplexity": "HIGH",
"attackVector": "NETWORK",
"availabilityImpact": "NONE",
"baseScore": 4.8,
"baseSeverity": "MEDIUM",
"confidentialityImpact": "LOW",
"integrityImpact": "LOW",
"privilegesRequired": "NONE",
"scope": "UNCHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N",
"version": "3.1"
},
"format": "CVSS",
"scenarios": [
{
"lang": "en",
"value": "GENERAL"
}
]
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-524",
"description": "CWE-524 Use of Cache Containing Sensitive Information",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-10-26T14:46:11.551Z",
"orgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
"shortName": "apache"
},
"references": [
{
"name": "Apache Camel Security Advisory - CVE-2026-94386",
"tags": [
"vendor-advisory"
],
"url": "https://camel.apache.org/security/CVE-2026-94386.html"
},
{
"name": "CAMEL-24872",
"tags": [
"issue-tracking"
],
"url": "https://issues.apache.org/jira/browse/CAMEL-24872"
},
{
"name": "Fix on main, released in 4.23.0 (commit 5e896b2df24bf80ad4a78be1f8a708f71d91aa16)",
"tags": [
"patch"
],
"url": "https://github.com/apache/camel/pull/26681"
},
{
"name": "Backport to camel-4.22.x for 4.22.2 (commit b2d9957bcbcf87bd5e59992fec45231876c645ed)",
"tags": [
"patch"
],
"url": "https://github.com/apache/camel/pull/27779"
},
{
"name": "CVE-2026-85317, the same class of defect in the camel-http OAuth2 client token cache",
"tags": [
"related"
],
"url": "https://camel.apache.org/security/CVE-2026-85317.html"
}
],
"solutions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eUpgrade to Apache Camel 4.23.0, which fixes the issue. Users on the 4.22.x stream should upgrade to 4.22.2. The 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 token cache is now keyed on every input of the token request: the token endpoint, the client ID, a SHA-256 fingerprint of the client secret, so that the raw secret is not kept in the cache, and the requested scope, so profiles that differ in credentials or scope obtain separate tokens while equivalent profiles still share one. The 4.18.x line and earlier never carried the client credentials token resolver and are not affected.\u003c/p\u003e"
}
],
"value": "Upgrade to Apache Camel 4.23.0, which fixes the issue. Users on the 4.22.x stream should upgrade to 4.22.2. The 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 token cache is now keyed on every input of the token request: the token endpoint, the client ID, a SHA-256 fingerprint of the client secret, so that the raw secret is not kept in the cache, and the requested scope, so profiles that differ in credentials or scope obtain separate tokens while equivalent profiles still share one. The 4.18.x line and earlier never carried the client credentials token resolver and are not affected."
}
],
"source": {
"discovery": "UNKNOWN"
},
"title": "Apache Camel: Camel-OAuth Cross-Scope Token Reuse via an Under-Keyed JVM-Global Client Credentials Token Cache",
"workarounds": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eDisable token caching on every OAuth profile that shares a token endpoint and client ID with another profile, by setting camel.oauth.NAME.cache-tokens=false for a named profile or camel.oauth.cache-tokens=false for the default one, so that each resolution requests a token with that profile\u0027s own scope and client secret, at the cost of a token request on every resolution. Alternatively, register a separate client at the identity provider for each profile that needs a different scope or client secret, so that no two such profiles share a client ID.\u003c/p\u003e"
}
],
"value": "Disable token caching on every OAuth profile that shares a token endpoint and client ID with another profile, by setting camel.oauth.NAME.cache-tokens=false for a named profile or camel.oauth.cache-tokens=false for the default one, so that each resolution requests a token with that profile\u0027s own scope and client secret, at the cost of a token request on every resolution. Alternatively, register a separate client at the identity provider for each profile that needs a different scope or client secret, so that no two such profiles share a client ID."
}
],
"x_generator": {
"engine": "Vulnogram 1.0.3"
}
}
},
"cveMetadata": {
"assignerOrgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
"assignerShortName": "apache",
"cveId": "CVE-2026-94386",
"datePublished": "2026-10-26T14:46:11.551Z",
"dateReserved": "2026-09-21T13:06:48.343Z",
"dateUpdated": "2026-10-26T15:35:49.712Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2026-95628 (GCVE-0-2026-95628)
Vulnerability from cvelistv5
Published
2026-10-26 08:48
Modified
2026-10-26 14:35
Severity ?
VLAI Severity ?
EPSS score ?
CWE
- CWE-22 - Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
Summary
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.
References
Impacted products
| Vendor | Product | Version | ||
|---|---|---|---|---|
| Apache Software Foundation | Apache Camel |
Version: 4.15.0 Version: 4.19.0 |
{
"containers": {
"adp": [
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2026-95628",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "no"
},
{
"Technical Impact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-10-26T14:12:52.898968Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-10-26T14:35:19.442Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"collectionURL": "https://repo.maven.apache.org/maven2",
"defaultStatus": "unaffected",
"packageName": "org.apache.camel:camel-docling",
"packageURL": "pkg:maven/org.apache.camel/camel-docling",
"product": "Apache Camel",
"vendor": "Apache Software Foundation",
"versions": [
{
"lessThan": "4.18.5",
"status": "affected",
"version": "4.15.0",
"versionType": "maven"
},
{
"lessThan": "4.22.2",
"status": "affected",
"version": "4.19.0",
"versionType": "maven"
}
]
}
],
"credits": [
{
"lang": "en",
"type": "finder",
"value": "Zhixi \"Jace\" Sun, independent security researcher"
},
{
"lang": "en",
"type": "remediation developer",
"value": "Andrea Cosentino"
}
],
"descriptions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eImproper Limitation of a Pathname to a Restricted Directory (\u0027Path Traversal\u0027) vulnerability in Apache Camel Docling component.\u003c/p\u003e\u003cp\u003eThis issue affects Apache Camel: from 4.15.0 before 4.18.5, from 4.19.0 before 4.22.2.\u003c/p\u003e\u003cp\u003eDoclingProducer 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\u0027s 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.\u003c/p\u003e\u003cp\u003eUsers 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.\u003c/p\u003e"
}
],
"value": "Improper Limitation of a Pathname to a Restricted Directory (\u0027Path Traversal\u0027) vulnerability in Apache Camel Docling component.\n\n\n\nThis issue affects Apache Camel: from 4.15.0 before 4.18.5, from 4.19.0 before 4.22.2.\n\n\n\nDoclingProducer 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\u0027s 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.\n\n\n\nUsers 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."
}
],
"metrics": [
{
"cvssV3_1": {
"attackComplexity": "LOW",
"attackVector": "NETWORK",
"availabilityImpact": "LOW",
"baseScore": 5.4,
"baseSeverity": "MEDIUM",
"confidentialityImpact": "NONE",
"integrityImpact": "LOW",
"privilegesRequired": "LOW",
"scope": "UNCHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:L",
"version": "3.1"
},
"format": "CVSS",
"scenarios": [
{
"lang": "en",
"value": "GENERAL"
}
]
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-22",
"description": "CWE-22 Improper Limitation of a Pathname to a Restricted Directory (\u0027Path Traversal\u0027)",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-10-26T08:48:48.344Z",
"orgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
"shortName": "apache"
},
"references": [
{
"name": "Apache Camel Security Advisory - CVE-2026-95628",
"tags": [
"vendor-advisory"
],
"url": "https://camel.apache.org/security/CVE-2026-95628.html"
},
{
"name": "CAMEL-24893",
"tags": [
"issue-tracking"
],
"url": "https://issues.apache.org/jira/browse/CAMEL-24893"
},
{
"name": "Fix on main, released in 4.23.0 (commit fd3bc8e73613f3aec691044ed07869ef79c1bf2f)",
"tags": [
"patch"
],
"url": "https://github.com/apache/camel/pull/26738"
},
{
"name": "Backport to camel-4.22.x for 4.22.2 (commit e9233c37c6127221157ac0901fb74250c5d24e98)",
"tags": [
"patch"
],
"url": "https://github.com/apache/camel/pull/26743"
},
{
"name": "Backport to camel-4.18.x, released in 4.18.5 (commit 59d30af17064320073e17cfb516be60d096bb979)",
"tags": [
"patch"
],
"url": "https://github.com/apache/camel/pull/26744"
},
{
"name": "CVE-2026-40047, the custom CLI argument validation issue whose fix this completes",
"tags": [
"related"
],
"url": "https://camel.apache.org/security/CVE-2026-40047.html"
},
{
"name": "CVE-2026-78163, a distinct input-source issue in the same producer",
"tags": [
"related"
],
"url": "https://camel.apache.org/security/CVE-2026-78163.html"
}
],
"solutions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eUpgrade to Apache Camel 4.23.0, which fixes the issue. Users on the 4.22.x stream should upgrade to 4.22.2 and users on the 4.18.x stream should upgrade to 4.18.5. The validatePathSafety helper now also rejects a path-like custom-argument value that is an absolute path, whether it is given as a separate list element or attached to its flag, so every path-valued flag on the allowlist is covered; a relative value without traversal segments is still accepted. 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.\u003c/p\u003e"
}
],
"value": "Upgrade to Apache Camel 4.23.0, which fixes the issue. Users on the 4.22.x stream should upgrade to 4.22.2 and users on the 4.18.x stream should upgrade to 4.18.5. The validatePathSafety helper now also rejects a path-like custom-argument value that is an absolute path, whether it is given as a separate list element or attached to its flag, so every path-valued flag on the allowlist is covered; a relative value without traversal segments is still accepted. 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."
}
],
"source": {
"discovery": "UNKNOWN"
},
"title": "Apache Camel: Camel-Docling Custom CLI Argument Path Validation Does Not Reject Absolute Paths (Incomplete Fix of CVE-2026-40047)",
"workarounds": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eDo 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.\u003c/p\u003e"
}
],
"value": "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."
}
],
"x_generator": {
"engine": "Vulnogram 1.0.3"
}
}
},
"cveMetadata": {
"assignerOrgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
"assignerShortName": "apache",
"cveId": "CVE-2026-95628",
"datePublished": "2026-10-26T08:48:48.344Z",
"dateReserved": "2026-09-22T11:01:34.300Z",
"dateUpdated": "2026-10-26T14:35:19.442Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2026-95629 (GCVE-0-2026-95629)
Vulnerability from cvelistv5
Published
2026-10-26 08:44
Modified
2026-10-26 08:44
Severity ?
VLAI Severity ?
EPSS score ?
CWE
- CWE-22 - Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
Summary
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.
References
| URL | Tags | ||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
|||||||||||||||||||||||
Impacted products
| Vendor | Product | Version | ||
|---|---|---|---|---|
| Apache Software Foundation | Apache Camel |
Version: 4.15.0 Version: 4.19.0 |
{
"containers": {
"cna": {
"affected": [
{
"collectionURL": "https://repo.maven.apache.org/maven2",
"defaultStatus": "unaffected",
"packageName": "org.apache.camel:camel-docling",
"packageURL": "pkg:maven/org.apache.camel/camel-docling",
"product": "Apache Camel",
"vendor": "Apache Software Foundation",
"versions": [
{
"lessThan": "4.18.5",
"status": "affected",
"version": "4.15.0",
"versionType": "maven"
},
{
"lessThan": "4.22.2",
"status": "affected",
"version": "4.19.0",
"versionType": "maven"
}
]
}
],
"credits": [
{
"lang": "en",
"type": "finder",
"value": "Zhixi \"Jace\" Sun, independent security researcher"
},
{
"lang": "en",
"type": "remediation developer",
"value": "Andrea Cosentino"
}
],
"descriptions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eImproper Limitation of a Pathname to a Restricted Directory (\u0027Path Traversal\u0027) vulnerability in Apache Camel Docling component.\u003c/p\u003e\u003cp\u003eThis issue affects Apache Camel: from 4.15.0 before 4.18.5, from 4.19.0 before 4.22.2.\u003c/p\u003e\u003cp\u003eDoclingProducer 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\u0027s 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.\u003c/p\u003e\u003cp\u003eUsers 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.\u003c/p\u003e"
}
],
"value": "Improper Limitation of a Pathname to a Restricted Directory (\u0027Path Traversal\u0027) vulnerability in Apache Camel Docling component.\n\n\n\nThis issue affects Apache Camel: from 4.15.0 before 4.18.5, from 4.19.0 before 4.22.2.\n\n\n\nDoclingProducer 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\u0027s 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.\n\n\n\nUsers 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."
}
],
"metrics": [
{
"cvssV3_1": {
"attackComplexity": "LOW",
"attackVector": "NETWORK",
"availabilityImpact": "LOW",
"baseScore": 5.4,
"baseSeverity": "MEDIUM",
"confidentialityImpact": "NONE",
"integrityImpact": "LOW",
"privilegesRequired": "LOW",
"scope": "UNCHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:L",
"version": "3.1"
},
"format": "CVSS",
"scenarios": [
{
"lang": "en",
"value": "GENERAL"
}
]
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-22",
"description": "CWE-22 Improper Limitation of a Pathname to a Restricted Directory (\u0027Path Traversal\u0027)",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-10-26T08:44:22.849Z",
"orgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
"shortName": "apache"
},
"references": [
{
"name": "Apache Camel Security Advisory - CVE-2026-95629",
"tags": [
"vendor-advisory"
],
"url": "https://camel.apache.org/security/CVE-2026-95629.html"
},
{
"name": "CAMEL-24894",
"tags": [
"issue-tracking"
],
"url": "https://issues.apache.org/jira/browse/CAMEL-24894"
},
{
"name": "Fix on main, released in 4.23.0 (commit 48485d408f190c46ef408ba4ba75e45b4e8ffb04)",
"tags": [
"patch"
],
"url": "https://github.com/apache/camel/pull/26737"
},
{
"name": "Backport to camel-4.22.x for 4.22.2 (commit 4f8eb14999163523af6b77d08bfd1b9e79ee49c0)",
"tags": [
"patch"
],
"url": "https://github.com/apache/camel/pull/27365"
},
{
"name": "Backport to camel-4.18.x, released in 4.18.5 (commit 54552df4b9e512cb2025fad22b88429ef0e0169c)",
"tags": [
"patch"
],
"url": "https://github.com/apache/camel/pull/27362"
},
{
"name": "CVE-2026-40047, whose custom-argument validation directs callers to the header described here",
"tags": [
"related"
],
"url": "https://camel.apache.org/security/CVE-2026-40047.html"
},
{
"name": "CVE-2026-78163, whose fix introduced the inputBaseDirectory option that outputBaseDirectory mirrors",
"tags": [
"related"
],
"url": "https://camel.apache.org/security/CVE-2026-78163.html"
}
],
"solutions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eUpgrade to Apache Camel 4.23.0, which fixes the issue. Users on the 4.22.x stream should upgrade to 4.22.2 and users on the 4.18.x stream should upgrade to 4.18.5. The CamelDoclingOutputFilePath header is now normalized before it reaches docling, and a new outputBaseDirectory endpoint option confines it: when the option is set, a value that resolves outside that directory, including an absolute path, is rejected with an IOException before docling is started. The option is unset by default, so it must be set after upgrading wherever the 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.\u003c/p\u003e"
}
],
"value": "Upgrade to Apache Camel 4.23.0, which fixes the issue. Users on the 4.22.x stream should upgrade to 4.22.2 and users on the 4.18.x stream should upgrade to 4.18.5. The CamelDoclingOutputFilePath header is now normalized before it reaches docling, and a new outputBaseDirectory endpoint option confines it: when the option is set, a value that resolves outside that directory, including an absolute path, is rejected with an IOException before docling is started. The option is unset by default, so it must be set after upgrading wherever the 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."
}
],
"source": {
"discovery": "UNKNOWN"
},
"title": "Apache Camel: Camel-Docling Unvalidated Output Path Header Enables Writing Conversion Output to an Arbitrary Directory",
"workarounds": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eDo 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.\u003c/p\u003e"
}
],
"value": "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."
}
],
"x_generator": {
"engine": "Vulnogram 1.0.3"
}
}
},
"cveMetadata": {
"assignerOrgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
"assignerShortName": "apache",
"cveId": "CVE-2026-95629",
"datePublished": "2026-10-26T08:44:22.849Z",
"dateReserved": "2026-09-22T11:04:06.573Z",
"dateUpdated": "2026-10-26T08:44:22.849Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2026-95663 (GCVE-0-2026-95663)
Vulnerability from cvelistv5
Published
2026-10-26 08:42
Modified
2026-10-26 08:42
Severity ?
VLAI Severity ?
EPSS score ?
CWE
- CWE-613 - Insufficient Session Expiration
Summary
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.
References
| URL | Tags | ||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
|||||||||||||||||||||||
Impacted products
| Vendor | Product | Version | ||
|---|---|---|---|---|
| Apache Software Foundation | Apache Camel |
Version: 4.16.0 Version: 4.19.0 |
{
"containers": {
"cna": {
"affected": [
{
"collectionURL": "https://repo.maven.apache.org/maven2",
"defaultStatus": "unaffected",
"packageName": "org.apache.camel:camel-keycloak",
"packageURL": "pkg:maven/org.apache.camel/camel-keycloak",
"product": "Apache Camel",
"vendor": "Apache Software Foundation",
"versions": [
{
"lessThan": "4.18.5",
"status": "affected",
"version": "4.16.0",
"versionType": "maven"
},
{
"lessThan": "4.22.2",
"status": "affected",
"version": "4.19.0",
"versionType": "maven"
}
]
}
],
"credits": [
{
"lang": "en",
"type": "finder",
"value": "Andrea Cosentino from Apache Software Foundation"
},
{
"lang": "en",
"type": "remediation developer",
"value": "Andrea Cosentino from Apache Software Foundation"
}
],
"descriptions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eInsufficient Session Expiration vulnerability in Apache Camel Keycloak component.\u003c/p\u003e\u003cp\u003eThis issue affects Apache Camel: from 4.16.0 before 4.18.5, from 4.19.0 before 4.22.2.\u003c/p\u003e\u003cp\u003eWhen 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\u0027s 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\u0027s 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\u0027s 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.\u003c/p\u003e\u003cp\u003eUsers 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.\u003c/p\u003e"
}
],
"value": "Insufficient Session Expiration vulnerability in Apache Camel Keycloak component.\n\n\n\nThis issue affects Apache Camel: from 4.16.0 before 4.18.5, from 4.19.0 before 4.22.2.\n\n\n\nWhen 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\u0027s 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\u0027s 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\u0027s 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.\n\n\n\nUsers 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."
}
],
"metrics": [
{
"cvssV3_1": {
"attackComplexity": "HIGH",
"attackVector": "NETWORK",
"availabilityImpact": "NONE",
"baseScore": 4.8,
"baseSeverity": "MEDIUM",
"confidentialityImpact": "LOW",
"integrityImpact": "LOW",
"privilegesRequired": "NONE",
"scope": "UNCHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N",
"version": "3.1"
},
"format": "CVSS",
"scenarios": [
{
"lang": "en",
"value": "GENERAL"
}
]
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-613",
"description": "CWE-613 Insufficient Session Expiration",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-10-26T08:42:17.403Z",
"orgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
"shortName": "apache"
},
"references": [
{
"name": "Apache Camel Security Advisory - CVE-2026-95663",
"tags": [
"vendor-advisory"
],
"url": "https://camel.apache.org/security/CVE-2026-95663.html"
},
{
"name": "CAMEL-24902",
"tags": [
"issue-tracking"
],
"url": "https://issues.apache.org/jira/browse/CAMEL-24902"
},
{
"name": "Fix on main, released in 4.23.0 (commit 7bfacb70d3300f97a130eda92b7b86ec5d8b11af)",
"tags": [
"patch"
],
"url": "https://github.com/apache/camel/pull/26747"
},
{
"name": "Backport to camel-4.22.x for 4.22.2 (commit 66fd7034911aebcaffa80bae4ece265feb2895bb)",
"tags": [
"patch"
],
"url": "https://github.com/apache/camel/pull/27182"
},
{
"name": "Backport to camel-4.18.x, released in 4.18.5 (commit 6be02c19c0259a983db5910e28deb4b3a00c9d22)",
"tags": [
"patch"
],
"url": "https://github.com/apache/camel/pull/27183"
},
{
"name": "CVE-2026-46455, expired tokens accepted on the local JWT verification path, distinct from this issue",
"tags": [
"related"
],
"url": "https://camel.apache.org/security/CVE-2026-46455.html"
},
{
"name": "CVE-2026-85301, issuer check skipped on the same introspection path, distinct from this issue",
"tags": [
"related"
],
"url": "https://camel.apache.org/security/CVE-2026-85301.html"
}
],
"solutions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eUsers 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. Both cache implementations now bound the lifetime of each entry by the shorter of introspectionCacheTtl and the time remaining until the token\u0027s exp, a result whose token has already expired is never served from the cache, and KeycloakSecurityProcessor now rejects a token whose exp lies in the past on every path that uses introspection, so expiry is enforced on the introspection path as it is on the local JWT verification path. The 4.16.x, 4.17.x and 4.19.x to 4.21.x releases streams reached end of life before this issue was resolved and will not receive a fix, so deployments on those lines must move to a supported release.\u003c/p\u003e"
}
],
"value": "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. Both cache implementations now bound the lifetime of each entry by the shorter of introspectionCacheTtl and the time remaining until the token\u0027s exp, a result whose token has already expired is never served from the cache, and KeycloakSecurityProcessor now rejects a token whose exp lies in the past on every path that uses introspection, so expiry is enforced on the introspection path as it is on the local JWT verification path. The 4.16.x, 4.17.x and 4.19.x to 4.21.x releases streams reached end of life before this issue was resolved and will not receive a fix, so deployments on those lines must move to a supported release."
}
],
"source": {
"discovery": "UNKNOWN"
},
"title": "Apache Camel: Camel-Keycloak Security Policy Accepts Expired Access Tokens Because Cached Token Introspection Results Are Not Bounded by the Token Expiry",
"workarounds": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eFor 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.\u003c/p\u003e"
}
],
"value": "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."
}
],
"x_generator": {
"engine": "Vulnogram 1.0.3"
}
}
},
"cveMetadata": {
"assignerOrgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
"assignerShortName": "apache",
"cveId": "CVE-2026-95663",
"datePublished": "2026-10-26T08:42:17.403Z",
"dateReserved": "2026-09-22T12:58:07.244Z",
"dateUpdated": "2026-10-26T08:42:17.403Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2026-95664 (GCVE-0-2026-95664)
Vulnerability from cvelistv5
Published
2026-10-26 08:40
Modified
2026-10-26 08:40
Severity ?
VLAI Severity ?
EPSS score ?
CWE
- CWE-917 - Improper Neutralization of Special Elements used in an Expression Language Statement ('Expression Language Injection')
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.
References
| URL | Tags | ||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
|||||||||||||||||||||||||||||||||||
Impacted products
| Vendor | Product | Version | ||
|---|---|---|---|---|
| Apache Software Foundation | Apache Camel |
Version: 4.8.0 Version: 4.19.0 |
{
"containers": {
"cna": {
"affected": [
{
"collectionURL": "https://repo.maven.apache.org/maven2",
"defaultStatus": "unaffected",
"packageName": "org.apache.camel:camel-aws2-s3",
"packageURL": "pkg:maven/org.apache.camel/camel-aws2-s3",
"product": "Apache Camel",
"vendor": "Apache Software Foundation",
"versions": [
{
"lessThan": "4.18.5",
"status": "affected",
"version": "4.8.0",
"versionType": "maven"
},
{
"lessThan": "4.22.2",
"status": "affected",
"version": "4.19.0",
"versionType": "maven"
}
]
}
],
"credits": [
{
"lang": "en",
"type": "finder",
"value": "Andrea Cosentino from Apache Software Foundation"
},
{
"lang": "en",
"type": "remediation developer",
"value": "Andrea Cosentino from Apache Software Foundation"
}
],
"descriptions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eImproper Neutralization of Special Elements used in an Expression Language Statement (\u0027Expression Language Injection\u0027) vulnerability in Apache Camel AWS2-s3 component.\u003c/p\u003e\u003cp\u003eThis issue affects Apache Camel: from 4.8.0 before 4.18.5, from 4.19.0 before 4.22.2.\u003c/p\u003e\u003cp\u003eFor 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.\u003c/p\u003e\u003cp\u003eUsers 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(\u201cCamelAwsS3Key\u201d), 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.\u003c/p\u003e"
}
],
"value": "Improper Neutralization of Special Elements used in an Expression Language Statement (\u0027Expression Language Injection\u0027) vulnerability in Apache Camel AWS2-s3 component.\n\n\n\nThis issue affects Apache Camel: from 4.8.0 before 4.18.5, from 4.19.0 before 4.22.2.\n\n\n\nFor 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.\n\n\n\nUsers 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(\u201cCamelAwsS3Key\u201d), 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."
}
],
"metrics": [
{
"cvssV3_1": {
"attackComplexity": "LOW",
"attackVector": "NETWORK",
"availabilityImpact": "NONE",
"baseScore": 5.4,
"baseSeverity": "MEDIUM",
"confidentialityImpact": "LOW",
"integrityImpact": "LOW",
"privilegesRequired": "LOW",
"scope": "UNCHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N",
"version": "3.1"
},
"format": "CVSS",
"scenarios": [
{
"lang": "en",
"value": "GENERAL"
}
]
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-917",
"description": "CWE-917 Improper Neutralization of Special Elements used in an Expression Language Statement (\u0027Expression Language Injection\u0027)",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-10-26T08:40:32.068Z",
"orgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
"shortName": "apache"
},
"references": [
{
"name": "Apache Camel Security Advisory - CVE-2026-95664",
"tags": [
"vendor-advisory"
],
"url": "https://camel.apache.org/security/CVE-2026-95664.html"
},
{
"name": "CAMEL-24901",
"tags": [
"issue-tracking"
],
"url": "https://issues.apache.org/jira/browse/CAMEL-24901"
},
{
"name": "Fix on main, released in 4.23.0 (commit 1fd7a667913ad068c8571b39c96b0a9c2dd4f3ef)",
"tags": [
"patch"
],
"url": "https://github.com/apache/camel/pull/26746"
},
{
"name": "Backport to camel-4.22.x for 4.22.2 (commit 19a672aa791480bff6b61c0551c79b2fa079da6e)",
"tags": [
"patch"
],
"url": "https://github.com/apache/camel/pull/26840"
},
{
"name": "Backport to camel-4.18.x, released in 4.18.5 (commit 124bf3da3cfb5d8e1994471e1301b6421bfe96d2)",
"tags": [
"patch"
],
"url": "https://github.com/apache/camel/pull/26842"
},
{
"name": "Upgrade-guide documentation for the 4.22.x and 4.18.x lines placed on main (commit aa48bb8a90adfae80a657a9ef427002d6634af31)",
"tags": [
"related"
],
"url": "https://github.com/apache/camel/pull/26841"
},
{
"name": "Javadoc of the header and configuration contract in AWS2S3Utils on main (commit 60c2c38b98ebbbaf56c10aff491291afe13df474)",
"tags": [
"related"
],
"url": "https://github.com/apache/camel/pull/26889"
},
{
"name": "CAMEL-20971, the dynamic key and bucket name support added in 4.8.0 that introduced the evaluation",
"tags": [
"related"
],
"url": "https://issues.apache.org/jira/browse/CAMEL-20971"
},
{
"name": "CVE-2026-78164, HTTP producers resolved property placeholders in message-supplied URI override headers (same family)",
"tags": [
"related"
],
"url": "https://camel.apache.org/security/CVE-2026-78164.html"
},
{
"name": "CVE-2026-83531, dynamic-router-control endpoint compiled predicate expressions supplied by control messages (same family)",
"tags": [
"related"
],
"url": "https://camel.apache.org/security/CVE-2026-83531.html"
},
{
"name": "CVE-2025-27636, Camel message header injection via improper filtering (distinct from this issue)",
"tags": [
"related"
],
"url": "https://camel.apache.org/security/CVE-2025-27636.html"
}
],
"solutions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eUsers 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. AWS2S3Utils.determineKey() and determineBucketName() now evaluate the Simple language only for the keyName and bucketName options configured on the endpoint, which the route author writes; a key supplied through the CamelAwsS3Key header, or a bucket name supplied through the CamelAwsS3OverrideBucketName header, is used literally. A route that put an unevaluated Simple expression in one of these headers 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.\u003c/p\u003e"
}
],
"value": "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. AWS2S3Utils.determineKey() and determineBucketName() now evaluate the Simple language only for the keyName and bucketName options configured on the endpoint, which the route author writes; a key supplied through the CamelAwsS3Key header, or a bucket name supplied through the CamelAwsS3OverrideBucketName header, is used literally. A route that put an unevaluated Simple expression in one of these headers 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."
}
],
"source": {
"discovery": "UNKNOWN"
},
"title": "Apache Camel: Camel-AWS2-S3 Producer Evaluates Untrusted S3 Object Keys From the CamelAwsS3Key Header as Simple Expressions",
"workarounds": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eFor 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(\u0026quot;CamelAwsS3Key\u0026quot;), 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.\u003c/p\u003e"
}
],
"value": "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."
}
],
"x_generator": {
"engine": "Vulnogram 1.0.3"
}
}
},
"cveMetadata": {
"assignerOrgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
"assignerShortName": "apache",
"cveId": "CVE-2026-95664",
"datePublished": "2026-10-26T08:40:32.068Z",
"dateReserved": "2026-09-22T12:59:19.318Z",
"dateUpdated": "2026-10-26T08:40:32.068Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2026-101259 (GCVE-0-2026-101259)
Vulnerability from cvelistv5
Published
2026-10-26 08:36
Modified
2026-10-26 08:36
Severity ?
VLAI Severity ?
EPSS score ?
CWE
- CWE-209 - Generation of Error Message Containing Sensitive Information
Summary
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.
References
| URL | Tags | ||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
|||||||||||||||||||||||||||||
Impacted products
| Vendor | Product | Version | ||
|---|---|---|---|---|
| Apache Software Foundation | Apache Camel |
Version: 4.0.0 Version: 4.19.0 |
{
"containers": {
"cna": {
"affected": [
{
"collectionURL": "https://repo.maven.apache.org/maven2",
"defaultStatus": "unaffected",
"packageName": "org.apache.camel:camel-coap",
"packageURL": "pkg:maven/org.apache.camel/camel-coap",
"product": "Apache Camel",
"vendor": "Apache Software Foundation",
"versions": [
{
"lessThan": "4.18.5",
"status": "affected",
"version": "4.0.0",
"versionType": "maven"
},
{
"lessThan": "4.22.2",
"status": "affected",
"version": "4.19.0",
"versionType": "maven"
}
]
}
],
"credits": [
{
"lang": "en",
"type": "finder",
"value": "Zhixi \"Jace\" Sun, independent security researcher"
},
{
"lang": "en",
"type": "remediation developer",
"value": "Andrea Cosentino"
}
],
"descriptions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eGeneration of Error Message Containing Sensitive Information vulnerability in Apache Camel CoAP component.\u003c/p\u003e\u003cp\u003eThis issue affects Apache Camel: from 4.0.0 before 4.18.5, from 4.19.0 before 4.22.2.\u003c/p\u003e\u003cp\u003eWhen 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\u0027s error handler. On the affected releases the message of such a failure names the class of the value being converted, carries the value\u0027s 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.\u003c/p\u003e\u003cp\u003eUsers 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.\u003c/p\u003e"
}
],
"value": "Generation of Error Message Containing Sensitive Information vulnerability in Apache Camel CoAP component.\n\n\n\nThis issue affects Apache Camel: from 4.0.0 before 4.18.5, from 4.19.0 before 4.22.2.\n\n\n\nWhen 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\u0027s error handler. On the affected releases the message of such a failure names the class of the value being converted, carries the value\u0027s 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.\n\n\n\nUsers 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."
}
],
"metrics": [
{
"cvssV3_1": {
"attackComplexity": "LOW",
"attackVector": "NETWORK",
"availabilityImpact": "NONE",
"baseScore": 5.3,
"baseSeverity": "MEDIUM",
"confidentialityImpact": "LOW",
"integrityImpact": "NONE",
"privilegesRequired": "NONE",
"scope": "UNCHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N",
"version": "3.1"
},
"format": "CVSS",
"scenarios": [
{
"lang": "en",
"value": "GENERAL"
}
]
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-209",
"description": "CWE-209 Generation of Error Message Containing Sensitive Information",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-10-26T08:36:47.439Z",
"orgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
"shortName": "apache"
},
"references": [
{
"name": "Apache Camel Security Advisory - CVE-2026-101259",
"tags": [
"vendor-advisory"
],
"url": "https://camel.apache.org/security/CVE-2026-101259.html"
},
{
"name": "CAMEL-25087",
"tags": [
"issue-tracking"
],
"url": "https://issues.apache.org/jira/browse/CAMEL-25087"
},
{
"name": "Fix on main, released in 4.23.0 (commit 2245feac8f4f9a85404b01d36114abdac504e7d1)",
"tags": [
"patch"
],
"url": "https://github.com/apache/camel/pull/26994"
},
{
"name": "Backport to camel-4.22.x for 4.22.2 (commit 868d56044119a8a975f583b63aeb9666cd952a88)",
"tags": [
"patch"
],
"url": "https://github.com/apache/camel/pull/27046"
},
{
"name": "Backport to camel-4.18.x, released in 4.18.5 (commit aaf5bbf81ede12837c9c65fa9106643fcb58b7c4)",
"tags": [
"patch"
],
"url": "https://github.com/apache/camel/pull/27048"
},
{
"name": "CVE-2026-84180, the camel-knative member of the same unmuted-consumer-exception family",
"tags": [
"related"
],
"url": "https://camel.apache.org/security/CVE-2026-84180.html"
},
{
"name": "CVE-2026-85246, the camel-mina member of the same unmuted-consumer-exception family",
"tags": [
"related"
],
"url": "https://camel.apache.org/security/CVE-2026-85246.html"
},
{
"name": "CVE-2026-85257, the camel-cxf member of the same unmuted-consumer-exception family",
"tags": [
"related"
],
"url": "https://camel.apache.org/security/CVE-2026-85257.html"
},
{
"name": "CVE-2026-85315, the camel-grpc member of the same unmuted-consumer-exception family",
"tags": [
"related"
],
"url": "https://camel.apache.org/security/CVE-2026-85315.html"
}
],
"solutions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eUsers 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 a muteException consumer option to the coap, coaps, coap+tcp and coaps+tcp endpoints, defaulting to true on all three release lines, so the upgrade is enough on its own and the error response carries no payload without any configuration change. An exception raised while the response is built is answered with an empty 5.00 Internal Server Error and reported through the consumer\u0027s exception handler, and a failed exchange, previously answered with 2.05 Content and the body the message held when the route failed, is now answered with 5.00 Internal Server Error under the same rule. Setting muteException=false sends the exception\u0027s message as the payload of the 5.00 response, for a route failure as well. 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.\u003c/p\u003e"
}
],
"value": "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 a muteException consumer option to the coap, coaps, coap+tcp and coaps+tcp endpoints, defaulting to true on all three release lines, so the upgrade is enough on its own and the error response carries no payload without any configuration change. An exception raised while the response is built is answered with an empty 5.00 Internal Server Error and reported through the consumer\u0027s exception handler, and a failed exchange, previously answered with 2.05 Content and the body the message held when the route failed, is now answered with 5.00 Internal Server Error under the same rule. Setting muteException=false sends the exception\u0027s message as the payload of the 5.00 response, for a route failure as well. 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."
}
],
"source": {
"discovery": "UNKNOWN"
},
"title": "Apache Camel: Camel-CoAP Information Disclosure via Unmuted Consumer Exceptions",
"workarounds": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eFor 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.\u003c/p\u003e"
}
],
"value": "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."
}
],
"x_generator": {
"engine": "Vulnogram 1.0.3"
}
}
},
"cveMetadata": {
"assignerOrgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
"assignerShortName": "apache",
"cveId": "CVE-2026-101259",
"datePublished": "2026-10-26T08:36:47.439Z",
"dateReserved": "2026-09-28T11:17:22.256Z",
"dateUpdated": "2026-10-26T08:36:47.439Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2026-88900 (GCVE-0-2026-88900)
Vulnerability from cvelistv5
Published
2026-10-19 11:07
Modified
2026-10-20 03:55
Severity ?
VLAI Severity ?
EPSS score ?
CWE
- CWE-502 - Deserialization of Untrusted Data
Summary
Deserialization of Untrusted Data vulnerability in Apache Camel Camel-Jgroups component.
This issue affects Apache Camel: from 4.0.0 before 4.18.5, from 4.19.0 before 4.22.1.
JGroupsEndpoint.createExchange(Message), which CamelJGroupsReceiver calls for every message the jgroups consumer receives before the exchange is routed, set the exchange body from org.jgroups.Message.getObject(). For an ObjectMessage, which is the message type the Camel jgroups producer sends, JGroups Java-deserializes the payload through an ObjectInputStream on its own receive thread as the message arrives, and getObject() returns the resulting object. No java.io.ObjectInputFilter was applied on that path unless the deployment had set a JVM-wide serialization filter: camel-jgroups installed none, and the JGroups versions shipped with the affected releases apply none of their own, so any serializable class on the application classpath could be instantiated and its deserialization callbacks run. Unless a channel or the channelProperties option is configured, the consumer creates its channel with new JChannel(), the stock JGroups protocol stack, which multicasts over UDP without the AUTH protocol and without encryption, so any host able to reach the cluster's multicast group or bind port can join the cluster and send messages to the consumer without credentials. Such a host could send a crafted serialized object that leads to remote code execution in the Camel process when a usable deserialization gadget chain is present on the classpath, and no non-default option was required on the consumer. Because JGroups materializes the object before Camel's receiver runs, a check performed by Camel can only inspect the deserialized result and cannot stop code that runs during deserialization, so closing the issue also requires a control that applies before the payload is read, as described in the mitigation. Exploitation requires network access to the cluster's multicast group or bind port, which with the default UDP multicast transport means a host on an adjacent network, and a usable gadget chain on the classpath, which is why the severity is assessed as high rather than critical.
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.1. 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 those lines must move to a supported release.
References
| URL | Tags | |||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
||||||||||||||||||||||||||||||||
Impacted products
| Vendor | Product | Version | ||
|---|---|---|---|---|
| Apache Software Foundation | Apache Camel |
Version: 4.0.0 Version: 4.19.0 |
{
"containers": {
"adp": [
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2026-88900",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "no"
},
{
"Technical Impact": "total"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-10-19T00:00:00+00:00",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-10-20T03:55:30.209Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"collectionURL": "https://repo.maven.apache.org/maven2",
"defaultStatus": "unaffected",
"packageName": "org.apache.camel:camel-jgroups",
"packageURL": "pkg:maven/org.apache.camel/camel-jgroups",
"product": "Apache Camel",
"vendor": "Apache Software Foundation",
"versions": [
{
"lessThan": "4.18.5",
"status": "affected",
"version": "4.0.0",
"versionType": "maven"
},
{
"lessThan": "4.22.1",
"status": "affected",
"version": "4.19.0",
"versionType": "maven"
}
]
}
],
"credits": [
{
"lang": "en",
"type": "finder",
"value": "h1ei1"
},
{
"lang": "en",
"type": "remediation developer",
"value": "Andrea Cosentino"
}
],
"descriptions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eDeserialization of Untrusted Data vulnerability in Apache Camel Camel-Jgroups component.\u003c/p\u003e\u003cp\u003eThis issue affects Apache Camel: from 4.0.0 before 4.18.5, from 4.19.0 before 4.22.1.\u003c/p\u003e\u003cp\u003eJGroupsEndpoint.createExchange(Message), which CamelJGroupsReceiver calls for every message the jgroups consumer receives before the exchange is routed, set the exchange body from org.jgroups.Message.getObject(). For an ObjectMessage, which is the message type the Camel jgroups producer sends, JGroups Java-deserializes the payload through an ObjectInputStream on its own receive thread as the message arrives, and getObject() returns the resulting object. No java.io.ObjectInputFilter was applied on that path unless the deployment had set a JVM-wide serialization filter: camel-jgroups installed none, and the JGroups versions shipped with the affected releases apply none of their own, so any serializable class on the application classpath could be instantiated and its deserialization callbacks run. Unless a channel or the channelProperties option is configured, the consumer creates its channel with new JChannel(), the stock JGroups protocol stack, which multicasts over UDP without the AUTH protocol and without encryption, so any host able to reach the cluster\u0027s multicast group or bind port can join the cluster and send messages to the consumer without credentials. Such a host could send a crafted serialized object that leads to remote code execution in the Camel process when a usable deserialization gadget chain is present on the classpath, and no non-default option was required on the consumer. Because JGroups materializes the object before Camel\u0027s receiver runs, a check performed by Camel can only inspect the deserialized result and cannot stop code that runs during deserialization, so closing the issue also requires a control that applies before the payload is read, as described in the mitigation. Exploitation requires network access to the cluster\u0027s multicast group or bind port, which with the default UDP multicast transport means a host on an adjacent network, and a usable gadget chain on the classpath, which is why the severity is assessed as high rather than critical.\u003c/p\u003e\u003cp\u003eUsers 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.1. 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 those lines must move to a supported release.\u003c/p\u003e"
}
],
"value": "Deserialization of Untrusted Data vulnerability in Apache Camel Camel-Jgroups component.\n\n\n\nThis issue affects Apache Camel: from 4.0.0 before 4.18.5, from 4.19.0 before 4.22.1.\n\n\n\nJGroupsEndpoint.createExchange(Message), which CamelJGroupsReceiver calls for every message the jgroups consumer receives before the exchange is routed, set the exchange body from org.jgroups.Message.getObject(). For an ObjectMessage, which is the message type the Camel jgroups producer sends, JGroups Java-deserializes the payload through an ObjectInputStream on its own receive thread as the message arrives, and getObject() returns the resulting object. No java.io.ObjectInputFilter was applied on that path unless the deployment had set a JVM-wide serialization filter: camel-jgroups installed none, and the JGroups versions shipped with the affected releases apply none of their own, so any serializable class on the application classpath could be instantiated and its deserialization callbacks run. Unless a channel or the channelProperties option is configured, the consumer creates its channel with new JChannel(), the stock JGroups protocol stack, which multicasts over UDP without the AUTH protocol and without encryption, so any host able to reach the cluster\u0027s multicast group or bind port can join the cluster and send messages to the consumer without credentials. Such a host could send a crafted serialized object that leads to remote code execution in the Camel process when a usable deserialization gadget chain is present on the classpath, and no non-default option was required on the consumer. Because JGroups materializes the object before Camel\u0027s receiver runs, a check performed by Camel can only inspect the deserialized result and cannot stop code that runs during deserialization, so closing the issue also requires a control that applies before the payload is read, as described in the mitigation. Exploitation requires network access to the cluster\u0027s multicast group or bind port, which with the default UDP multicast transport means a host on an adjacent network, and a usable gadget chain on the classpath, which is why the severity is assessed as high rather than critical.\n\n\n\nUsers 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.1. 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 those lines must move to a supported release."
}
],
"metrics": [
{
"cvssV3_1": {
"attackComplexity": "LOW",
"attackVector": "ADJACENT_NETWORK",
"availabilityImpact": "HIGH",
"baseScore": 8.8,
"baseSeverity": "HIGH",
"confidentialityImpact": "HIGH",
"integrityImpact": "HIGH",
"privilegesRequired": "NONE",
"scope": "UNCHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
"version": "3.1"
},
"format": "CVSS",
"scenarios": [
{
"lang": "en",
"value": "GENERAL"
}
]
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-502",
"description": "CWE-502 Deserialization of Untrusted Data",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-10-19T11:07:34.371Z",
"orgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
"shortName": "apache"
},
"references": [
{
"name": "Apache Camel Security Advisory - CVE-2026-88900",
"tags": [
"vendor-advisory"
],
"url": "https://camel.apache.org/security/CVE-2026-88900.html"
},
{
"name": "CAMEL-24676",
"tags": [
"issue-tracking"
],
"url": "https://issues.apache.org/jira/browse/CAMEL-24676"
},
{
"name": "CAMEL-25223",
"tags": [
"issue-tracking"
],
"url": "https://issues.apache.org/jira/browse/CAMEL-25223"
},
{
"name": "Fix on main, released in 4.23.0 (commit 0ef94ee8feabf56a5c595c07b2c60f64a73ba14e)",
"tags": [
"patch"
],
"url": "https://github.com/apache/camel/pull/26267"
},
{
"name": "Backport to camel-4.22.x, released in 4.22.1 (commit da07367d1b6e2bb00ddb6afa5cfa08a6c0c0bd0f)",
"tags": [
"patch"
],
"url": "https://github.com/apache/camel/pull/26281"
},
{
"name": "Backport to camel-4.18.x, released in 4.18.5 (commit f988494d01145473551ca75fc11cda3e5cb49f2d)",
"tags": [
"patch"
],
"url": "https://github.com/apache/camel/pull/26283"
},
{
"name": "Follow-up start-up guard on main, released in 4.23.0 (commit d30328a49596a04add88d32ee7ed923811c58866)",
"tags": [
"patch"
],
"url": "https://github.com/apache/camel/pull/27205"
},
{
"name": "Upgrade-guide entry for 4.22.1 placed on main (commit f02cde41ea679f8a3582b639b0ddd99ab723b4f0)",
"tags": [
"related"
],
"url": "https://github.com/apache/camel/pull/26282"
},
{
"name": "Upgrade-guide entry for 4.18.5 placed on main (commit d858054b98739eebf1a89f690558e1c54f09c45a)",
"tags": [
"related"
],
"url": "https://github.com/apache/camel/pull/26326"
},
{
"name": "Apache Camel Security Advisory - CVE-2026-40860",
"tags": [
"related"
],
"url": "https://camel.apache.org/security/CVE-2026-40860.html"
}
],
"solutions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eUsers 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.1. If users are on the 4.18.x releases stream, then they are suggested to upgrade to 4.18.5. The fixed releases check the class of the deserialized body against the deserializationFilter option before the exchange is routed; when the option is not set, the JVM-wide jdk.serialFilter is honoured if present, and otherwise the default allow-list !java.net.**;java.**;javax.**;org.apache.camel.**;!* is applied. Because this check runs after JGroups has deserialized the payload, it is defense in depth, and deployments on 4.22.1 and 4.18.5 must also configure at least one control that applies before the payload is read: a JVM-wide jdk.serialFilter that allows only the classes the routes exchange over the cluster, or a channel secured with AUTH together with SYM_ENCRYPT or ASYM_ENCRYPT through the channelProperties option. On 4.23.0, which ships JGroups 5.5.7.Final and so also honours the jgroups.deserialization.filter system property, the consumer refuses to start until at least one of these controls is configured, unless acceptAllObjects=true, an insecure serialization setting that restores the previous behaviour, is set. 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 those lines must move to a supported release.\u003c/p\u003e"
}
],
"value": "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.1. If users are on the 4.18.x releases stream, then they are suggested to upgrade to 4.18.5. The fixed releases check the class of the deserialized body against the deserializationFilter option before the exchange is routed; when the option is not set, the JVM-wide jdk.serialFilter is honoured if present, and otherwise the default allow-list !java.net.**;java.**;javax.**;org.apache.camel.**;!* is applied. Because this check runs after JGroups has deserialized the payload, it is defense in depth, and deployments on 4.22.1 and 4.18.5 must also configure at least one control that applies before the payload is read: a JVM-wide jdk.serialFilter that allows only the classes the routes exchange over the cluster, or a channel secured with AUTH together with SYM_ENCRYPT or ASYM_ENCRYPT through the channelProperties option. On 4.23.0, which ships JGroups 5.5.7.Final and so also honours the jgroups.deserialization.filter system property, the consumer refuses to start until at least one of these controls is configured, unless acceptAllObjects=true, an insecure serialization setting that restores the previous behaviour, is set. 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 those lines must move to a supported release."
}
],
"source": {
"discovery": "UNKNOWN"
},
"title": "Apache Camel: Camel-JGroups: Unsafe Java Deserialization of Cluster Messages in the JGroups Consumer Can Lead to Remote Code Execution",
"workarounds": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eFor deployments that cannot upgrade immediately, set a JVM-wide serialization filter with the jdk.serialFilter system property on the JVM that runs the jgroups consumer, allowing only the classes the routes exchange over the cluster, which applies because JGroups reads the payload through a java.io.ObjectInputStream; secure the channel by supplying, through the channelProperties option, a protocol stack that adds the AUTH protocol together with SYM_ENCRYPT or ASYM_ENCRYPT; and do not expose the cluster\u0027s multicast group or bind port to untrusted networks.\u003c/p\u003e"
}
],
"value": "For deployments that cannot upgrade immediately, set a JVM-wide serialization filter with the jdk.serialFilter system property on the JVM that runs the jgroups consumer, allowing only the classes the routes exchange over the cluster, which applies because JGroups reads the payload through a java.io.ObjectInputStream; secure the channel by supplying, through the channelProperties option, a protocol stack that adds the AUTH protocol together with SYM_ENCRYPT or ASYM_ENCRYPT; and do not expose the cluster\u0027s multicast group or bind port to untrusted networks."
}
],
"x_generator": {
"engine": "Vulnogram 1.0.3"
}
}
},
"cveMetadata": {
"assignerOrgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
"assignerShortName": "apache",
"cveId": "CVE-2026-88900",
"datePublished": "2026-10-19T11:07:34.371Z",
"dateReserved": "2026-09-10T11:43:06.921Z",
"dateUpdated": "2026-10-20T03:55:30.209Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2026-91858 (GCVE-0-2026-91858)
Vulnerability from cvelistv5
Published
2026-10-19 10:47
Modified
2026-10-19 14:30
Severity ?
VLAI Severity ?
EPSS score ?
CWE
- CWE-611 - Improper Restriction of XML External Entity Reference
Summary
FopProducer transforms the incoming XSL-FO message body by creating a javax.xml.transform.TransformerFactory through TransformerFactory.newInstance() and enabling only FEATURE_SECURE_PROCESSING before running an identity transform over the body. On the JDK's built-in transformer, that feature alone already empties the accessExternalDTD and accessExternalStylesheet limits, so an external DTD or entity is refused. When a third-party JAXP TransformerFactory such as Saxon-HE is on the classpath, for example because the application also uses camel-xslt-saxon or camel-saxon, TransformerFactory.newInstance() returns that implementation instead, and FEATURE_SECURE_PROCESSING on its own does not restrict external resource access on it. A DOCTYPE with an external subset, or an external general entity, declared in the XSL-FO document is then resolved and expanded while the body is transformed. An external sender whose XSL-FO reaches a fop producer could therefore read files readable by the Camel process and cause the process to issue requests to hosts the document names. camel-fop does not bring such a factory itself, and excludes Xalan, so a default deployment using the JDK transformer is not affected; the issue is reachable only where another component has placed an alternative JAXP TransformerFactory on the classpath. Releases on the 4.14.x line and earlier reached end of life before this issue was resolved and do not receive a fix.
References
| URL | Tags | |
|---|---|---|
Impacted products
| Vendor | Product | Version | ||
|---|---|---|---|---|
| Apache Software Foundation | Apache Camel |
Version: 4.0.0 Version: 4.19.0 |
{
"containers": {
"adp": [
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2026-91858",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "no"
},
{
"Technical Impact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-10-19T14:29:43.649018Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-10-19T14:30:10.376Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"collectionURL": "https://repo.maven.apache.org/maven2",
"defaultStatus": "unaffected",
"packageName": "org.apache.camel:camel-fop",
"packageURL": "pkg:maven/org.apache.camel/camel-fop",
"product": "Apache Camel",
"vendor": "Apache Software Foundation",
"versions": [
{
"lessThan": "4.18.5",
"status": "affected",
"version": "4.0.0",
"versionType": "maven"
},
{
"lessThan": "4.22.1",
"status": "affected",
"version": "4.19.0",
"versionType": "maven"
}
]
}
],
"credits": [
{
"lang": "en",
"type": "finder",
"value": "Andrea Cosentino"
},
{
"lang": "en",
"type": "remediation developer",
"value": "Andrea Cosentino"
}
],
"descriptions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eFopProducer transforms the incoming XSL-FO message body by creating a javax.xml.transform.TransformerFactory through TransformerFactory.newInstance() and enabling only FEATURE_SECURE_PROCESSING before running an identity transform over the body. On the JDK\u0027s built-in transformer, that feature alone already empties the accessExternalDTD and accessExternalStylesheet limits, so an external DTD or entity is refused. When a third-party JAXP TransformerFactory such as Saxon-HE is on the classpath, for example because the application also uses camel-xslt-saxon or camel-saxon, TransformerFactory.newInstance() returns that implementation instead, and FEATURE_SECURE_PROCESSING on its own does not restrict external resource access on it. A DOCTYPE with an external subset, or an external general entity, declared in the XSL-FO document is then resolved and expanded while the body is transformed. An external sender whose XSL-FO reaches a fop producer could therefore read files readable by the Camel process and cause the process to issue requests to hosts the document names. camel-fop does not bring such a factory itself, and excludes Xalan, so a default deployment using the JDK transformer is not affected; the issue is reachable only where another component has placed an alternative JAXP TransformerFactory on the classpath. Releases on the 4.14.x line and earlier reached end of life before this issue was resolved and do not receive a fix.\u003c/p\u003e"
}
],
"value": "FopProducer transforms the incoming XSL-FO message body by creating a javax.xml.transform.TransformerFactory through TransformerFactory.newInstance() and enabling only FEATURE_SECURE_PROCESSING before running an identity transform over the body. On the JDK\u0027s built-in transformer, that feature alone already empties the accessExternalDTD and accessExternalStylesheet limits, so an external DTD or entity is refused. When a third-party JAXP TransformerFactory such as Saxon-HE is on the classpath, for example because the application also uses camel-xslt-saxon or camel-saxon, TransformerFactory.newInstance() returns that implementation instead, and FEATURE_SECURE_PROCESSING on its own does not restrict external resource access on it. A DOCTYPE with an external subset, or an external general entity, declared in the XSL-FO document is then resolved and expanded while the body is transformed. An external sender whose XSL-FO reaches a fop producer could therefore read files readable by the Camel process and cause the process to issue requests to hosts the document names. camel-fop does not bring such a factory itself, and excludes Xalan, so a default deployment using the JDK transformer is not affected; the issue is reachable only where another component has placed an alternative JAXP TransformerFactory on the classpath. Releases on the 4.14.x line and earlier reached end of life before this issue was resolved and do not receive a fix."
}
],
"metrics": [
{
"cvssV3_1": {
"attackComplexity": "HIGH",
"attackVector": "NETWORK",
"availabilityImpact": "NONE",
"baseScore": 6.5,
"baseSeverity": "MEDIUM",
"confidentialityImpact": "HIGH",
"integrityImpact": "LOW",
"privilegesRequired": "NONE",
"scope": "UNCHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:L/A:N",
"version": "3.1"
},
"format": "CVSS",
"scenarios": [
{
"lang": "en",
"value": "GENERAL"
}
]
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-611",
"description": "CWE-611 Improper Restriction of XML External Entity Reference",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-10-19T10:47:48.267Z",
"orgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
"shortName": "apache"
},
"references": [
{
"name": "Apache Camel Security Advisory - CVE-2026-91858",
"tags": [
"vendor-advisory"
],
"url": "https://camel.apache.org/security/CVE-2026-91858.html"
},
{
"name": "CAMEL-24605",
"tags": [
"issue-tracking"
],
"url": "https://issues.apache.org/jira/browse/CAMEL-24605"
},
{
"name": "Fix on main, released in 4.23.0 (commit 209c67a851d3c145583d25829b7ffac0c500674b)",
"tags": [
"patch"
],
"url": "https://github.com/apache/camel/pull/26108"
},
{
"name": "Backport to camel-4.22.x, released in 4.22.1 (commit f689a9c92f0e6c406f9a0256c7d940024cf56782)",
"tags": [
"patch"
],
"url": "https://github.com/apache/camel/pull/26168"
},
{
"name": "Backport to camel-4.18.x, released in 4.18.5 (commit 9c06c6d265d70be30023e7514456b697e91db69e)",
"tags": [
"patch"
],
"url": "https://github.com/apache/camel/pull/26169"
}
],
"solutions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eUsers 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.1. If users are on the 4.18.x releases stream, then they are suggested to upgrade to 4.18.5. FopProducer now also sets ACCESS_EXTERNAL_DTD and ACCESS_EXTERNAL_STYLESHEET to the empty string on the TransformerFactory it creates, in addition to FEATURE_SECURE_PROCESSING, matching the secure XML processing configuration used by org.apache.camel.converter.jaxp.XmlConverter, so external DTD and stylesheet access is refused on any JAXP implementation that honours those attributes. The 4.14.x releases stream and earlier reached end of life before this issue was resolved and will not receive a fix, so deployments on those lines must move to a supported release.\u003c/p\u003e"
}
],
"value": "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.1. If users are on the 4.18.x releases stream, then they are suggested to upgrade to 4.18.5. FopProducer now also sets ACCESS_EXTERNAL_DTD and ACCESS_EXTERNAL_STYLESHEET to the empty string on the TransformerFactory it creates, in addition to FEATURE_SECURE_PROCESSING, matching the secure XML processing configuration used by org.apache.camel.converter.jaxp.XmlConverter, so external DTD and stylesheet access is refused on any JAXP implementation that honours those attributes. The 4.14.x releases stream and earlier reached end of life before this issue was resolved and will not receive a fix, so deployments on those lines must move to a supported release."
}
],
"source": {
"discovery": "UNKNOWN"
},
"title": "Apache Camel: Camel-FOP Resolves External DTDs and Entities From Untrusted XSL-FO Input When a Third-Party JAXP TransformerFactory Is Present",
"workarounds": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eFor deployments that cannot upgrade immediately, do not send untrusted XSL-FO to a fop producer. Alternatively, remove the third-party JAXP TransformerFactory such as Saxon-HE from the classpath, so that the JDK\u0027s built-in transformer is used, which already refuses external DTDs and external entities when secure processing is enabled.\u003c/p\u003e"
}
],
"value": "For deployments that cannot upgrade immediately, do not send untrusted XSL-FO to a fop producer. Alternatively, remove the third-party JAXP TransformerFactory such as Saxon-HE from the classpath, so that the JDK\u0027s built-in transformer is used, which already refuses external DTDs and external entities when secure processing is enabled."
}
],
"x_generator": {
"engine": "Vulnogram 1.0.3"
}
}
},
"cveMetadata": {
"assignerOrgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
"assignerShortName": "apache",
"cveId": "CVE-2026-91858",
"datePublished": "2026-10-19T10:47:48.267Z",
"dateReserved": "2026-09-15T09:22:12.094Z",
"dateUpdated": "2026-10-19T14:30:10.376Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2026-88901 (GCVE-0-2026-88901)
Vulnerability from cvelistv5
Published
2026-10-19 10:44
Modified
2026-10-19 14:30
Severity ?
VLAI Severity ?
EPSS score ?
CWE
- CWE-611 - Improper Restriction of XML External Entity Reference
Summary
Improper Restriction of XML External Entity Reference vulnerability in Apache Camel.
This issue affects Apache Camel: from 4.7.0 before 4.18.5, from 4.19.0 before 4.22.1.
Improper Restriction of XML External Entity Reference in the Smooks component (camel-smooks) in Apache Camel allows an attacker who supplies the XML message body to read local files or issue requests to internal network locations via an external entity declaration in that body. This issue affects Apache Camel: from 4.7.0 before 4.18.5, from 4.19.0 before 4.22.1. The Smooks data format (.unmarshal().smooks(...)) and the Smooks component (smooks:) parse the incoming XML body with the reader Smooks resolves by default, which is the Woodstox SAX parser. That reader resolves external general and parameter entities and loads external DTDs, and camel-smooks applied none of the parser hardening that the other Camel XML components apply. A DOCTYPE with an external subset, or an external general entity, declared in the XML document is therefore resolved and expanded while the body is unmarshalled, and the resolved content is bound into the unmarshalled result and returned on InOut routes. An external sender whose XML reaches a camel-smooks data format or endpoint could therefore read files readable by the Camel process and cause the process to issue requests to hosts the document names. No non-default option is required, since resolving external entities was the default behaviour. Configurations that declare their own reader - EDI, CSV, JSON, or a custom reader - do not use the XML reader and are not affected. Users are recommended to upgrade to version 4.18.5, 4.22.1 or 4.23.0, which fixes the issue.
Upgrade to Apache Camel 4.23.0, which fixes the issue. Users on the 4.18.x LTS releases stream should upgrade to 4.18.5. Users on the 4.22.x LTS releases stream should upgrade to 4.22.1. camel-smooks now parses the XML body with a javax.xml.parsers.DocumentBuilder that does not resolve external general or parameter entities and does not load external DTDs, and hands Smooks the resulting document, matching the secure XML processing configuration used by org.apache.camel.converter.jaxp.XmlConverter and the other Camel XML components. This hardening is applied only when the Smooks configuration parses XML with its default reader, so EDI, CSV, JSON and custom-reader configurations, and the marshalling direction, are unchanged. A new allowExternalEntities option, disabled by default, restores the previous behaviour for trusted legacy configurations that rely on external entity resolution. The camel-4.14.x releases stream and earlier reached end of life before this issue was resolved and will not receive a fix, so deployments on those lines must move to a supported release. For deployments that cannot upgrade immediately, do not apply camel-smooks to XML received from untrusted senders.
References
| URL | Tags | |
|---|---|---|
Impacted products
| Vendor | Product | Version | ||
|---|---|---|---|---|
| Apache Software Foundation | Apache Camel |
Version: 4.7.0 Version: 4.19.0 |
{
"containers": {
"adp": [
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2026-88901",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "yes"
},
{
"Technical Impact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-10-19T14:30:33.192143Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-10-19T14:30:52.101Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"collectionURL": "https://repo.maven.apache.org/maven2",
"defaultStatus": "unaffected",
"packageName": "org.apache.camel:camel-smooks",
"packageURL": "pkg:maven/org.apache.camel/camel-smooks",
"product": "Apache Camel",
"vendor": "Apache Software Foundation",
"versions": [
{
"lessThan": "4.18.5",
"status": "affected",
"version": "4.7.0",
"versionType": "maven"
},
{
"lessThan": "4.22.1",
"status": "affected",
"version": "4.19.0",
"versionType": "maven"
}
]
}
],
"credits": [
{
"lang": "en",
"type": "finder",
"value": "h1ei1"
},
{
"lang": "en",
"type": "remediation developer",
"value": "Andrea Cosentino"
}
],
"descriptions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eImproper Restriction of XML External Entity Reference vulnerability in Apache Camel.\u003c/p\u003e\u003cp\u003eThis issue affects Apache Camel: from 4.7.0 before 4.18.5, from 4.19.0 before 4.22.1.\u003c/p\u003e\u003cp\u003eImproper Restriction of XML External Entity Reference in the Smooks component (camel-smooks) in Apache Camel allows an attacker who supplies the XML message body to read local files or issue requests to internal network locations via an external entity declaration in that body. This issue affects Apache Camel: from 4.7.0 before 4.18.5, from 4.19.0 before 4.22.1. The Smooks data format (.unmarshal().smooks(...)) and the Smooks component (smooks:) parse the incoming XML body with the reader Smooks resolves by default, which is the Woodstox SAX parser. That reader resolves external general and parameter entities and loads external DTDs, and camel-smooks applied none of the parser hardening that the other Camel XML components apply. A DOCTYPE with an external subset, or an external general entity, declared in the XML document is therefore resolved and expanded while the body is unmarshalled, and the resolved content is bound into the unmarshalled result and returned on InOut routes. An external sender whose XML reaches a camel-smooks data format or endpoint could therefore read files readable by the Camel process and cause the process to issue requests to hosts the document names. No non-default option is required, since resolving external entities was the default behaviour. Configurations that declare their own reader - EDI, CSV, JSON, or a custom reader - do not use the XML reader and are not affected. Users are recommended to upgrade to version 4.18.5, 4.22.1 or 4.23.0, which fixes the issue.\u003c/p\u003e\u003cp\u003eUpgrade to Apache Camel 4.23.0, which fixes the issue. Users on the 4.18.x LTS releases stream should upgrade to 4.18.5. Users on the 4.22.x LTS releases stream should upgrade to 4.22.1. camel-smooks now parses the XML body with a javax.xml.parsers.DocumentBuilder that does not resolve external general or parameter entities and does not load external DTDs, and hands Smooks the resulting document, matching the secure XML processing configuration used by org.apache.camel.converter.jaxp.XmlConverter and the other Camel XML components. This hardening is applied only when the Smooks configuration parses XML with its default reader, so EDI, CSV, JSON and custom-reader configurations, and the marshalling direction, are unchanged. A new allowExternalEntities option, disabled by default, restores the previous behaviour for trusted legacy configurations that rely on external entity resolution. The camel-4.14.x releases stream and earlier reached end of life before this issue was resolved and will not receive a fix, so deployments on those lines must move to a supported release. For deployments that cannot upgrade immediately, do not apply camel-smooks to XML received from untrusted senders.\u003c/p\u003e"
}
],
"value": "Improper Restriction of XML External Entity Reference vulnerability in Apache Camel.\n\n\n\nThis issue affects Apache Camel: from 4.7.0 before 4.18.5, from 4.19.0 before 4.22.1.\n\n\n\nImproper Restriction of XML External Entity Reference in the Smooks component (camel-smooks) in Apache Camel allows an attacker who supplies the XML message body to read local files or issue requests to internal network locations via an external entity declaration in that body. This issue affects Apache Camel: from 4.7.0 before 4.18.5, from 4.19.0 before 4.22.1. The Smooks data format (.unmarshal().smooks(...)) and the Smooks component (smooks:) parse the incoming XML body with the reader Smooks resolves by default, which is the Woodstox SAX parser. That reader resolves external general and parameter entities and loads external DTDs, and camel-smooks applied none of the parser hardening that the other Camel XML components apply. A DOCTYPE with an external subset, or an external general entity, declared in the XML document is therefore resolved and expanded while the body is unmarshalled, and the resolved content is bound into the unmarshalled result and returned on InOut routes. An external sender whose XML reaches a camel-smooks data format or endpoint could therefore read files readable by the Camel process and cause the process to issue requests to hosts the document names. No non-default option is required, since resolving external entities was the default behaviour. Configurations that declare their own reader - EDI, CSV, JSON, or a custom reader - do not use the XML reader and are not affected. Users are recommended to upgrade to version 4.18.5, 4.22.1 or 4.23.0, which fixes the issue.\n\n\n\nUpgrade to Apache Camel 4.23.0, which fixes the issue. Users on the 4.18.x LTS releases stream should upgrade to 4.18.5. Users on the 4.22.x LTS releases stream should upgrade to 4.22.1. camel-smooks now parses the XML body with a javax.xml.parsers.DocumentBuilder that does not resolve external general or parameter entities and does not load external DTDs, and hands Smooks the resulting document, matching the secure XML processing configuration used by org.apache.camel.converter.jaxp.XmlConverter and the other Camel XML components. This hardening is applied only when the Smooks configuration parses XML with its default reader, so EDI, CSV, JSON and custom-reader configurations, and the marshalling direction, are unchanged. A new allowExternalEntities option, disabled by default, restores the previous behaviour for trusted legacy configurations that rely on external entity resolution. The camel-4.14.x releases stream and earlier reached end of life before this issue was resolved and will not receive a fix, so deployments on those lines must move to a supported release. For deployments that cannot upgrade immediately, do not apply camel-smooks to XML received from untrusted senders."
}
],
"metrics": [
{
"cvssV3_1": {
"attackComplexity": "LOW",
"attackVector": "NETWORK",
"availabilityImpact": "LOW",
"baseScore": 8.2,
"baseSeverity": "HIGH",
"confidentialityImpact": "HIGH",
"integrityImpact": "NONE",
"privilegesRequired": "NONE",
"scope": "UNCHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:L",
"version": "3.1"
},
"format": "CVSS",
"scenarios": [
{
"lang": "en",
"value": "GENERAL"
}
]
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-611",
"description": "CWE-611 Improper Restriction of XML External Entity Reference",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-10-19T10:44:07.084Z",
"orgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
"shortName": "apache"
},
"references": [
{
"name": "Apache Camel Security Advisory - CVE-2026-88901",
"tags": [
"vendor-advisory"
],
"url": "https://camel.apache.org/security/CVE-2026-88901.html"
},
{
"name": "CAMEL-24677",
"tags": [
"issue-tracking"
],
"url": "https://issues.apache.org/jira/browse/CAMEL-24677"
},
{
"name": "Fix on main for 4.23.0 (commit 4b1fc499a0ceff909612b5310152cd71517888f7)",
"tags": [
"patch"
],
"url": "https://github.com/apache/camel/pull/26270"
},
{
"name": "Backport to camel-4.22.x for 4.22.1 (commit 1b375c171e2546cafdcaadc2aa9f7346a25a4cd7)",
"tags": [
"patch"
],
"url": "https://github.com/apache/camel/pull/26327"
},
{
"name": "Backport to camel-4.18.x for 4.18.5 (commit 680290f6ba5324301673b7353564130af6d2ad83)",
"tags": [
"patch"
],
"url": "https://github.com/apache/camel/pull/26329"
}
],
"solutions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eUpgrade to Apache Camel 4.23.0, which fixes the issue. Users on the 4.18.x LTS releases stream should upgrade to 4.18.5. Users on the 4.22.x LTS releases stream should upgrade to 4.22.1. camel-smooks now parses the XML body with a javax.xml.parsers.DocumentBuilder that does not resolve external general or parameter entities and does not load external DTDs, and hands Smooks the resulting document, matching the secure XML processing configuration used by org.apache.camel.converter.jaxp.XmlConverter and the other Camel XML components. This hardening is applied only when the Smooks configuration parses XML with its default reader, so EDI, CSV, JSON and custom-reader configurations, and the marshalling direction, are unchanged. A new allowExternalEntities option, disabled by default, restores the previous behaviour for trusted legacy configurations that rely on external entity resolution. The camel-4.14.x releases stream and earlier reached end of life before this issue was resolved and will not receive a fix, so deployments on those lines must move to a supported release. For deployments that cannot upgrade immediately, do not apply camel-smooks to XML received from untrusted senders.\u003c/p\u003e"
}
],
"value": "Upgrade to Apache Camel 4.23.0, which fixes the issue. Users on the 4.18.x LTS releases stream should upgrade to 4.18.5. Users on the 4.22.x LTS releases stream should upgrade to 4.22.1. camel-smooks now parses the XML body with a javax.xml.parsers.DocumentBuilder that does not resolve external general or parameter entities and does not load external DTDs, and hands Smooks the resulting document, matching the secure XML processing configuration used by org.apache.camel.converter.jaxp.XmlConverter and the other Camel XML components. This hardening is applied only when the Smooks configuration parses XML with its default reader, so EDI, CSV, JSON and custom-reader configurations, and the marshalling direction, are unchanged. A new allowExternalEntities option, disabled by default, restores the previous behaviour for trusted legacy configurations that rely on external entity resolution. The camel-4.14.x releases stream and earlier reached end of life before this issue was resolved and will not receive a fix, so deployments on those lines must move to a supported release. For deployments that cannot upgrade immediately, do not apply camel-smooks to XML received from untrusted senders."
}
],
"source": {
"discovery": "UNKNOWN"
},
"title": "Apache Camel: Camel-Smooks XML External Entity Processing, external entities resolved by default",
"workarounds": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eDo not apply the Smooks data format or the Smooks component to XML received from untrusted senders. The camel-4.14.x releases stream and earlier reached end of life before this issue was resolved and will not receive a fix, so deployments on those lines must move to a supported release.\u003c/p\u003e"
}
],
"value": "Do not apply the Smooks data format or the Smooks component to XML received from untrusted senders. The camel-4.14.x releases stream and earlier reached end of life before this issue was resolved and will not receive a fix, so deployments on those lines must move to a supported release."
}
],
"x_generator": {
"engine": "Vulnogram 1.0.3"
}
}
},
"cveMetadata": {
"assignerOrgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
"assignerShortName": "apache",
"cveId": "CVE-2026-88901",
"datePublished": "2026-10-19T10:44:07.084Z",
"dateReserved": "2026-09-10T11:43:50.047Z",
"dateUpdated": "2026-10-19T14:30:52.101Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2026-85317 (GCVE-0-2026-85317)
Vulnerability from cvelistv5
Published
2026-10-19 10:43
Modified
2026-10-19 14:31
Severity ?
VLAI Severity ?
EPSS score ?
CWE
- CWE-524 - Use of Cache Containing Sensitive Information
Summary
Use of Cache Containing Sensitive Information vulnerability in Apache Camel HTTP component.
This issue affects Apache Camel: from 4.0.0 before 4.18.5, from 4.19.0 before 4.22.1.
The OAuth2 client token cache is global to the JVM, and its key omitted several of the fields that determine what a token actually authorises: the requested scope, the resource indicator, and the token endpoint the token was obtained from. Two endpoints differing only in those fields therefore shared a cache entry, and an endpoint could be served a token minted for a different scope, a different resource, or by a different authorization server. The consequence is a request carrying broader authority than the endpoint was configured for, or a token presented to a party it was not issued for. Reaching it requires a deployment that configures more than one OAuth2 endpoint differing in exactly those fields, which is why the severity is assessed low.
Upgrade to Apache Camel 4.23.0, which fixes the issue. Users on the 4.18.x LTS releases stream should upgrade to 4.18.5. Users on the 4.22.x LTS releases stream should upgrade to 4.22.1. The cache key now includes every field that shapes the token, so entries are no longer shared between endpoints that differ in any of them. For deployments that cannot upgrade immediately, run endpoints that differ in scope, resource indicator or token endpoint in separate JVMs so that they do not share the cache.
References
| URL | Tags | |
|---|---|---|
Impacted products
| Vendor | Product | Version | ||
|---|---|---|---|---|
| Apache Software Foundation | Apache Camel |
Version: 4.0.0 Version: 4.19.0 |
{
"containers": {
"adp": [
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2026-85317",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "no"
},
{
"Technical Impact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-10-19T14:31:11.714980Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-10-19T14:31:27.611Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"collectionURL": "https://repo.maven.apache.org/maven2",
"defaultStatus": "unaffected",
"packageName": "org.apache.camel:camel-http",
"packageURL": "pkg:maven/org.apache.camel/camel-http",
"product": "Apache Camel",
"vendor": "Apache Software Foundation",
"versions": [
{
"lessThan": "4.18.5",
"status": "affected",
"version": "4.0.0",
"versionType": "maven"
},
{
"lessThan": "4.22.1",
"status": "affected",
"version": "4.19.0",
"versionType": "maven"
},
{
"status": "unaffected",
"version": "4.18.5",
"versionType": "maven"
},
{
"status": "unaffected",
"version": "4.22.1",
"versionType": "maven"
},
{
"status": "unaffected",
"version": "4.23.0",
"versionType": "maven"
}
]
}
],
"credits": [
{
"lang": "en",
"type": "finder",
"value": "Claude Security"
},
{
"lang": "en",
"type": "remediation developer",
"value": "Andrea Cosentino"
}
],
"descriptions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eUse of Cache Containing Sensitive Information vulnerability in Apache Camel HTTP component.\u003cbr\u003e\u003cbr\u003eThis issue affects Apache Camel: from 4.0.0 before 4.18.5, from 4.19.0 before 4.22.1.\u003cbr\u003e\u003cbr\u003eThe OAuth2 client token cache is global to the JVM, and its key omitted several of the fields that determine what a token actually authorises: the requested scope, the resource indicator, and the token endpoint the token was obtained from. Two endpoints differing only in those fields therefore shared a cache entry, and an endpoint could be served a token minted for a different scope, a different resource, or by a different authorization server. The consequence is a request carrying broader authority than the endpoint was configured for, or a token presented to a party it was not issued for. Reaching it requires a deployment that configures more than one OAuth2 endpoint differing in exactly those fields, which is why the severity is assessed low.\u003cbr\u003e\u003cbr\u003eUpgrade to Apache Camel 4.23.0, which fixes the issue. Users on the 4.18.x LTS releases stream should upgrade to 4.18.5. Users on the 4.22.x LTS releases stream should upgrade to 4.22.1. The cache key now includes every field that shapes the token, so entries are no longer shared between endpoints that differ in any of them. For deployments that cannot upgrade immediately, run endpoints that differ in scope, resource indicator or token endpoint in separate JVMs so that they do not share the cache.\u003c/p\u003e"
}
],
"value": "Use of Cache Containing Sensitive Information vulnerability in Apache Camel HTTP component.\n\nThis issue affects Apache Camel: from 4.0.0 before 4.18.5, from 4.19.0 before 4.22.1.\n\nThe OAuth2 client token cache is global to the JVM, and its key omitted several of the fields that determine what a token actually authorises: the requested scope, the resource indicator, and the token endpoint the token was obtained from. Two endpoints differing only in those fields therefore shared a cache entry, and an endpoint could be served a token minted for a different scope, a different resource, or by a different authorization server. The consequence is a request carrying broader authority than the endpoint was configured for, or a token presented to a party it was not issued for. Reaching it requires a deployment that configures more than one OAuth2 endpoint differing in exactly those fields, which is why the severity is assessed low.\n\nUpgrade to Apache Camel 4.23.0, which fixes the issue. Users on the 4.18.x LTS releases stream should upgrade to 4.18.5. Users on the 4.22.x LTS releases stream should upgrade to 4.22.1. The cache key now includes every field that shapes the token, so entries are no longer shared between endpoints that differ in any of them. For deployments that cannot upgrade immediately, run endpoints that differ in scope, resource indicator or token endpoint in separate JVMs so that they do not share the cache."
}
],
"metrics": [
{
"cvssV3_1": {
"attackComplexity": "HIGH",
"attackVector": "NETWORK",
"availabilityImpact": "NONE",
"baseScore": 4.8,
"baseSeverity": "MEDIUM",
"confidentialityImpact": "LOW",
"integrityImpact": "LOW",
"privilegesRequired": "NONE",
"scope": "UNCHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N",
"version": "3.1"
},
"format": "CVSS",
"scenarios": [
{
"lang": "en",
"value": "GENERAL"
}
]
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-524",
"description": "CWE-524 Use of Cache Containing Sensitive Information",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-10-19T10:43:39.184Z",
"orgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
"shortName": "apache"
},
"references": [
{
"name": "Apache Camel Security Advisory - CVE-2026-85317",
"tags": [
"vendor-advisory"
],
"url": "https://camel.apache.org/security/CVE-2026-85317.html"
},
{
"name": "CAMEL-24456",
"tags": [
"issue-tracking"
],
"url": "https://issues.apache.org/jira/browse/CAMEL-24456"
},
{
"name": "Fix on main, released in 4.23.0 (commit 4e2ddabd0392441b48ce591105851933b04b34b0)",
"tags": [
"patch"
],
"url": "https://github.com/apache/camel/pull/25834"
},
{
"name": "Backport to camel-4.22.x, released in 4.22.1 (commit b0399b181d26cd8b136fa98b54ec8e5c283338da)",
"tags": [
"patch"
],
"url": "https://github.com/apache/camel/pull/25937"
},
{
"name": "Backport to camel-4.18.x, released in 4.18.5 (commit e23332aec12f7ec3a841e52d1821e2a580c2fbc7)",
"tags": [
"patch"
],
"url": "https://github.com/apache/camel/pull/25938"
}
],
"solutions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eUpgrade to Apache Camel 4.23.0, which fixes the issue. Users on the 4.18.x LTS releases stream should upgrade to 4.18.5. Users on the 4.22.x LTS releases stream should upgrade to 4.22.1. The cache key now includes every field that shapes the token, so entries are no longer shared between endpoints that differ in any of them.\u003c/p\u003e"
}
],
"value": "Upgrade to Apache Camel 4.23.0, which fixes the issue. Users on the 4.18.x LTS releases stream should upgrade to 4.18.5. Users on the 4.22.x LTS releases stream should upgrade to 4.22.1. The cache key now includes every field that shapes the token, so entries are no longer shared between endpoints that differ in any of them."
}
],
"source": {
"discovery": "UNKNOWN"
},
"title": "Apache Camel: Camel-HTTP OAuth2 Token Confusion via an Under-Keyed JVM-Global Token Cache",
"workarounds": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eFor deployments that cannot upgrade immediately, run endpoints that differ in scope, resource indicator or token endpoint in separate JVMs so that they do not share the cache.\u003c/p\u003e"
}
],
"value": "For deployments that cannot upgrade immediately, run endpoints that differ in scope, resource indicator or token endpoint in separate JVMs so that they do not share the cache."
}
],
"x_generator": {
"engine": "Vulnogram 1.0.3"
}
}
},
"cveMetadata": {
"assignerOrgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
"assignerShortName": "apache",
"cveId": "CVE-2026-85317",
"datePublished": "2026-10-19T10:43:39.184Z",
"dateReserved": "2026-09-03T16:47:40.818Z",
"dateUpdated": "2026-10-19T14:31:27.611Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2026-85316 (GCVE-0-2026-85316)
Vulnerability from cvelistv5
Published
2026-10-19 10:43
Modified
2026-10-19 14:32
Severity ?
VLAI Severity ?
EPSS score ?
CWE
- CWE-1220 - Insufficient Granularity of Access Control
Summary
Insufficient Granularity of Access Control vulnerability in Apache Camel Platform HTTP component.
This issue affects Apache Camel: from 4.0.0 before 4.18.5, from 4.19.0 before 4.22.1.
The component decided whether an endpoint ran in proxy mode by testing whether its configured path started with the string proxy, rather than by matching the path exactly. Any endpoint whose path merely begins with those characters - proxyStatus, proxy-config, proxying and so on - therefore became a proxy endpoint without the route author asking for it. A proxy endpoint forwards requests onward, so an endpoint that was intended to serve its own content instead relays traffic on behalf of whoever calls it, which is both a request forgery primitive and an exposure of whatever the forwarding path can reach.
Upgrade to Apache Camel 4.23.0, which fixes the issue. Users on the 4.18.x LTS releases stream should upgrade to 4.18.5. Users on the 4.22.x LTS releases stream should upgrade to 4.22.1. Proxy mode is now selected by an exact path match rather than by prefix. For deployments that cannot upgrade immediately, rename any endpoint path that begins with proxy but is not intended to be a proxy.
References
| URL | Tags | |
|---|---|---|
Impacted products
| Vendor | Product | Version | ||
|---|---|---|---|---|
| Apache Software Foundation | Apache Camel |
Version: 4.0.0 Version: 4.19.0 |
{
"containers": {
"adp": [
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2026-85316",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "no"
},
{
"Technical Impact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-10-19T14:31:55.301941Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-10-19T14:32:09.821Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"collectionURL": "https://repo.maven.apache.org/maven2",
"defaultStatus": "unaffected",
"packageName": "org.apache.camel:camel-platform-http",
"packageURL": "pkg:maven/org.apache.camel/camel-platform-http",
"product": "Apache Camel",
"vendor": "Apache Software Foundation",
"versions": [
{
"lessThan": "4.18.5",
"status": "affected",
"version": "4.0.0",
"versionType": "maven"
},
{
"lessThan": "4.22.1",
"status": "affected",
"version": "4.19.0",
"versionType": "maven"
},
{
"status": "unaffected",
"version": "4.18.5",
"versionType": "maven"
},
{
"status": "unaffected",
"version": "4.22.1",
"versionType": "maven"
},
{
"status": "unaffected",
"version": "4.23.0",
"versionType": "maven"
}
]
}
],
"credits": [
{
"lang": "en",
"type": "finder",
"value": "Claude Security"
},
{
"lang": "en",
"type": "remediation developer",
"value": "Andrea Cosentino"
}
],
"descriptions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eInsufficient Granularity of Access Control vulnerability in Apache Camel Platform HTTP component.\u003cbr\u003e\u003cbr\u003eThis issue affects Apache Camel: from 4.0.0 before 4.18.5, from 4.19.0 before 4.22.1.\u003cbr\u003e\u003cbr\u003eThe component decided whether an endpoint ran in proxy mode by testing whether its configured path started with the string proxy, rather than by matching the path exactly. Any endpoint whose path merely begins with those characters - proxyStatus, proxy-config, proxying and so on - therefore became a proxy endpoint without the route author asking for it. A proxy endpoint forwards requests onward, so an endpoint that was intended to serve its own content instead relays traffic on behalf of whoever calls it, which is both a request forgery primitive and an exposure of whatever the forwarding path can reach.\u003cbr\u003e\u003cbr\u003eUpgrade to Apache Camel 4.23.0, which fixes the issue. Users on the 4.18.x LTS releases stream should upgrade to 4.18.5. Users on the 4.22.x LTS releases stream should upgrade to 4.22.1. Proxy mode is now selected by an exact path match rather than by prefix. For deployments that cannot upgrade immediately, rename any endpoint path that begins with proxy but is not intended to be a proxy.\u003c/p\u003e"
}
],
"value": "Insufficient Granularity of Access Control vulnerability in Apache Camel Platform HTTP component.\n\nThis issue affects Apache Camel: from 4.0.0 before 4.18.5, from 4.19.0 before 4.22.1.\n\nThe component decided whether an endpoint ran in proxy mode by testing whether its configured path started with the string proxy, rather than by matching the path exactly. Any endpoint whose path merely begins with those characters - proxyStatus, proxy-config, proxying and so on - therefore became a proxy endpoint without the route author asking for it. A proxy endpoint forwards requests onward, so an endpoint that was intended to serve its own content instead relays traffic on behalf of whoever calls it, which is both a request forgery primitive and an exposure of whatever the forwarding path can reach.\n\nUpgrade to Apache Camel 4.23.0, which fixes the issue. Users on the 4.18.x LTS releases stream should upgrade to 4.18.5. Users on the 4.22.x LTS releases stream should upgrade to 4.22.1. Proxy mode is now selected by an exact path match rather than by prefix. For deployments that cannot upgrade immediately, rename any endpoint path that begins with proxy but is not intended to be a proxy."
}
],
"metrics": [
{
"cvssV3_1": {
"attackComplexity": "HIGH",
"attackVector": "NETWORK",
"availabilityImpact": "NONE",
"baseScore": 4.8,
"baseSeverity": "MEDIUM",
"confidentialityImpact": "LOW",
"integrityImpact": "LOW",
"privilegesRequired": "NONE",
"scope": "UNCHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N",
"version": "3.1"
},
"format": "CVSS",
"scenarios": [
{
"lang": "en",
"value": "GENERAL"
}
]
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-1220",
"description": "CWE-1220 Insufficient Granularity of Access Control",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-10-19T10:43:00.504Z",
"orgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
"shortName": "apache"
},
"references": [
{
"name": "Apache Camel Security Advisory - CVE-2026-85316",
"tags": [
"vendor-advisory"
],
"url": "https://camel.apache.org/security/CVE-2026-85316.html"
},
{
"name": "CAMEL-24455",
"tags": [
"issue-tracking"
],
"url": "https://issues.apache.org/jira/browse/CAMEL-24455"
},
{
"name": "Fix on main, released in 4.23.0 (commit 7abf13b2b314f40b8e76af3ba655266b57ff5e20)",
"tags": [
"patch"
],
"url": "https://github.com/apache/camel/pull/25833"
},
{
"name": "Backport to camel-4.22.x, released in 4.22.1 (commit 260989268cbc6d258b1fcba63770be8ebbec40cb)",
"tags": [
"patch"
],
"url": "https://github.com/apache/camel/pull/25940"
},
{
"name": "Backport to camel-4.18.x, released in 4.18.5 (commit af1efbcccf5882b1ef0094db718972da3190e7e9)",
"tags": [
"patch"
],
"url": "https://github.com/apache/camel/pull/25942"
}
],
"solutions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eUpgrade to Apache Camel 4.23.0, which fixes the issue. Users on the 4.18.x LTS releases stream should upgrade to 4.18.5. Users on the 4.22.x LTS releases stream should upgrade to 4.22.1. Proxy mode is now selected by an exact path match rather than by prefix.\u003c/p\u003e"
}
],
"value": "Upgrade to Apache Camel 4.23.0, which fixes the issue. Users on the 4.18.x LTS releases stream should upgrade to 4.18.5. Users on the 4.22.x LTS releases stream should upgrade to 4.22.1. Proxy mode is now selected by an exact path match rather than by prefix."
}
],
"source": {
"discovery": "UNKNOWN"
},
"title": "Apache Camel: Camel-Platform-HTTP Unintended Proxy Mode via Prefix Path Matching",
"workarounds": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eFor deployments that cannot upgrade immediately, rename any endpoint path that begins with proxy but is not intended to be a proxy.\u003c/p\u003e"
}
],
"value": "For deployments that cannot upgrade immediately, rename any endpoint path that begins with proxy but is not intended to be a proxy."
}
],
"x_generator": {
"engine": "Vulnogram 1.0.3"
}
}
},
"cveMetadata": {
"assignerOrgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
"assignerShortName": "apache",
"cveId": "CVE-2026-85316",
"datePublished": "2026-10-19T10:43:00.504Z",
"dateReserved": "2026-09-03T16:47:12.426Z",
"dateUpdated": "2026-10-19T14:32:09.821Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2026-85315 (GCVE-0-2026-85315)
Vulnerability from cvelistv5
Published
2026-10-19 10:42
Modified
2026-10-19 14:38
Severity ?
VLAI Severity ?
EPSS score ?
CWE
- CWE-209 - Generation of Error Message Containing Sensitive Information
Summary
Generation of Error Message Containing Sensitive Information vulnerability in Apache Camel gRPC component.
This issue affects Apache Camel: from 4.0.0 before 4.18.5, from 4.19.0 before 4.22.1.
When a route behind a gRPC consumer failed, the exception's message was placed into the gRPC status description. Unlike the status cause, which stays local to the server, the description is transmitted to the calling client, so an external caller able to provoke a failure could read the internal error message. What that discloses depends on the exception, and in practice includes class and package names, paths, host names and connection detail carried in messages. This is the gRPC member of the same unmuted-consumer-exception family as the knative, mina and CXF advisories published alongside it.
Upgrade to Apache Camel 4.23.0, which fixes the issue. Users on the 4.18.x LTS releases stream should upgrade to 4.18.5. Users on the 4.22.x LTS releases stream should upgrade to 4.22.1. A muteException consumer option, defaulting to true, puts a generic description in the status instead of the route exception's message. Set muteException=false to restore the previous output. For deployments that cannot upgrade immediately, map failures onto an explicit status in an onException handler so the framework never copies the exception message into the description.
References
| URL | Tags | |
|---|---|---|
Impacted products
| Vendor | Product | Version | ||
|---|---|---|---|---|
| Apache Software Foundation | Apache Camel |
Version: 4.0.0 Version: 4.19.0 |
{
"containers": {
"adp": [
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2026-85315",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "yes"
},
{
"Technical Impact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-10-19T14:37:21.222896Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-10-19T14:38:44.708Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"collectionURL": "https://repo.maven.apache.org/maven2",
"defaultStatus": "unaffected",
"packageName": "org.apache.camel:camel-grpc",
"packageURL": "pkg:maven/org.apache.camel/camel-grpc",
"product": "Apache Camel",
"vendor": "Apache Software Foundation",
"versions": [
{
"lessThan": "4.18.5",
"status": "affected",
"version": "4.0.0",
"versionType": "maven"
},
{
"lessThan": "4.22.1",
"status": "affected",
"version": "4.19.0",
"versionType": "maven"
},
{
"status": "unaffected",
"version": "4.18.5",
"versionType": "maven"
},
{
"status": "unaffected",
"version": "4.22.1",
"versionType": "maven"
},
{
"status": "unaffected",
"version": "4.23.0",
"versionType": "maven"
}
]
}
],
"credits": [
{
"lang": "en",
"type": "finder",
"value": "Claude Security"
},
{
"lang": "en",
"type": "remediation developer",
"value": "Andrea Cosentino"
}
],
"descriptions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eGeneration of Error Message Containing Sensitive Information vulnerability in Apache Camel gRPC component.\u003cbr\u003e\u003cbr\u003eThis issue affects Apache Camel: from 4.0.0 before 4.18.5, from 4.19.0 before 4.22.1.\u003cbr\u003e\u003cbr\u003eWhen a route behind a gRPC consumer failed, the exception\u0027s message was placed into the gRPC status description. Unlike the status cause, which stays local to the server, the description is transmitted to the calling client, so an external caller able to provoke a failure could read the internal error message. What that discloses depends on the exception, and in practice includes class and package names, paths, host names and connection detail carried in messages. This is the gRPC member of the same unmuted-consumer-exception family as the knative, mina and CXF advisories published alongside it.\u003cbr\u003e\u003cbr\u003eUpgrade to Apache Camel 4.23.0, which fixes the issue. Users on the 4.18.x LTS releases stream should upgrade to 4.18.5. Users on the 4.22.x LTS releases stream should upgrade to 4.22.1. A muteException consumer option, defaulting to true, puts a generic description in the status instead of the route exception\u0027s message. Set muteException=false to restore the previous output. For deployments that cannot upgrade immediately, map failures onto an explicit status in an onException handler so the framework never copies the exception message into the description.\u003c/p\u003e"
}
],
"value": "Generation of Error Message Containing Sensitive Information vulnerability in Apache Camel gRPC component.\n\nThis issue affects Apache Camel: from 4.0.0 before 4.18.5, from 4.19.0 before 4.22.1.\n\nWhen a route behind a gRPC consumer failed, the exception\u0027s message was placed into the gRPC status description. Unlike the status cause, which stays local to the server, the description is transmitted to the calling client, so an external caller able to provoke a failure could read the internal error message. What that discloses depends on the exception, and in practice includes class and package names, paths, host names and connection detail carried in messages. This is the gRPC member of the same unmuted-consumer-exception family as the knative, mina and CXF advisories published alongside it.\n\nUpgrade to Apache Camel 4.23.0, which fixes the issue. Users on the 4.18.x LTS releases stream should upgrade to 4.18.5. Users on the 4.22.x LTS releases stream should upgrade to 4.22.1. A muteException consumer option, defaulting to true, puts a generic description in the status instead of the route exception\u0027s message. Set muteException=false to restore the previous output. For deployments that cannot upgrade immediately, map failures onto an explicit status in an onException handler so the framework never copies the exception message into the description."
}
],
"metrics": [
{
"cvssV3_1": {
"attackComplexity": "LOW",
"attackVector": "NETWORK",
"availabilityImpact": "NONE",
"baseScore": 5.3,
"baseSeverity": "MEDIUM",
"confidentialityImpact": "LOW",
"integrityImpact": "NONE",
"privilegesRequired": "NONE",
"scope": "UNCHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N",
"version": "3.1"
},
"format": "CVSS",
"scenarios": [
{
"lang": "en",
"value": "GENERAL"
}
]
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-209",
"description": "CWE-209 Generation of Error Message Containing Sensitive Information",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-10-19T10:42:10.032Z",
"orgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
"shortName": "apache"
},
"references": [
{
"name": "Apache Camel Security Advisory - CVE-2026-85315",
"tags": [
"vendor-advisory"
],
"url": "https://camel.apache.org/security/CVE-2026-85315.html"
},
{
"name": "CAMEL-24478",
"tags": [
"issue-tracking"
],
"url": "https://issues.apache.org/jira/browse/CAMEL-24478"
},
{
"name": "Fix on main, released in 4.23.0 (commit 3c99874122e0c4dbad655a1e32bbcaf48cee1e67)",
"tags": [
"patch"
],
"url": "https://github.com/apache/camel/pull/25839"
},
{
"name": "Backport to camel-4.22.x, released in 4.22.1 (commit 9a6e8222085ed12f73ce76f826aeb69e9d111ff8)",
"tags": [
"patch"
],
"url": "https://github.com/apache/camel/pull/25934"
},
{
"name": "Backport to camel-4.18.x, released in 4.18.5 (commit e6986906e41b3e537d3a5d278525bc09b78b4127)",
"tags": [
"patch"
],
"url": "https://github.com/apache/camel/pull/25935"
}
],
"solutions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eUpgrade to Apache Camel 4.23.0, which fixes the issue. Users on the 4.18.x LTS releases stream should upgrade to 4.18.5. Users on the 4.22.x LTS releases stream should upgrade to 4.22.1. A muteException consumer option, defaulting to true, puts a generic description in the status instead of the route exception\u0027s message. Set muteException=false to restore the previous output.\u003c/p\u003e"
}
],
"value": "Upgrade to Apache Camel 4.23.0, which fixes the issue. Users on the 4.18.x LTS releases stream should upgrade to 4.18.5. Users on the 4.22.x LTS releases stream should upgrade to 4.22.1. A muteException consumer option, defaulting to true, puts a generic description in the status instead of the route exception\u0027s message. Set muteException=false to restore the previous output."
}
],
"source": {
"discovery": "UNKNOWN"
},
"title": "Apache Camel: Camel-gRPC Information Disclosure via Unmuted Consumer Exceptions",
"workarounds": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eFor deployments that cannot upgrade immediately, map failures onto an explicit status in an onException handler so the framework never copies the exception message into the description.\u003c/p\u003e"
}
],
"value": "For deployments that cannot upgrade immediately, map failures onto an explicit status in an onException handler so the framework never copies the exception message into the description."
}
],
"x_generator": {
"engine": "Vulnogram 1.0.3"
}
}
},
"cveMetadata": {
"assignerOrgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
"assignerShortName": "apache",
"cveId": "CVE-2026-85315",
"datePublished": "2026-10-19T10:42:10.032Z",
"dateReserved": "2026-09-03T16:46:17.540Z",
"dateUpdated": "2026-10-19T14:38:44.708Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2026-85314 (GCVE-0-2026-85314)
Vulnerability from cvelistv5
Published
2026-10-19 10:41
Modified
2026-10-19 14:32
Severity ?
VLAI Severity ?
EPSS score ?
CWE
- CWE-20 - Improper Input Validation
Summary
Improper Input Validation vulnerability in Apache Camel Mail component.
This issue affects Apache Camel: from 4.0.0 before 4.18.5, from 4.19.0 before 4.22.1.
CVE-2026-46584 addressed mail headers reaching the Exchange without passing through a header filter, but the MimeMultipart data format retained an unfiltered path: unmarshalling a multipart message mapped mail.smtp headers onto the Exchange with no filter applied. Those names sit outside the Camel namespace that consumer filters block, so a message crafted by an external sender could still set them, and the mail.smtp namespace influences how a downstream mail producer connects and sends. This is an incomplete fix of CVE-2026-46584 rather than a new class of defect: a deployment that applied that advisory and considered camel-mail settled remained exposed on this path.
Upgrade to Apache Camel 4.23.0, which fixes the issue. Users on the 4.18.x LTS releases stream should upgrade to 4.18.5. Users on the 4.22.x LTS releases stream should upgrade to 4.22.1. The MimeMultipart data format now applies the header filter on unmarshal, closing the path CVE-2026-46584 left open. For deployments that cannot upgrade immediately, strip the namespace after the data format with removeHeaders("mail.smtp*") before any mail producer.
References
| URL | Tags | |
|---|---|---|
Impacted products
| Vendor | Product | Version | ||
|---|---|---|---|---|
| Apache Software Foundation | Apache Camel |
Version: 4.0.0 Version: 4.19.0 |
{
"containers": {
"adp": [
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2026-85314",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "yes"
},
{
"Technical Impact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-10-19T14:32:29.162863Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-10-19T14:32:46.401Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"collectionURL": "https://repo.maven.apache.org/maven2",
"defaultStatus": "unaffected",
"packageName": "org.apache.camel:camel-mail",
"packageURL": "pkg:maven/org.apache.camel/camel-mail",
"product": "Apache Camel",
"vendor": "Apache Software Foundation",
"versions": [
{
"lessThan": "4.18.5",
"status": "affected",
"version": "4.0.0",
"versionType": "maven"
},
{
"lessThan": "4.22.1",
"status": "affected",
"version": "4.19.0",
"versionType": "maven"
},
{
"status": "unaffected",
"version": "4.18.5",
"versionType": "maven"
},
{
"status": "unaffected",
"version": "4.22.1",
"versionType": "maven"
},
{
"status": "unaffected",
"version": "4.23.0",
"versionType": "maven"
}
]
}
],
"credits": [
{
"lang": "en",
"type": "finder",
"value": "Claude Security"
},
{
"lang": "en",
"type": "remediation developer",
"value": "Andrea Cosentino"
}
],
"descriptions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eImproper Input Validation vulnerability in Apache Camel Mail component.\u003cbr\u003e\u003cbr\u003eThis issue affects Apache Camel: from 4.0.0 before 4.18.5, from 4.19.0 before 4.22.1.\u003cbr\u003e\u003cbr\u003eCVE-2026-46584 addressed mail headers reaching the Exchange without passing through a header filter, but the MimeMultipart data format retained an unfiltered path: unmarshalling a multipart message mapped mail.smtp headers onto the Exchange with no filter applied. Those names sit outside the Camel namespace that consumer filters block, so a message crafted by an external sender could still set them, and the mail.smtp namespace influences how a downstream mail producer connects and sends. This is an incomplete fix of CVE-2026-46584 rather than a new class of defect: a deployment that applied that advisory and considered camel-mail settled remained exposed on this path.\u003cbr\u003e\u003cbr\u003eUpgrade to Apache Camel 4.23.0, which fixes the issue. Users on the 4.18.x LTS releases stream should upgrade to 4.18.5. Users on the 4.22.x LTS releases stream should upgrade to 4.22.1. The MimeMultipart data format now applies the header filter on unmarshal, closing the path CVE-2026-46584 left open. For deployments that cannot upgrade immediately, strip the namespace after the data format with removeHeaders(\"mail.smtp*\") before any mail producer.\u003c/p\u003e"
}
],
"value": "Improper Input Validation vulnerability in Apache Camel Mail component.\n\nThis issue affects Apache Camel: from 4.0.0 before 4.18.5, from 4.19.0 before 4.22.1.\n\nCVE-2026-46584 addressed mail headers reaching the Exchange without passing through a header filter, but the MimeMultipart data format retained an unfiltered path: unmarshalling a multipart message mapped mail.smtp headers onto the Exchange with no filter applied. Those names sit outside the Camel namespace that consumer filters block, so a message crafted by an external sender could still set them, and the mail.smtp namespace influences how a downstream mail producer connects and sends. This is an incomplete fix of CVE-2026-46584 rather than a new class of defect: a deployment that applied that advisory and considered camel-mail settled remained exposed on this path.\n\nUpgrade to Apache Camel 4.23.0, which fixes the issue. Users on the 4.18.x LTS releases stream should upgrade to 4.18.5. Users on the 4.22.x LTS releases stream should upgrade to 4.22.1. The MimeMultipart data format now applies the header filter on unmarshal, closing the path CVE-2026-46584 left open. For deployments that cannot upgrade immediately, strip the namespace after the data format with removeHeaders(\"mail.smtp*\") before any mail producer."
}
],
"metrics": [
{
"cvssV3_1": {
"attackComplexity": "LOW",
"attackVector": "NETWORK",
"availabilityImpact": "NONE",
"baseScore": 6.5,
"baseSeverity": "MEDIUM",
"confidentialityImpact": "LOW",
"integrityImpact": "LOW",
"privilegesRequired": "NONE",
"scope": "UNCHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N",
"version": "3.1"
},
"format": "CVSS",
"scenarios": [
{
"lang": "en",
"value": "GENERAL"
}
]
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-20",
"description": "CWE-20 Improper Input Validation",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-10-19T10:41:45.323Z",
"orgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
"shortName": "apache"
},
"references": [
{
"name": "Apache Camel Security Advisory - CVE-2026-85314",
"tags": [
"vendor-advisory"
],
"url": "https://camel.apache.org/security/CVE-2026-85314.html"
},
{
"name": "CAMEL-24419",
"tags": [
"issue-tracking"
],
"url": "https://issues.apache.org/jira/browse/CAMEL-24419"
},
{
"name": "Fix on main, released in 4.23.0 (commit c2bcb24814a806ced928e612ce5da1a6e3658234)",
"tags": [
"patch"
],
"url": "https://github.com/apache/camel/pull/25568"
},
{
"name": "Backport to camel-4.22.x, released in 4.22.1 (commit 451d3037ee60544cb2158675959416fec5cc5745)",
"tags": [
"patch"
],
"url": "https://github.com/apache/camel/pull/25765"
},
{
"name": "Backport to camel-4.18.x, released in 4.18.5 (commit e25a496381c1330aea16f26136ce02bb818ccccb)",
"tags": [
"patch"
],
"url": "https://github.com/apache/camel/pull/25766"
}
],
"solutions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eUpgrade to Apache Camel 4.23.0, which fixes the issue. Users on the 4.18.x LTS releases stream should upgrade to 4.18.5. Users on the 4.22.x LTS releases stream should upgrade to 4.22.1. The MimeMultipart data format now applies the header filter on unmarshal, closing the path CVE-2026-46584 left open.\u003c/p\u003e"
}
],
"value": "Upgrade to Apache Camel 4.23.0, which fixes the issue. Users on the 4.18.x LTS releases stream should upgrade to 4.18.5. Users on the 4.22.x LTS releases stream should upgrade to 4.22.1. The MimeMultipart data format now applies the header filter on unmarshal, closing the path CVE-2026-46584 left open."
}
],
"source": {
"discovery": "UNKNOWN"
},
"title": "Apache Camel: Camel-Mail Header Injection via Unfiltered mail.smtp Headers in the MimeMultipart Data Format (Incomplete Fix of CVE-2026-46584)",
"workarounds": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eFor deployments that cannot upgrade immediately, strip the namespace after the data format with removeHeaders(\u0026quot;mail.smtp*\u0026quot;) before any mail producer.\u003c/p\u003e"
}
],
"value": "For deployments that cannot upgrade immediately, strip the namespace after the data format with removeHeaders(\"mail.smtp*\") before any mail producer."
}
],
"x_generator": {
"engine": "Vulnogram 1.0.3"
}
}
},
"cveMetadata": {
"assignerOrgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
"assignerShortName": "apache",
"cveId": "CVE-2026-85314",
"datePublished": "2026-10-19T10:41:45.323Z",
"dateReserved": "2026-09-03T16:45:25.143Z",
"dateUpdated": "2026-10-19T14:32:46.401Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2026-85313 (GCVE-0-2026-85313)
Vulnerability from cvelistv5
Published
2026-10-19 10:40
Modified
2026-10-19 14:33
Severity ?
VLAI Severity ?
EPSS score ?
CWE
- CWE-942 - Permissive Cross-domain Policy with Untrusted Domains
Summary
Permissive Cross-domain Policy with Untrusted Domains vulnerability in Apache Camel Jetty component.
This issue affects Apache Camel: from 4.0.0 before 4.18.5, from 4.19.0 before 4.22.1.
Setting enableCORS on a Jetty endpoint installed Jetty's CrossOriginFilter with its stock defaults, which accept every origin and allow credentials. An operator asking for CORS therefore obtained a policy that lets a page on any origin make credentialed cross-origin requests to the endpoint and read the responses, without any indication that turning the option on had chosen an allow-all policy rather than an empty one to be filled in. This is the same defect class as the platform-http-vertx advisory published alongside it, in a different component.
Upgrade to Apache Camel 4.23.0, which fixes the issue. Users on the 4.18.x LTS releases stream should upgrade to 4.18.5. Users on the 4.22.x LTS releases stream should upgrade to 4.22.1. enableCORS no longer grants credentials to an origin the operator did not name. A deployment that relied on any origin being accepted must now list its origins explicitly. For deployments that cannot upgrade immediately, configure the CrossOriginFilter parameters explicitly rather than relying on what enableCORS installs, naming the allowed origins.
References
| URL | Tags | |
|---|---|---|
Impacted products
| Vendor | Product | Version | ||
|---|---|---|---|---|
| Apache Software Foundation | Apache Camel |
Version: 4.0.0 Version: 4.19.0 |
{
"containers": {
"adp": [
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2026-85313",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "no"
},
{
"Technical Impact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-10-19T14:33:15.618494Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-10-19T14:33:28.013Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"collectionURL": "https://repo.maven.apache.org/maven2",
"defaultStatus": "unaffected",
"packageName": "org.apache.camel:camel-jetty",
"packageURL": "pkg:maven/org.apache.camel/camel-jetty",
"product": "Apache Camel",
"vendor": "Apache Software Foundation",
"versions": [
{
"lessThan": "4.18.5",
"status": "affected",
"version": "4.0.0",
"versionType": "maven"
},
{
"lessThan": "4.22.1",
"status": "affected",
"version": "4.19.0",
"versionType": "maven"
},
{
"status": "unaffected",
"version": "4.18.5",
"versionType": "maven"
},
{
"status": "unaffected",
"version": "4.22.1",
"versionType": "maven"
},
{
"status": "unaffected",
"version": "4.23.0",
"versionType": "maven"
}
]
}
],
"credits": [
{
"lang": "en",
"type": "finder",
"value": "Claude Security"
},
{
"lang": "en",
"type": "remediation developer",
"value": "Andrea Cosentino"
}
],
"descriptions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003ePermissive Cross-domain Policy with Untrusted Domains vulnerability in Apache Camel Jetty component.\u003cbr\u003e\u003cbr\u003eThis issue affects Apache Camel: from 4.0.0 before 4.18.5, from 4.19.0 before 4.22.1.\u003cbr\u003e\u003cbr\u003eSetting enableCORS on a Jetty endpoint installed Jetty\u0027s CrossOriginFilter with its stock defaults, which accept every origin and allow credentials. An operator asking for CORS therefore obtained a policy that lets a page on any origin make credentialed cross-origin requests to the endpoint and read the responses, without any indication that turning the option on had chosen an allow-all policy rather than an empty one to be filled in. This is the same defect class as the platform-http-vertx advisory published alongside it, in a different component.\u003cbr\u003e\u003cbr\u003eUpgrade to Apache Camel 4.23.0, which fixes the issue. Users on the 4.18.x LTS releases stream should upgrade to 4.18.5. Users on the 4.22.x LTS releases stream should upgrade to 4.22.1. enableCORS no longer grants credentials to an origin the operator did not name. A deployment that relied on any origin being accepted must now list its origins explicitly. For deployments that cannot upgrade immediately, configure the CrossOriginFilter parameters explicitly rather than relying on what enableCORS installs, naming the allowed origins.\u003c/p\u003e"
}
],
"value": "Permissive Cross-domain Policy with Untrusted Domains vulnerability in Apache Camel Jetty component.\n\nThis issue affects Apache Camel: from 4.0.0 before 4.18.5, from 4.19.0 before 4.22.1.\n\nSetting enableCORS on a Jetty endpoint installed Jetty\u0027s CrossOriginFilter with its stock defaults, which accept every origin and allow credentials. An operator asking for CORS therefore obtained a policy that lets a page on any origin make credentialed cross-origin requests to the endpoint and read the responses, without any indication that turning the option on had chosen an allow-all policy rather than an empty one to be filled in. This is the same defect class as the platform-http-vertx advisory published alongside it, in a different component.\n\nUpgrade to Apache Camel 4.23.0, which fixes the issue. Users on the 4.18.x LTS releases stream should upgrade to 4.18.5. Users on the 4.22.x LTS releases stream should upgrade to 4.22.1. enableCORS no longer grants credentials to an origin the operator did not name. A deployment that relied on any origin being accepted must now list its origins explicitly. For deployments that cannot upgrade immediately, configure the CrossOriginFilter parameters explicitly rather than relying on what enableCORS installs, naming the allowed origins."
}
],
"metrics": [
{
"cvssV3_1": {
"attackComplexity": "LOW",
"attackVector": "NETWORK",
"availabilityImpact": "NONE",
"baseScore": 4.3,
"baseSeverity": "MEDIUM",
"confidentialityImpact": "LOW",
"integrityImpact": "NONE",
"privilegesRequired": "NONE",
"scope": "UNCHANGED",
"userInteraction": "REQUIRED",
"vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:N/A:N",
"version": "3.1"
},
"format": "CVSS",
"scenarios": [
{
"lang": "en",
"value": "GENERAL"
}
]
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-942",
"description": "CWE-942 Permissive Cross-domain Policy with Untrusted Domains",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-10-19T10:40:58.206Z",
"orgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
"shortName": "apache"
},
"references": [
{
"name": "Apache Camel Security Advisory - CVE-2026-85313",
"tags": [
"vendor-advisory"
],
"url": "https://camel.apache.org/security/CVE-2026-85313.html"
},
{
"name": "CAMEL-24450",
"tags": [
"issue-tracking"
],
"url": "https://issues.apache.org/jira/browse/CAMEL-24450"
},
{
"name": "Fix on main, released in 4.23.0 (commit 6e3e4ec510b4966c70ad99b3c032e27d6adbef9d)",
"tags": [
"patch"
],
"url": "https://github.com/apache/camel/pull/25829"
},
{
"name": "Backport to camel-4.22.x, released in 4.22.1 (commit b0399b181d26cd8b136fa98b54ec8e5c283338da)",
"tags": [
"patch"
],
"url": "https://github.com/apache/camel/pull/25937"
},
{
"name": "Backport to camel-4.18.x, released in 4.18.5 (commit e23332aec12f7ec3a841e52d1821e2a580c2fbc7)",
"tags": [
"patch"
],
"url": "https://github.com/apache/camel/pull/25938"
}
],
"solutions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eUpgrade to Apache Camel 4.23.0, which fixes the issue. Users on the 4.18.x LTS releases stream should upgrade to 4.18.5. Users on the 4.22.x LTS releases stream should upgrade to 4.22.1. enableCORS no longer grants credentials to an origin the operator did not name. A deployment that relied on any origin being accepted must now list its origins explicitly.\u003c/p\u003e"
}
],
"value": "Upgrade to Apache Camel 4.23.0, which fixes the issue. Users on the 4.18.x LTS releases stream should upgrade to 4.18.5. Users on the 4.22.x LTS releases stream should upgrade to 4.22.1. enableCORS no longer grants credentials to an origin the operator did not name. A deployment that relied on any origin being accepted must now list its origins explicitly."
}
],
"source": {
"discovery": "UNKNOWN"
},
"title": "Apache Camel: Camel-Jetty Cross-Origin Credential Exposure via Allow-All CrossOriginFilter Defaults When enableCORS Is Set",
"workarounds": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eFor deployments that cannot upgrade immediately, configure the CrossOriginFilter parameters explicitly rather than relying on what enableCORS installs, naming the allowed origins.\u003c/p\u003e"
}
],
"value": "For deployments that cannot upgrade immediately, configure the CrossOriginFilter parameters explicitly rather than relying on what enableCORS installs, naming the allowed origins."
}
],
"x_generator": {
"engine": "Vulnogram 1.0.3"
}
}
},
"cveMetadata": {
"assignerOrgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
"assignerShortName": "apache",
"cveId": "CVE-2026-85313",
"datePublished": "2026-10-19T10:40:58.206Z",
"dateReserved": "2026-09-03T16:43:32.647Z",
"dateUpdated": "2026-10-19T14:33:28.013Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2026-85312 (GCVE-0-2026-85312)
Vulnerability from cvelistv5
Published
2026-10-19 10:40
Modified
2026-10-19 14:34
Severity ?
VLAI Severity ?
EPSS score ?
CWE
- CWE-20 - Improper Input Validation
Summary
Improper Input Validation vulnerability in Apache Camel Core component.
This issue affects Apache Camel: from 4.0.0 before 4.18.5, from 4.19.0 before 4.22.1.
The saga processor consulted a header named Long-Running-Action to decide which saga an exchange belonged to. The name carries no Camel prefix, so it sits outside the namespace that consumer header filters block, and an external sender could supply it on an inbound message. That let the sender name the saga the exchange joined, attaching their request to a long-running action started by someone else, or causing compensation to be associated with an action they did not initiate. The header is only consulted by a saga service that uses it, which bounds the exposure to deployments running sagas over an LRA coordinator.
Upgrade to Apache Camel 4.23.0, which fixes the issue. Users on the 4.18.x LTS releases stream should upgrade to 4.18.5. Users on the 4.22.x LTS releases stream should upgrade to 4.22.1. The header is now consulted only for a saga service that actually uses it, rather than on every exchange. For deployments that cannot upgrade immediately, strip the header at the trust boundary with removeHeaders("Long-Running-Action") on every consumer that accepts messages from an untrusted sender.
References
| URL | Tags | |
|---|---|---|
Impacted products
| Vendor | Product | Version | ||
|---|---|---|---|---|
| Apache Software Foundation | Apache Camel |
Version: 4.0.0 Version: 4.19.0 |
{
"containers": {
"adp": [
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2026-85312",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "no"
},
{
"Technical Impact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-10-19T14:33:54.394645Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-10-19T14:34:13.505Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"collectionURL": "https://repo.maven.apache.org/maven2",
"defaultStatus": "unaffected",
"packageName": "org.apache.camel:camel-core",
"packageURL": "pkg:maven/org.apache.camel/camel-core",
"product": "Apache Camel",
"vendor": "Apache Software Foundation",
"versions": [
{
"lessThan": "4.18.5",
"status": "affected",
"version": "4.0.0",
"versionType": "maven"
},
{
"lessThan": "4.22.1",
"status": "affected",
"version": "4.19.0",
"versionType": "maven"
},
{
"status": "unaffected",
"version": "4.18.5",
"versionType": "maven"
},
{
"status": "unaffected",
"version": "4.22.1",
"versionType": "maven"
},
{
"status": "unaffected",
"version": "4.23.0",
"versionType": "maven"
}
]
}
],
"credits": [
{
"lang": "en",
"type": "finder",
"value": "Claude Security"
},
{
"lang": "en",
"type": "remediation developer",
"value": "Andrea Cosentino"
}
],
"descriptions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eImproper Input Validation vulnerability in Apache Camel Core component.\u003cbr\u003e\u003cbr\u003eThis issue affects Apache Camel: from 4.0.0 before 4.18.5, from 4.19.0 before 4.22.1.\u003cbr\u003e\u003cbr\u003eThe saga processor consulted a header named Long-Running-Action to decide which saga an exchange belonged to. The name carries no Camel prefix, so it sits outside the namespace that consumer header filters block, and an external sender could supply it on an inbound message. That let the sender name the saga the exchange joined, attaching their request to a long-running action started by someone else, or causing compensation to be associated with an action they did not initiate. The header is only consulted by a saga service that uses it, which bounds the exposure to deployments running sagas over an LRA coordinator.\u003cbr\u003e\u003cbr\u003eUpgrade to Apache Camel 4.23.0, which fixes the issue. Users on the 4.18.x LTS releases stream should upgrade to 4.18.5. Users on the 4.22.x LTS releases stream should upgrade to 4.22.1. The header is now consulted only for a saga service that actually uses it, rather than on every exchange. For deployments that cannot upgrade immediately, strip the header at the trust boundary with removeHeaders(\"Long-Running-Action\") on every consumer that accepts messages from an untrusted sender.\u003c/p\u003e"
}
],
"value": "Improper Input Validation vulnerability in Apache Camel Core component.\n\nThis issue affects Apache Camel: from 4.0.0 before 4.18.5, from 4.19.0 before 4.22.1.\n\nThe saga processor consulted a header named Long-Running-Action to decide which saga an exchange belonged to. The name carries no Camel prefix, so it sits outside the namespace that consumer header filters block, and an external sender could supply it on an inbound message. That let the sender name the saga the exchange joined, attaching their request to a long-running action started by someone else, or causing compensation to be associated with an action they did not initiate. The header is only consulted by a saga service that uses it, which bounds the exposure to deployments running sagas over an LRA coordinator.\n\nUpgrade to Apache Camel 4.23.0, which fixes the issue. Users on the 4.18.x LTS releases stream should upgrade to 4.18.5. Users on the 4.22.x LTS releases stream should upgrade to 4.22.1. The header is now consulted only for a saga service that actually uses it, rather than on every exchange. For deployments that cannot upgrade immediately, strip the header at the trust boundary with removeHeaders(\"Long-Running-Action\") on every consumer that accepts messages from an untrusted sender."
}
],
"metrics": [
{
"cvssV3_1": {
"attackComplexity": "HIGH",
"attackVector": "NETWORK",
"availabilityImpact": "NONE",
"baseScore": 4.8,
"baseSeverity": "MEDIUM",
"confidentialityImpact": "LOW",
"integrityImpact": "LOW",
"privilegesRequired": "NONE",
"scope": "UNCHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N",
"version": "3.1"
},
"format": "CVSS",
"scenarios": [
{
"lang": "en",
"value": "GENERAL"
}
]
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-20",
"description": "CWE-20 Improper Input Validation",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-10-19T10:40:30.029Z",
"orgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
"shortName": "apache"
},
"references": [
{
"name": "Apache Camel Security Advisory - CVE-2026-85312",
"tags": [
"vendor-advisory"
],
"url": "https://camel.apache.org/security/CVE-2026-85312.html"
},
{
"name": "CAMEL-24449",
"tags": [
"issue-tracking"
],
"url": "https://issues.apache.org/jira/browse/CAMEL-24449"
},
{
"name": "Fix on main, released in 4.23.0 (commit dfde003151a0753f997f9eea7d071097f4b00db2)",
"tags": [
"patch"
],
"url": "https://github.com/apache/camel/pull/25828"
},
{
"name": "Backport to camel-4.22.x, released in 4.22.1 (commit 260989268cbc6d258b1fcba63770be8ebbec40cb)",
"tags": [
"patch"
],
"url": "https://github.com/apache/camel/pull/25940"
},
{
"name": "Backport to camel-4.18.x, released in 4.18.5 (commit af1efbcccf5882b1ef0094db718972da3190e7e9)",
"tags": [
"patch"
],
"url": "https://github.com/apache/camel/pull/25942"
}
],
"solutions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eUpgrade to Apache Camel 4.23.0, which fixes the issue. Users on the 4.18.x LTS releases stream should upgrade to 4.18.5. Users on the 4.22.x LTS releases stream should upgrade to 4.22.1. The header is now consulted only for a saga service that actually uses it, rather than on every exchange.\u003c/p\u003e"
}
],
"value": "Upgrade to Apache Camel 4.23.0, which fixes the issue. Users on the 4.18.x LTS releases stream should upgrade to 4.18.5. Users on the 4.22.x LTS releases stream should upgrade to 4.22.1. The header is now consulted only for a saga service that actually uses it, rather than on every exchange."
}
],
"source": {
"discovery": "UNKNOWN"
},
"title": "Apache Camel: Camel-Core Saga Participation Hijacking via the Unfiltered Long-Running-Action Header",
"workarounds": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eFor deployments that cannot upgrade immediately, strip the header at the trust boundary with removeHeaders(\u0026quot;Long-Running-Action\u0026quot;) on every consumer that accepts messages from an untrusted sender.\u003c/p\u003e"
}
],
"value": "For deployments that cannot upgrade immediately, strip the header at the trust boundary with removeHeaders(\"Long-Running-Action\") on every consumer that accepts messages from an untrusted sender."
}
],
"x_generator": {
"engine": "Vulnogram 1.0.3"
}
}
},
"cveMetadata": {
"assignerOrgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
"assignerShortName": "apache",
"cveId": "CVE-2026-85312",
"datePublished": "2026-10-19T10:40:26.439Z",
"dateReserved": "2026-09-03T16:43:01.279Z",
"dateUpdated": "2026-10-19T14:34:13.505Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2026-85300 (GCVE-0-2026-85300)
Vulnerability from cvelistv5
Published
2026-10-19 10:40
Modified
2026-10-19 14:35
Severity ?
VLAI Severity ?
EPSS score ?
CWE
- CWE-276 - Incorrect Default Permissions
Summary
Incorrect Default Permissions vulnerability in Apache Camel PQC component.
This issue affects Apache Camel: from 4.12.0 before 4.18.5, from 4.19.0 before 4.22.1.
When the component wrote generated key material to disk it did so with the permissions the process default umask produced, rather than restricting the file to its owner. On a host whose umask allows group or world read, the private key was therefore readable by other local accounts. The exposure is to a local party rather than to the remote sender that the Camel threat model treats as the primary adversary, which is why the severity is assessed low, but the consequence where it applies is complete: possession of the private key defeats every signature and key exchange the deployment performs with it.
Upgrade to Apache Camel 4.23.0, which fixes the issue. Users on the 4.18.x LTS releases stream should upgrade to 4.18.5. Users on the 4.22.x LTS releases stream should upgrade to 4.22.1. Key material is now written with owner-only permissions. For deployments that cannot upgrade immediately, place the key directory on a path only the service account can traverse, and tighten the process umask. Key material already written with permissive permissions should be treated as exposed and rotated.
References
| URL | Tags | |
|---|---|---|
Impacted products
| Vendor | Product | Version | ||
|---|---|---|---|---|
| Apache Software Foundation | Apache Camel |
Version: 4.12.0 Version: 4.19.0 |
{
"containers": {
"adp": [
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2026-85300",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "no"
},
{
"Technical Impact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-10-19T14:34:32.324506Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-10-19T14:35:02.757Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"collectionURL": "https://repo.maven.apache.org/maven2",
"defaultStatus": "unaffected",
"packageName": "org.apache.camel:camel-pqc",
"packageURL": "pkg:maven/org.apache.camel/camel-pqc",
"product": "Apache Camel",
"vendor": "Apache Software Foundation",
"versions": [
{
"lessThan": "4.18.5",
"status": "affected",
"version": "4.12.0",
"versionType": "maven"
},
{
"lessThan": "4.22.1",
"status": "affected",
"version": "4.19.0",
"versionType": "maven"
},
{
"status": "unaffected",
"version": "4.18.5",
"versionType": "maven"
},
{
"status": "unaffected",
"version": "4.22.1",
"versionType": "maven"
},
{
"status": "unaffected",
"version": "4.23.0",
"versionType": "maven"
}
]
}
],
"credits": [
{
"lang": "en",
"type": "finder",
"value": "Claude Security"
},
{
"lang": "en",
"type": "remediation developer",
"value": "Andrea Cosentino"
}
],
"descriptions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eIncorrect Default Permissions vulnerability in Apache Camel PQC component.\u003cbr\u003e\u003cbr\u003eThis issue affects Apache Camel: from 4.12.0 before 4.18.5, from 4.19.0 before 4.22.1.\u003cbr\u003e\u003cbr\u003eWhen the component wrote generated key material to disk it did so with the permissions the process default umask produced, rather than restricting the file to its owner. On a host whose umask allows group or world read, the private key was therefore readable by other local accounts. The exposure is to a local party rather than to the remote sender that the Camel threat model treats as the primary adversary, which is why the severity is assessed low, but the consequence where it applies is complete: possession of the private key defeats every signature and key exchange the deployment performs with it.\u003cbr\u003e\u003cbr\u003eUpgrade to Apache Camel 4.23.0, which fixes the issue. Users on the 4.18.x LTS releases stream should upgrade to 4.18.5. Users on the 4.22.x LTS releases stream should upgrade to 4.22.1. Key material is now written with owner-only permissions. For deployments that cannot upgrade immediately, place the key directory on a path only the service account can traverse, and tighten the process umask. Key material already written with permissive permissions should be treated as exposed and rotated.\u003c/p\u003e"
}
],
"value": "Incorrect Default Permissions vulnerability in Apache Camel PQC component.\n\nThis issue affects Apache Camel: from 4.12.0 before 4.18.5, from 4.19.0 before 4.22.1.\n\nWhen the component wrote generated key material to disk it did so with the permissions the process default umask produced, rather than restricting the file to its owner. On a host whose umask allows group or world read, the private key was therefore readable by other local accounts. The exposure is to a local party rather than to the remote sender that the Camel threat model treats as the primary adversary, which is why the severity is assessed low, but the consequence where it applies is complete: possession of the private key defeats every signature and key exchange the deployment performs with it.\n\nUpgrade to Apache Camel 4.23.0, which fixes the issue. Users on the 4.18.x LTS releases stream should upgrade to 4.18.5. Users on the 4.22.x LTS releases stream should upgrade to 4.22.1. Key material is now written with owner-only permissions. For deployments that cannot upgrade immediately, place the key directory on a path only the service account can traverse, and tighten the process umask. Key material already written with permissive permissions should be treated as exposed and rotated."
}
],
"metrics": [
{
"cvssV3_1": {
"attackComplexity": "LOW",
"attackVector": "LOCAL",
"availabilityImpact": "NONE",
"baseScore": 5.5,
"baseSeverity": "MEDIUM",
"confidentialityImpact": "HIGH",
"integrityImpact": "NONE",
"privilegesRequired": "LOW",
"scope": "UNCHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N",
"version": "3.1"
},
"format": "CVSS",
"scenarios": [
{
"lang": "en",
"value": "GENERAL"
}
]
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-276",
"description": "CWE-276 Incorrect Default Permissions",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-10-19T10:40:04.752Z",
"orgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
"shortName": "apache"
},
"references": [
{
"name": "Apache Camel Security Advisory - CVE-2026-85300",
"tags": [
"vendor-advisory"
],
"url": "https://camel.apache.org/security/CVE-2026-85300.html"
},
{
"name": "CAMEL-24447",
"tags": [
"issue-tracking"
],
"url": "https://issues.apache.org/jira/browse/CAMEL-24447"
},
{
"name": "Fix on main, released in 4.23.0 (commit 957b28aa7fad123bfafeea6bfb33a2b1d0a5a188)",
"tags": [
"patch"
],
"url": "https://github.com/apache/camel/pull/25826"
},
{
"name": "Backport to camel-4.22.x, released in 4.22.1 (commit fdb9642e53e47bd0588ab8394db634095e8a19cb)",
"tags": [
"patch"
],
"url": "https://github.com/apache/camel/pull/25856"
},
{
"name": "Backport to camel-4.18.x, released in 4.18.5 (commit 2b3e2028491566043955700f639f086c42b9d93a)",
"tags": [
"patch"
],
"url": "https://github.com/apache/camel/pull/25857"
}
],
"solutions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eUpgrade to Apache Camel 4.23.0, which fixes the issue. Users on the 4.18.x LTS releases stream should upgrade to 4.18.5. Users on the 4.22.x LTS releases stream should upgrade to 4.22.1. Key material is now written with owner-only permissions.\u003c/p\u003e"
}
],
"value": "Upgrade to Apache Camel 4.23.0, which fixes the issue. Users on the 4.18.x LTS releases stream should upgrade to 4.18.5. Users on the 4.22.x LTS releases stream should upgrade to 4.22.1. Key material is now written with owner-only permissions."
}
],
"source": {
"discovery": "UNKNOWN"
},
"title": "Apache Camel: Camel-PQC Private Key Disclosure via Key Material Written with Default File Permissions",
"workarounds": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eFor deployments that cannot upgrade immediately, place the key directory on a path only the service account can traverse, and tighten the process umask. Key material already written with permissive permissions should be treated as exposed and rotated.\u003c/p\u003e"
}
],
"value": "For deployments that cannot upgrade immediately, place the key directory on a path only the service account can traverse, and tighten the process umask. Key material already written with permissive permissions should be treated as exposed and rotated."
}
],
"x_generator": {
"engine": "Vulnogram 1.0.3"
}
}
},
"cveMetadata": {
"assignerOrgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
"assignerShortName": "apache",
"cveId": "CVE-2026-85300",
"datePublished": "2026-10-19T10:40:04.752Z",
"dateReserved": "2026-09-03T16:39:46.231Z",
"dateUpdated": "2026-10-19T14:35:02.757Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2026-85301 (GCVE-0-2026-85301)
Vulnerability from cvelistv5
Published
2026-10-19 10:39
Modified
2026-10-19 14:35
Severity ?
VLAI Severity ?
EPSS score ?
CWE
- CWE-287 - Improper Authentication
Summary
Improper Authentication vulnerability in Apache Camel Keycloak component.
This issue affects Apache Camel: from 4.15.0 before 4.18.5, from 4.19.0 before 4.22.1.
The security processor validated the issuer of an introspected token only when the introspection response actually carried an iss claim. When the claim was absent the check was skipped rather than treated as a failure, so a token that the configured issuer did not mint could be accepted provided the introspection endpoint answered without naming an issuer. Reaching this requires an introspection endpoint that omits iss and accepts tokens from more than one issuer, which is not the default Keycloak arrangement, hence the low severity; where that arrangement exists the consequence is that the deployment authenticates a caller it should have rejected.
Upgrade to Apache Camel 4.23.0, which fixes the issue. Users on the 4.18.x LTS releases stream should upgrade to 4.18.5. Users on the 4.22.x LTS releases stream should upgrade to 4.22.1. An absent iss claim is now treated as a validation failure rather than as a reason to skip the check. For deployments that cannot upgrade immediately, ensure the introspection endpoint returns the iss claim, and that it serves exactly one issuer.
References
| URL | Tags | |
|---|---|---|
Impacted products
| Vendor | Product | Version | ||
|---|---|---|---|---|
| Apache Software Foundation | Apache Camel |
Version: 4.15.0 Version: 4.19.0 |
{
"containers": {
"adp": [
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2026-85301",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "no"
},
{
"Technical Impact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-10-19T14:35:43.367454Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-10-19T14:35:58.104Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"collectionURL": "https://repo.maven.apache.org/maven2",
"defaultStatus": "unaffected",
"packageName": "org.apache.camel:camel-keycloak",
"packageURL": "pkg:maven/org.apache.camel/camel-keycloak",
"product": "Apache Camel",
"vendor": "Apache Software Foundation",
"versions": [
{
"lessThan": "4.18.5",
"status": "affected",
"version": "4.15.0",
"versionType": "maven"
},
{
"lessThan": "4.22.1",
"status": "affected",
"version": "4.19.0",
"versionType": "maven"
},
{
"status": "unaffected",
"version": "4.18.5",
"versionType": "maven"
},
{
"status": "unaffected",
"version": "4.22.1",
"versionType": "maven"
},
{
"status": "unaffected",
"version": "4.23.0",
"versionType": "maven"
}
]
}
],
"credits": [
{
"lang": "en",
"type": "finder",
"value": "Claude Security"
},
{
"lang": "en",
"type": "remediation developer",
"value": "Andrea Cosentino"
}
],
"descriptions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eImproper Authentication vulnerability in Apache Camel Keycloak component.\u003cbr\u003e\u003cbr\u003eThis issue affects Apache Camel: from 4.15.0 before 4.18.5, from 4.19.0 before 4.22.1.\u003c/p\u003e\u003cp\u003e\u003cbr\u003eThe security processor validated the issuer of an introspected token only when the introspection response actually carried an iss claim. When the claim was absent the check was skipped rather than treated as a failure, so a token that the configured issuer did not mint could be accepted provided the introspection endpoint answered without naming an issuer. Reaching this requires an introspection endpoint that omits iss and accepts tokens from more than one issuer, which is not the default Keycloak arrangement, hence the low severity; where that arrangement exists the consequence is that the deployment authenticates a caller it should have rejected.\u003cbr\u003e\u003cbr\u003eUpgrade to Apache Camel 4.23.0, which fixes the issue. Users on the 4.18.x LTS releases stream should upgrade to 4.18.5. Users on the 4.22.x LTS releases stream should upgrade to 4.22.1. An absent iss claim is now treated as a validation failure rather than as a reason to skip the check. For deployments that cannot upgrade immediately, ensure the introspection endpoint returns the iss claim, and that it serves exactly one issuer.\u003c/p\u003e"
}
],
"value": "Improper Authentication vulnerability in Apache Camel Keycloak component.\n\nThis issue affects Apache Camel: from 4.15.0 before 4.18.5, from 4.19.0 before 4.22.1.\n\n\n\n\nThe security processor validated the issuer of an introspected token only when the introspection response actually carried an iss claim. When the claim was absent the check was skipped rather than treated as a failure, so a token that the configured issuer did not mint could be accepted provided the introspection endpoint answered without naming an issuer. Reaching this requires an introspection endpoint that omits iss and accepts tokens from more than one issuer, which is not the default Keycloak arrangement, hence the low severity; where that arrangement exists the consequence is that the deployment authenticates a caller it should have rejected.\n\nUpgrade to Apache Camel 4.23.0, which fixes the issue. Users on the 4.18.x LTS releases stream should upgrade to 4.18.5. Users on the 4.22.x LTS releases stream should upgrade to 4.22.1. An absent iss claim is now treated as a validation failure rather than as a reason to skip the check. For deployments that cannot upgrade immediately, ensure the introspection endpoint returns the iss claim, and that it serves exactly one issuer."
}
],
"metrics": [
{
"cvssV3_1": {
"attackComplexity": "HIGH",
"attackVector": "NETWORK",
"availabilityImpact": "NONE",
"baseScore": 4.8,
"baseSeverity": "MEDIUM",
"confidentialityImpact": "LOW",
"integrityImpact": "LOW",
"privilegesRequired": "NONE",
"scope": "UNCHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N",
"version": "3.1"
},
"format": "CVSS",
"scenarios": [
{
"lang": "en",
"value": "GENERAL"
}
]
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-287",
"description": "CWE-287 Improper Authentication",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-10-19T10:39:46.650Z",
"orgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
"shortName": "apache"
},
"references": [
{
"name": "Apache Camel Security Advisory - CVE-2026-85301",
"tags": [
"vendor-advisory"
],
"url": "https://camel.apache.org/security/CVE-2026-85301.html"
},
{
"name": "CAMEL-24448",
"tags": [
"issue-tracking"
],
"url": "https://issues.apache.org/jira/browse/CAMEL-24448"
},
{
"name": "Fix on main, released in 4.23.0 (commit ee074873e92dde749aa183d26205b92ddc9bde2a)",
"tags": [
"patch"
],
"url": "https://github.com/apache/camel/pull/25827"
},
{
"name": "Backport to camel-4.22.x, released in 4.22.1 (commit c9e69aae7b374cc38d28c1c8dca744c1ba4d6718)",
"tags": [
"patch"
],
"url": "https://github.com/apache/camel/pull/25858"
},
{
"name": "Backport to camel-4.18.x, released in 4.18.5 (commit aba0f7551e4f63e1f37498454870a49ccdaae727)",
"tags": [
"patch"
],
"url": "https://github.com/apache/camel/pull/25859"
}
],
"solutions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eUpgrade to Apache Camel 4.23.0, which fixes the issue. Users on the 4.18.x LTS releases stream should upgrade to 4.18.5. Users on the 4.22.x LTS releases stream should upgrade to 4.22.1. An absent iss claim is now treated as a validation failure rather than as a reason to skip the check.\u003c/p\u003e"
}
],
"value": "Upgrade to Apache Camel 4.23.0, which fixes the issue. Users on the 4.18.x LTS releases stream should upgrade to 4.18.5. Users on the 4.22.x LTS releases stream should upgrade to 4.22.1. An absent iss claim is now treated as a validation failure rather than as a reason to skip the check."
}
],
"source": {
"discovery": "UNKNOWN"
},
"title": "Apache Camel: Camel-Keycloak Issuer Validation Bypass When the Introspection Response Omits the iss Claim",
"workarounds": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eFor deployments that cannot upgrade immediately, ensure the introspection endpoint returns the iss claim, and that it serves exactly one issuer.\u003c/p\u003e"
}
],
"value": "For deployments that cannot upgrade immediately, ensure the introspection endpoint returns the iss claim, and that it serves exactly one issuer."
}
],
"x_generator": {
"engine": "Vulnogram 1.0.3"
}
}
},
"cveMetadata": {
"assignerOrgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
"assignerShortName": "apache",
"cveId": "CVE-2026-85301",
"datePublished": "2026-10-19T10:39:46.650Z",
"dateReserved": "2026-09-03T16:41:14.419Z",
"dateUpdated": "2026-10-19T14:35:58.104Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2026-85296 (GCVE-0-2026-85296)
Vulnerability from cvelistv5
Published
2026-10-19 10:38
Modified
2026-10-19 16:46
Severity ?
VLAI Severity ?
EPSS score ?
CWE
- CWE-488 - Exposure of Data Element to Wrong Session
Summary
Exposure of Data Element to Wrong Session vulnerability in Apache Camel AS2 component.
This issue affects Apache Camel: from 4.0.0 before 4.18.5, from 4.19.0 before 4.22.1.
Signing material belonging to an individual request was stored in state that is shared across requests rather than confined to the request being processed. Where a deployment serves more than one trading partner, concurrent or successive requests could therefore observe each other's material, and a Message Disposition Notification could be signed with the key of a partner other than the one the receipt was for. The result is cross-partner key confusion: a receipt attributable to the wrong partner, and one partner's signing material used while handling another partner's exchange. AS2 deployments are typically multi-partner by design, so the condition is reached by ordinary concurrent traffic rather than by anything the attacker must arrange.
Upgrade to Apache Camel 4.23.0, which fixes the issue. Users on the 4.18.x LTS releases stream should upgrade to 4.18.5. Users on the 4.22.x LTS releases stream should upgrade to 4.22.1. Per-request signing keys are now confined to the request being processed in ResponseMDN. For deployments that cannot upgrade immediately, run a separate Camel context per trading partner so that no signing material is shared between them.
References
| URL | Tags | |
|---|---|---|
Impacted products
| Vendor | Product | Version | ||
|---|---|---|---|---|
| Apache Software Foundation | Apache Camel |
Version: 4.0.0 Version: 4.19.0 |
{
"containers": {
"adp": [
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2026-85296",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "no"
},
{
"Technical Impact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-10-19T16:46:14.078587Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-10-19T16:46:25.273Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"collectionURL": "https://repo.maven.apache.org/maven2",
"defaultStatus": "unaffected",
"packageName": "org.apache.camel:camel-as2",
"packageURL": "pkg:maven/org.apache.camel/camel-as2",
"product": "Apache Camel",
"vendor": "Apache Software Foundation",
"versions": [
{
"lessThan": "4.18.5",
"status": "affected",
"version": "4.0.0",
"versionType": "maven"
},
{
"lessThan": "4.22.1",
"status": "affected",
"version": "4.19.0",
"versionType": "maven"
},
{
"status": "unaffected",
"version": "4.18.5",
"versionType": "maven"
},
{
"status": "unaffected",
"version": "4.22.1",
"versionType": "maven"
},
{
"status": "unaffected",
"version": "4.23.0",
"versionType": "maven"
}
]
}
],
"credits": [
{
"lang": "en",
"type": "finder",
"value": "Claude Security"
},
{
"lang": "en",
"type": "remediation developer",
"value": "Andrea Cosentino"
}
],
"descriptions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eExposure of Data Element to Wrong Session vulnerability in Apache Camel AS2 component.\u003cbr\u003e\u003cbr\u003eThis issue affects Apache Camel: from 4.0.0 before 4.18.5, from 4.19.0 before 4.22.1.\u003cbr\u003e\u003cbr\u003eSigning material belonging to an individual request was stored in state that is shared across requests rather than confined to the request being processed. Where a deployment serves more than one trading partner, concurrent or successive requests could therefore observe each other\u0027s material, and a Message Disposition Notification could be signed with the key of a partner other than the one the receipt was for. The result is cross-partner key confusion: a receipt attributable to the wrong partner, and one partner\u0027s signing material used while handling another partner\u0027s exchange. AS2 deployments are typically multi-partner by design, so the condition is reached by ordinary concurrent traffic rather than by anything the attacker must arrange.\u003cbr\u003e\u003cbr\u003eUpgrade to Apache Camel 4.23.0, which fixes the issue. Users on the 4.18.x LTS releases stream should upgrade to 4.18.5. Users on the 4.22.x LTS releases stream should upgrade to 4.22.1. Per-request signing keys are now confined to the request being processed in ResponseMDN. For deployments that cannot upgrade immediately, run a separate Camel context per trading partner so that no signing material is shared between them.\u003c/p\u003e"
}
],
"value": "Exposure of Data Element to Wrong Session vulnerability in Apache Camel AS2 component.\n\nThis issue affects Apache Camel: from 4.0.0 before 4.18.5, from 4.19.0 before 4.22.1.\n\nSigning material belonging to an individual request was stored in state that is shared across requests rather than confined to the request being processed. Where a deployment serves more than one trading partner, concurrent or successive requests could therefore observe each other\u0027s material, and a Message Disposition Notification could be signed with the key of a partner other than the one the receipt was for. The result is cross-partner key confusion: a receipt attributable to the wrong partner, and one partner\u0027s signing material used while handling another partner\u0027s exchange. AS2 deployments are typically multi-partner by design, so the condition is reached by ordinary concurrent traffic rather than by anything the attacker must arrange.\n\nUpgrade to Apache Camel 4.23.0, which fixes the issue. Users on the 4.18.x LTS releases stream should upgrade to 4.18.5. Users on the 4.22.x LTS releases stream should upgrade to 4.22.1. Per-request signing keys are now confined to the request being processed in ResponseMDN. For deployments that cannot upgrade immediately, run a separate Camel context per trading partner so that no signing material is shared between them."
}
],
"metrics": [
{
"cvssV3_1": {
"attackComplexity": "HIGH",
"attackVector": "NETWORK",
"availabilityImpact": "NONE",
"baseScore": 6.5,
"baseSeverity": "MEDIUM",
"confidentialityImpact": "HIGH",
"integrityImpact": "LOW",
"privilegesRequired": "NONE",
"scope": "UNCHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:L/A:N",
"version": "3.1"
},
"format": "CVSS",
"scenarios": [
{
"lang": "en",
"value": "GENERAL"
}
]
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-488",
"description": "CWE-488 Exposure of Data Element to Wrong Session",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-10-19T10:38:11.146Z",
"orgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
"shortName": "apache"
},
"references": [
{
"name": "Apache Camel Security Advisory - CVE-2026-85296",
"tags": [
"vendor-advisory"
],
"url": "https://camel.apache.org/security/CVE-2026-85296.html"
},
{
"name": "CAMEL-24429",
"tags": [
"issue-tracking"
],
"url": "https://issues.apache.org/jira/browse/CAMEL-24429"
},
{
"name": "Fix on main, released in 4.23.0 (commit 659176dec58522fbebea11a1f6d5ee5c37f235d9)",
"tags": [
"patch"
],
"url": "https://github.com/apache/camel/pull/25641"
},
{
"name": "Backport to camel-4.22.x, released in 4.22.1 (commit ab5eacd3fa485eb990cf021dc56e48465c060d39)",
"tags": [
"patch"
],
"url": "https://github.com/apache/camel/pull/25869"
},
{
"name": "Backport to camel-4.18.x, released in 4.18.5 (commit 19f91785f9e975e7734efd514946c2dfdbdbd1d7)",
"tags": [
"patch"
],
"url": "https://github.com/apache/camel/pull/25870"
}
],
"solutions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eUpgrade to Apache Camel 4.23.0, which fixes the issue. Users on the 4.18.x LTS releases stream should upgrade to 4.18.5. Users on the 4.22.x LTS releases stream should upgrade to 4.22.1. Per-request signing keys are now confined to the request being processed in ResponseMDN.\u003c/p\u003e"
}
],
"value": "Upgrade to Apache Camel 4.23.0, which fixes the issue. Users on the 4.18.x LTS releases stream should upgrade to 4.18.5. Users on the 4.22.x LTS releases stream should upgrade to 4.22.1. Per-request signing keys are now confined to the request being processed in ResponseMDN."
}
],
"source": {
"discovery": "UNKNOWN"
},
"title": "Apache Camel: Camel-AS2 Cross-Partner Signing Key Confusion via Shared Per-Request State",
"workarounds": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eFor deployments that cannot upgrade immediately, run a separate Camel context per trading partner so that no signing material is shared between them.\u003c/p\u003e"
}
],
"value": "For deployments that cannot upgrade immediately, run a separate Camel context per trading partner so that no signing material is shared between them."
}
],
"x_generator": {
"engine": "Vulnogram 1.0.3"
}
}
},
"cveMetadata": {
"assignerOrgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
"assignerShortName": "apache",
"cveId": "CVE-2026-85296",
"datePublished": "2026-10-19T10:38:11.146Z",
"dateReserved": "2026-09-03T16:37:54.485Z",
"dateUpdated": "2026-10-19T16:46:25.273Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2026-85260 (GCVE-0-2026-85260)
Vulnerability from cvelistv5
Published
2026-10-19 10:37
Modified
2026-10-19 16:47
Severity ?
VLAI Severity ?
EPSS score ?
CWE
- CWE-532 - Insertion of Sensitive Information into Log File
Summary
Insertion of Sensitive Information into Log File vulnerability in Apache Camel MLLP component.
This issue affects Apache Camel: from 4.0.0 before 4.18.5, from 4.19.0 before 4.22.1.
The camel-mllp component carries a logPhi option that governs whether HL7 payload content may be written to the log. It defaulted to true, so a deployment that did nothing logged protected health information out of the box. Two further paths wrote payload content to the log regardless of the setting, so even an operator who had turned logPhi off was still exposed on those paths. MLLP is used to carry HL7 clinical messages, so the content concerned is patient data, and it reached ordinary application logs where it is subject to whatever retention, aggregation and access the deployment applies to logs generally rather than to clinical records.
Upgrade to Apache Camel 4.23.0, which fixes the issue. Users on the 4.18.x LTS releases stream should upgrade to 4.18.5. Users on the 4.22.x LTS releases stream should upgrade to 4.22.1. logPhi now defaults to false and is honoured on the paths that previously ignored it. This is a changed default: a deployment that relied on payload logging must now set logPhi=true explicitly. Because the upgrade guide for a change like this lives on the main branch only, operators upgrading within the 4.18.x or 4.22.x lines should treat this advisory as the notice of that change. For deployments that cannot upgrade immediately, set logPhi=false and be aware that two paths will continue to log payload content until the fix is applied; restrict access to the logs accordingly.
References
| URL | Tags | |
|---|---|---|
Impacted products
| Vendor | Product | Version | ||
|---|---|---|---|---|
| Apache Software Foundation | Apache Camel |
Version: 4.0.0 Version: 4.19.0 |
{
"containers": {
"adp": [
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2026-85260",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "no"
},
{
"Technical Impact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-10-19T16:46:52.790872Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-10-19T16:47:15.565Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"collectionURL": "https://repo.maven.apache.org/maven2",
"defaultStatus": "unaffected",
"packageName": "org.apache.camel:camel-mllp",
"packageURL": "pkg:maven/org.apache.camel/camel-mllp",
"product": "Apache Camel",
"vendor": "Apache Software Foundation",
"versions": [
{
"lessThan": "4.18.5",
"status": "affected",
"version": "4.0.0",
"versionType": "maven"
},
{
"lessThan": "4.22.1",
"status": "affected",
"version": "4.19.0",
"versionType": "maven"
},
{
"status": "unaffected",
"version": "4.18.5",
"versionType": "maven"
},
{
"status": "unaffected",
"version": "4.22.1",
"versionType": "maven"
},
{
"status": "unaffected",
"version": "4.23.0",
"versionType": "maven"
}
]
}
],
"credits": [
{
"lang": "en",
"type": "finder",
"value": "Claude Security"
},
{
"lang": "en",
"type": "remediation developer",
"value": "Andrea Cosentino"
}
],
"descriptions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eInsertion of Sensitive Information into Log File vulnerability in Apache Camel MLLP component.\u003cbr\u003e\u003cbr\u003eThis issue affects Apache Camel: from 4.0.0 before 4.18.5, from 4.19.0 before 4.22.1.\u003cbr\u003e\u003cbr\u003eThe camel-mllp component carries a logPhi option that governs whether HL7 payload content may be written to the log. It defaulted to true, so a deployment that did nothing logged protected health information out of the box. Two further paths wrote payload content to the log regardless of the setting, so even an operator who had turned logPhi off was still exposed on those paths. MLLP is used to carry HL7 clinical messages, so the content concerned is patient data, and it reached ordinary application logs where it is subject to whatever retention, aggregation and access the deployment applies to logs generally rather than to clinical records.\u003cbr\u003e\u003cbr\u003eUpgrade to Apache Camel 4.23.0, which fixes the issue. Users on the 4.18.x LTS releases stream should upgrade to 4.18.5. Users on the 4.22.x LTS releases stream should upgrade to 4.22.1. logPhi now defaults to false and is honoured on the paths that previously ignored it. This is a changed default: a deployment that relied on payload logging must now set logPhi=true explicitly. Because the upgrade guide for a change like this lives on the main branch only, operators upgrading within the 4.18.x or 4.22.x lines should treat this advisory as the notice of that change. For deployments that cannot upgrade immediately, set logPhi=false and be aware that two paths will continue to log payload content until the fix is applied; restrict access to the logs accordingly.\u003c/p\u003e"
}
],
"value": "Insertion of Sensitive Information into Log File vulnerability in Apache Camel MLLP component.\n\nThis issue affects Apache Camel: from 4.0.0 before 4.18.5, from 4.19.0 before 4.22.1.\n\nThe camel-mllp component carries a logPhi option that governs whether HL7 payload content may be written to the log. It defaulted to true, so a deployment that did nothing logged protected health information out of the box. Two further paths wrote payload content to the log regardless of the setting, so even an operator who had turned logPhi off was still exposed on those paths. MLLP is used to carry HL7 clinical messages, so the content concerned is patient data, and it reached ordinary application logs where it is subject to whatever retention, aggregation and access the deployment applies to logs generally rather than to clinical records.\n\nUpgrade to Apache Camel 4.23.0, which fixes the issue. Users on the 4.18.x LTS releases stream should upgrade to 4.18.5. Users on the 4.22.x LTS releases stream should upgrade to 4.22.1. logPhi now defaults to false and is honoured on the paths that previously ignored it. This is a changed default: a deployment that relied on payload logging must now set logPhi=true explicitly. Because the upgrade guide for a change like this lives on the main branch only, operators upgrading within the 4.18.x or 4.22.x lines should treat this advisory as the notice of that change. For deployments that cannot upgrade immediately, set logPhi=false and be aware that two paths will continue to log payload content until the fix is applied; restrict access to the logs accordingly."
}
],
"metrics": [
{
"cvssV3_1": {
"attackComplexity": "LOW",
"attackVector": "LOCAL",
"availabilityImpact": "NONE",
"baseScore": 5.5,
"baseSeverity": "MEDIUM",
"confidentialityImpact": "HIGH",
"integrityImpact": "NONE",
"privilegesRequired": "LOW",
"scope": "UNCHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N",
"version": "3.1"
},
"format": "CVSS",
"scenarios": [
{
"lang": "en",
"value": "GENERAL"
}
]
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-532",
"description": "CWE-532 Insertion of Sensitive Information into Log File",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-10-19T10:37:42.980Z",
"orgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
"shortName": "apache"
},
"references": [
{
"name": "Apache Camel Security Advisory - CVE-2026-85260",
"tags": [
"vendor-advisory"
],
"url": "https://camel.apache.org/security/CVE-2026-85260.html"
},
{
"name": "CAMEL-24454",
"tags": [
"issue-tracking"
],
"url": "https://issues.apache.org/jira/browse/CAMEL-24454"
},
{
"name": "Fix on main, released in 4.23.0 (commit dd2bf57190c12ff7f1e97f121738867a680992ce)",
"tags": [
"patch"
],
"url": "https://github.com/apache/camel/pull/25832"
},
{
"name": "Backport to camel-4.22.x, released in 4.22.1 (commit 95b4c1500001bc32877df5b8fca0bc7bdd080666)",
"tags": [
"patch"
],
"url": "https://github.com/apache/camel/pull/25944"
},
{
"name": "Backport to camel-4.18.x, released in 4.18.5 (commit 4ec9b37d70b08c478966000fb1bd653abfe410e3)",
"tags": [
"patch"
],
"url": "https://github.com/apache/camel/pull/25946"
}
],
"solutions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eUpgrade to Apache Camel 4.23.0, which fixes the issue. Users on the 4.18.x LTS releases stream should upgrade to 4.18.5. Users on the 4.22.x LTS releases stream should upgrade to 4.22.1. logPhi now defaults to false and is honoured on the paths that previously ignored it. This is a changed default: a deployment that relied on payload logging must now set logPhi=true explicitly. Because the upgrade guide for a change like this lives on the main branch only, operators upgrading within the 4.18.x or 4.22.x lines should treat this advisory as the notice of that change.\u003c/p\u003e"
}
],
"value": "Upgrade to Apache Camel 4.23.0, which fixes the issue. Users on the 4.18.x LTS releases stream should upgrade to 4.18.5. Users on the 4.22.x LTS releases stream should upgrade to 4.22.1. logPhi now defaults to false and is honoured on the paths that previously ignored it. This is a changed default: a deployment that relied on payload logging must now set logPhi=true explicitly. Because the upgrade guide for a change like this lives on the main branch only, operators upgrading within the 4.18.x or 4.22.x lines should treat this advisory as the notice of that change."
}
],
"source": {
"discovery": "UNKNOWN"
},
"title": "Apache Camel: Camel-MLLP Protected Health Information Disclosure to Logs by Default",
"workarounds": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eFor deployments that cannot upgrade immediately, set logPhi=false and be aware that two paths will continue to log payload content until the fix is applied; restrict access to the logs accordingly.\u003c/p\u003e"
}
],
"value": "For deployments that cannot upgrade immediately, set logPhi=false and be aware that two paths will continue to log payload content until the fix is applied; restrict access to the logs accordingly."
}
],
"x_generator": {
"engine": "Vulnogram 1.0.3"
}
}
},
"cveMetadata": {
"assignerOrgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
"assignerShortName": "apache",
"cveId": "CVE-2026-85260",
"datePublished": "2026-10-19T10:37:42.980Z",
"dateReserved": "2026-09-03T16:35:42.561Z",
"dateUpdated": "2026-10-19T16:47:15.565Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2026-85257 (GCVE-0-2026-85257)
Vulnerability from cvelistv5
Published
2026-10-19 10:37
Modified
2026-10-19 16:47
Severity ?
VLAI Severity ?
EPSS score ?
CWE
- CWE-209 - Generation of Error Message Containing Sensitive Information
Summary
Generation of Error Message Containing Sensitive Information vulnerability in Apache Camel CXF component.
This issue affects Apache Camel: from 4.0.0 before 4.18.5, from 4.19.0 before 4.22.1.
When a route behind a CXF SOAP consumer failed with an exception the service contract does not declare, the exception was described back to the SOAP client in the fault: CXF copies the message into the SOAP faultstring, and can be configured to place the stack trace in the fault detail. An external caller able to provoke a failure could therefore read internal detail about the deployment - class and package names, and whatever the exception message carries. Declared faults, annotated @WebFault, are a different matter: those are part of the published contract that clients are written against, and suppressing them would break the service rather than protect anything.
Upgrade to Apache Camel 4.23.0, which fixes the issue. Users on the 4.18.x LTS releases stream should upgrade to 4.18.5. Users on the 4.22.x LTS releases stream should upgrade to 4.22.1. A muteException consumer option, defaulting to true, replaces an undeclared route failure with a generic fault carrying no class name, message or stack trace. Faults the contract declares are reported exactly as before. Set muteException=false to restore the previous output. For deployments that cannot upgrade immediately, declare the exceptions the service is allowed to report and map every other failure onto one of them in an onException handler, so no undeclared exception reaches the fault.
References
| URL | Tags | |
|---|---|---|
Impacted products
| Vendor | Product | Version | ||
|---|---|---|---|---|
| Apache Software Foundation | Apache Camel |
Version: 4.0.0 Version: 4.19.0 |
{
"containers": {
"adp": [
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2026-85257",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "yes"
},
{
"Technical Impact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-10-19T16:47:36.190817Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-10-19T16:47:59.389Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"collectionURL": "https://repo.maven.apache.org/maven2",
"defaultStatus": "unaffected",
"packageName": "org.apache.camel:camel-cxf",
"packageURL": "pkg:maven/org.apache.camel/camel-cxf",
"product": "Apache Camel",
"vendor": "Apache Software Foundation",
"versions": [
{
"lessThan": "4.18.5",
"status": "affected",
"version": "4.0.0",
"versionType": "maven"
},
{
"lessThan": "4.22.1",
"status": "affected",
"version": "4.19.0",
"versionType": "maven"
},
{
"status": "unaffected",
"version": "4.18.5",
"versionType": "maven"
},
{
"status": "unaffected",
"version": "4.22.1",
"versionType": "maven"
},
{
"status": "unaffected",
"version": "4.23.0",
"versionType": "maven"
}
]
}
],
"credits": [
{
"lang": "en",
"type": "finder",
"value": "Claude Security"
},
{
"lang": "en",
"type": "remediation developer",
"value": "Andrea Cosentino"
}
],
"descriptions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eGeneration of Error Message Containing Sensitive Information vulnerability in Apache Camel CXF component.\u003cbr\u003e\u003cbr\u003eThis issue affects Apache Camel: from 4.0.0 before 4.18.5, from 4.19.0 before 4.22.1.\u003cbr\u003e\u003cbr\u003eWhen a route behind a CXF SOAP consumer failed with an exception the service contract does not declare, the exception was described back to the SOAP client in the fault: CXF copies the message into the SOAP faultstring, and can be configured to place the stack trace in the fault detail. An external caller able to provoke a failure could therefore read internal detail about the deployment - class and package names, and whatever the exception message carries. Declared faults, annotated @WebFault, are a different matter: those are part of the published contract that clients are written against, and suppressing them would break the service rather than protect anything.\u003cbr\u003e\u003cbr\u003eUpgrade to Apache Camel 4.23.0, which fixes the issue. Users on the 4.18.x LTS releases stream should upgrade to 4.18.5. Users on the 4.22.x LTS releases stream should upgrade to 4.22.1. A muteException consumer option, defaulting to true, replaces an undeclared route failure with a generic fault carrying no class name, message or stack trace. Faults the contract declares are reported exactly as before. Set muteException=false to restore the previous output. For deployments that cannot upgrade immediately, declare the exceptions the service is allowed to report and map every other failure onto one of them in an onException handler, so no undeclared exception reaches the fault.\u003c/p\u003e"
}
],
"value": "Generation of Error Message Containing Sensitive Information vulnerability in Apache Camel CXF component.\n\nThis issue affects Apache Camel: from 4.0.0 before 4.18.5, from 4.19.0 before 4.22.1.\n\nWhen a route behind a CXF SOAP consumer failed with an exception the service contract does not declare, the exception was described back to the SOAP client in the fault: CXF copies the message into the SOAP faultstring, and can be configured to place the stack trace in the fault detail. An external caller able to provoke a failure could therefore read internal detail about the deployment - class and package names, and whatever the exception message carries. Declared faults, annotated @WebFault, are a different matter: those are part of the published contract that clients are written against, and suppressing them would break the service rather than protect anything.\n\nUpgrade to Apache Camel 4.23.0, which fixes the issue. Users on the 4.18.x LTS releases stream should upgrade to 4.18.5. Users on the 4.22.x LTS releases stream should upgrade to 4.22.1. A muteException consumer option, defaulting to true, replaces an undeclared route failure with a generic fault carrying no class name, message or stack trace. Faults the contract declares are reported exactly as before. Set muteException=false to restore the previous output. For deployments that cannot upgrade immediately, declare the exceptions the service is allowed to report and map every other failure onto one of them in an onException handler, so no undeclared exception reaches the fault."
}
],
"metrics": [
{
"cvssV3_1": {
"attackComplexity": "LOW",
"attackVector": "NETWORK",
"availabilityImpact": "NONE",
"baseScore": 5.3,
"baseSeverity": "MEDIUM",
"confidentialityImpact": "LOW",
"integrityImpact": "NONE",
"privilegesRequired": "NONE",
"scope": "UNCHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N",
"version": "3.1"
},
"format": "CVSS",
"scenarios": [
{
"lang": "en",
"value": "GENERAL"
}
]
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-209",
"description": "CWE-209 Generation of Error Message Containing Sensitive Information",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-10-19T10:37:14.792Z",
"orgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
"shortName": "apache"
},
"references": [
{
"name": "Apache Camel Security Advisory - CVE-2026-85257",
"tags": [
"vendor-advisory"
],
"url": "https://camel.apache.org/security/CVE-2026-85257.html"
},
{
"name": "CAMEL-24477",
"tags": [
"issue-tracking"
],
"url": "https://issues.apache.org/jira/browse/CAMEL-24477"
},
{
"name": "Fix on main, released in 4.23.0 (commit fd4fd273e4d1d36c1341cc8cf08405decd8c755c)",
"tags": [
"patch"
],
"url": "https://github.com/apache/camel/pull/25742"
},
{
"name": "Backport to camel-4.22.x, released in 4.22.1 (commit 9a6e8222085ed12f73ce76f826aeb69e9d111ff8)",
"tags": [
"patch"
],
"url": "https://github.com/apache/camel/pull/25934"
},
{
"name": "Backport to camel-4.18.x, released in 4.18.5 (commit e6986906e41b3e537d3a5d278525bc09b78b4127)",
"tags": [
"patch"
],
"url": "https://github.com/apache/camel/pull/25935"
}
],
"solutions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eUpgrade to Apache Camel 4.23.0, which fixes the issue. Users on the 4.18.x LTS releases stream should upgrade to 4.18.5. Users on the 4.22.x LTS releases stream should upgrade to 4.22.1. A muteException consumer option, defaulting to true, replaces an undeclared route failure with a generic fault carrying no class name, message or stack trace. Faults the contract declares are reported exactly as before. Set muteException=false to restore the previous output.\u003c/p\u003e"
}
],
"value": "Upgrade to Apache Camel 4.23.0, which fixes the issue. Users on the 4.18.x LTS releases stream should upgrade to 4.18.5. Users on the 4.22.x LTS releases stream should upgrade to 4.22.1. A muteException consumer option, defaulting to true, replaces an undeclared route failure with a generic fault carrying no class name, message or stack trace. Faults the contract declares are reported exactly as before. Set muteException=false to restore the previous output."
}
],
"source": {
"discovery": "UNKNOWN"
},
"title": "Apache Camel: Camel-CXF Information Disclosure via Unmuted Consumer Exceptions",
"workarounds": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eFor deployments that cannot upgrade immediately, declare the exceptions the service is allowed to report and map every other failure onto one of them in an onException handler, so no undeclared exception reaches the fault.\u003c/p\u003e"
}
],
"value": "For deployments that cannot upgrade immediately, declare the exceptions the service is allowed to report and map every other failure onto one of them in an onException handler, so no undeclared exception reaches the fault."
}
],
"x_generator": {
"engine": "Vulnogram 1.0.3"
}
}
},
"cveMetadata": {
"assignerOrgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
"assignerShortName": "apache",
"cveId": "CVE-2026-85257",
"datePublished": "2026-10-19T10:37:14.792Z",
"dateReserved": "2026-09-03T16:34:33.777Z",
"dateUpdated": "2026-10-19T16:47:59.389Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2026-85254 (GCVE-0-2026-85254)
Vulnerability from cvelistv5
Published
2026-10-19 10:36
Modified
2026-10-19 16:48
Severity ?
VLAI Severity ?
EPSS score ?
CWE
- CWE-178 - Improper Handling of Case Sensitivity
Summary
Improper Handling of Case Sensitivity vulnerability in Apache Camel Platform HTTP component.
This issue affects Apache Camel: from 4.0.0 before 4.18.5, from 4.19.0 before 4.22.1.
The guard that prevents a request header being reflected into the response compared header names case sensitively, while HTTP header names are case insensitive. A caller could therefore defeat the suppression simply by varying the case of the header name. HTTP/2 makes the problem unconditional rather than optional: the protocol requires header names to be lowercase on the wire, so the comparison never matched and the suppression was inert for every request on an HTTP/2 connection. The consequence is that content the caller chose is echoed back in the response, which is the basis for response-splitting and cache-poisoning style attacks against whatever sits in front of the Camel endpoint.
Upgrade to Apache Camel 4.23.0, which fixes the issue. Users on the 4.18.x LTS releases stream should upgrade to 4.18.5. Users on the 4.22.x LTS releases stream should upgrade to 4.22.1. Request header names are now compared case insensitively, so the suppression holds regardless of casing and works under HTTP/2. For deployments that cannot upgrade immediately, strip the headers in question in front of the Camel endpoint, or remove them from the response in the route rather than relying on the built-in suppression.
References
| URL | Tags | |
|---|---|---|
Impacted products
| Vendor | Product | Version | ||
|---|---|---|---|---|
| Apache Software Foundation | Apache Camel |
Version: 4.0.0 Version: 4.19.0 |
{
"containers": {
"adp": [
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2026-85254",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "yes"
},
{
"Technical Impact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-10-19T16:48:28.484546Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-10-19T16:48:42.551Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"collectionURL": "https://repo.maven.apache.org/maven2",
"defaultStatus": "unaffected",
"packageName": "org.apache.camel:camel-platform-http",
"packageURL": "pkg:maven/org.apache.camel/camel-platform-http",
"product": "Apache Camel",
"vendor": "Apache Software Foundation",
"versions": [
{
"lessThan": "4.18.5",
"status": "affected",
"version": "4.0.0",
"versionType": "maven"
},
{
"lessThan": "4.22.1",
"status": "affected",
"version": "4.19.0",
"versionType": "maven"
},
{
"status": "unaffected",
"version": "4.18.5",
"versionType": "maven"
},
{
"status": "unaffected",
"version": "4.22.1",
"versionType": "maven"
},
{
"status": "unaffected",
"version": "4.23.0",
"versionType": "maven"
}
]
}
],
"credits": [
{
"lang": "en",
"type": "finder",
"value": "Claude Security"
},
{
"lang": "en",
"type": "remediation developer",
"value": "Andrea Cosentino"
}
],
"descriptions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eImproper Handling of Case Sensitivity vulnerability in Apache Camel Platform HTTP component.\u003cbr\u003e\u003cbr\u003eThis issue affects Apache Camel: from 4.0.0 before 4.18.5, from 4.19.0 before 4.22.1.\u003cbr\u003e\u003cbr\u003eThe guard that prevents a request header being reflected into the response compared header names case sensitively, while HTTP header names are case insensitive. A caller could therefore defeat the suppression simply by varying the case of the header name. HTTP/2 makes the problem unconditional rather than optional: the protocol requires header names to be lowercase on the wire, so the comparison never matched and the suppression was inert for every request on an HTTP/2 connection. The consequence is that content the caller chose is echoed back in the response, which is the basis for response-splitting and cache-poisoning style attacks against whatever sits in front of the Camel endpoint.\u003cbr\u003e\u003cbr\u003eUpgrade to Apache Camel 4.23.0, which fixes the issue. Users on the 4.18.x LTS releases stream should upgrade to 4.18.5. Users on the 4.22.x LTS releases stream should upgrade to 4.22.1. Request header names are now compared case insensitively, so the suppression holds regardless of casing and works under HTTP/2. For deployments that cannot upgrade immediately, strip the headers in question in front of the Camel endpoint, or remove them from the response in the route rather than relying on the built-in suppression.\u003c/p\u003e"
}
],
"value": "Improper Handling of Case Sensitivity vulnerability in Apache Camel Platform HTTP component.\n\nThis issue affects Apache Camel: from 4.0.0 before 4.18.5, from 4.19.0 before 4.22.1.\n\nThe guard that prevents a request header being reflected into the response compared header names case sensitively, while HTTP header names are case insensitive. A caller could therefore defeat the suppression simply by varying the case of the header name. HTTP/2 makes the problem unconditional rather than optional: the protocol requires header names to be lowercase on the wire, so the comparison never matched and the suppression was inert for every request on an HTTP/2 connection. The consequence is that content the caller chose is echoed back in the response, which is the basis for response-splitting and cache-poisoning style attacks against whatever sits in front of the Camel endpoint.\n\nUpgrade to Apache Camel 4.23.0, which fixes the issue. Users on the 4.18.x LTS releases stream should upgrade to 4.18.5. Users on the 4.22.x LTS releases stream should upgrade to 4.22.1. Request header names are now compared case insensitively, so the suppression holds regardless of casing and works under HTTP/2. For deployments that cannot upgrade immediately, strip the headers in question in front of the Camel endpoint, or remove them from the response in the route rather than relying on the built-in suppression."
}
],
"metrics": [
{
"cvssV3_1": {
"attackComplexity": "LOW",
"attackVector": "NETWORK",
"availabilityImpact": "NONE",
"baseScore": 6.5,
"baseSeverity": "MEDIUM",
"confidentialityImpact": "LOW",
"integrityImpact": "LOW",
"privilegesRequired": "NONE",
"scope": "UNCHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N",
"version": "3.1"
},
"format": "CVSS",
"scenarios": [
{
"lang": "en",
"value": "GENERAL"
}
]
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-178",
"description": "CWE-178 Improper Handling of Case Sensitivity",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-10-19T10:36:46.283Z",
"orgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
"shortName": "apache"
},
"references": [
{
"name": "Apache Camel Security Advisory - CVE-2026-85254",
"tags": [
"vendor-advisory"
],
"url": "https://camel.apache.org/security/CVE-2026-85254.html"
},
{
"name": "CAMEL-24453",
"tags": [
"issue-tracking"
],
"url": "https://issues.apache.org/jira/browse/CAMEL-24453"
},
{
"name": "Fix on main, released in 4.23.0 (commit 126c79bdf3f171184461f987c143b5a818df4d81)",
"tags": [
"patch"
],
"url": "https://github.com/apache/camel/pull/25831"
},
{
"name": "Backport to camel-4.22.x, released in 4.22.1 (commit 260989268cbc6d258b1fcba63770be8ebbec40cb)",
"tags": [
"patch"
],
"url": "https://github.com/apache/camel/pull/25940"
},
{
"name": "Backport to camel-4.18.x, released in 4.18.5 (commit af1efbcccf5882b1ef0094db718972da3190e7e9)",
"tags": [
"patch"
],
"url": "https://github.com/apache/camel/pull/25942"
}
],
"solutions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eUpgrade to Apache Camel 4.23.0, which fixes the issue. Users on the 4.18.x LTS releases stream should upgrade to 4.18.5. Users on the 4.22.x LTS releases stream should upgrade to 4.22.1. Request header names are now compared case insensitively, so the suppression holds regardless of casing and works under HTTP/2.\u003c/p\u003e"
}
],
"value": "Upgrade to Apache Camel 4.23.0, which fixes the issue. Users on the 4.18.x LTS releases stream should upgrade to 4.18.5. Users on the 4.22.x LTS releases stream should upgrade to 4.22.1. Request header names are now compared case insensitively, so the suppression holds regardless of casing and works under HTTP/2."
}
],
"source": {
"discovery": "UNKNOWN"
},
"title": "Apache Camel: Camel-Platform-HTTP Request-Header Echo Suppression Bypassed by Header-Name Casing",
"workarounds": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eFor deployments that cannot upgrade immediately, strip the headers in question in front of the Camel endpoint, or remove them from the response in the route rather than relying on the built-in suppression.\u003c/p\u003e"
}
],
"value": "For deployments that cannot upgrade immediately, strip the headers in question in front of the Camel endpoint, or remove them from the response in the route rather than relying on the built-in suppression."
}
],
"x_generator": {
"engine": "Vulnogram 1.0.3"
}
}
},
"cveMetadata": {
"assignerOrgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
"assignerShortName": "apache",
"cveId": "CVE-2026-85254",
"datePublished": "2026-10-19T10:36:46.283Z",
"dateReserved": "2026-09-03T16:33:22.096Z",
"dateUpdated": "2026-10-19T16:48:42.551Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2026-85251 (GCVE-0-2026-85251)
Vulnerability from cvelistv5
Published
2026-10-19 10:36
Modified
2026-10-19 16:49
Severity ?
VLAI Severity ?
EPSS score ?
CWE
- CWE-200 - Exposure of Sensitive Information to an Unauthorized Actor
Summary
Exposure of Sensitive Information to an Unauthorized Actor vulnerability in Apache Camel HTTP component.
This issue affects Apache Camel: from 4.0.0 before 4.18.5, from 4.19.0 before 4.22.1.
Two paths handed credentials to a redirect target, which is a host chosen by the remote server rather than by the route, once followRedirects=true. OAuth2ClientConfigurer registers its interceptor with addRequestInterceptorFirst, and HttpClient runs protocol-level request interceptors inside ProtocolExec, which sits below RedirectExec in the exec chain; the interceptor therefore ran again for every redirect hop and re-attached Authorization: Bearer to whatever host the Location header named. Separately, credentials were registered against an AuthScope matching any host, so basic and digest credentials were presented to a redirect target as well. A remote endpoint - or anyone who can influence its responses - could therefore collect the bearer token or the configured credentials simply by answering with a redirect to a host it controls.
Upgrade to Apache Camel 4.23.0, which fixes the issue. Users on the 4.18.x LTS releases stream should upgrade to 4.18.5. Users on the 4.22.x LTS releases stream should upgrade to 4.22.1. Credentials are now sent only to the authority the endpoint was configured with, and are not re-attached when a redirect crosses to another host. For deployments that cannot upgrade immediately, set followRedirects=false on endpoints that carry credentials, and handle any redirect explicitly in the route so that the destination is chosen by the route rather than by the remote server.
References
| URL | Tags | |
|---|---|---|
Impacted products
| Vendor | Product | Version | ||
|---|---|---|---|---|
| Apache Software Foundation | Apache Camel |
Version: 4.0.0 Version: 4.19.0 |
{
"containers": {
"adp": [
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2026-85251",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "yes"
},
{
"Technical Impact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-10-19T16:49:16.842926Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-10-19T16:49:37.974Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"collectionURL": "https://repo.maven.apache.org/maven2",
"defaultStatus": "unaffected",
"packageName": "org.apache.camel:camel-http",
"packageURL": "pkg:maven/org.apache.camel/camel-http",
"product": "Apache Camel",
"vendor": "Apache Software Foundation",
"versions": [
{
"lessThan": "4.18.5",
"status": "affected",
"version": "4.0.0",
"versionType": "maven"
},
{
"lessThan": "4.22.1",
"status": "affected",
"version": "4.19.0",
"versionType": "maven"
},
{
"status": "unaffected",
"version": "4.18.5",
"versionType": "maven"
},
{
"status": "unaffected",
"version": "4.22.1",
"versionType": "maven"
},
{
"status": "unaffected",
"version": "4.23.0",
"versionType": "maven"
}
]
}
],
"credits": [
{
"lang": "en",
"type": "finder",
"value": "Claude Security"
},
{
"lang": "en",
"type": "remediation developer",
"value": "Andrea Cosentino"
}
],
"descriptions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eExposure of Sensitive Information to an Unauthorized Actor vulnerability in Apache Camel HTTP component.\u003cbr\u003e\u003cbr\u003eThis issue affects Apache Camel: from 4.0.0 before 4.18.5, from 4.19.0 before 4.22.1.\u003cbr\u003e\u003cbr\u003eTwo paths handed credentials to a redirect target, which is a host chosen by the remote server rather than by the route, once followRedirects=true. OAuth2ClientConfigurer registers its interceptor with addRequestInterceptorFirst, and HttpClient runs protocol-level request interceptors inside ProtocolExec, which sits below RedirectExec in the exec chain; the interceptor therefore ran again for every redirect hop and re-attached Authorization: Bearer to whatever host the Location header named. Separately, credentials were registered against an AuthScope matching any host, so basic and digest credentials were presented to a redirect target as well. A remote endpoint - or anyone who can influence its responses - could therefore collect the bearer token or the configured credentials simply by answering with a redirect to a host it controls.\u003cbr\u003e\u003cbr\u003eUpgrade to Apache Camel 4.23.0, which fixes the issue. Users on the 4.18.x LTS releases stream should upgrade to 4.18.5. Users on the 4.22.x LTS releases stream should upgrade to 4.22.1. Credentials are now sent only to the authority the endpoint was configured with, and are not re-attached when a redirect crosses to another host. For deployments that cannot upgrade immediately, set followRedirects=false on endpoints that carry credentials, and handle any redirect explicitly in the route so that the destination is chosen by the route rather than by the remote server.\u003c/p\u003e"
}
],
"value": "Exposure of Sensitive Information to an Unauthorized Actor vulnerability in Apache Camel HTTP component.\n\nThis issue affects Apache Camel: from 4.0.0 before 4.18.5, from 4.19.0 before 4.22.1.\n\nTwo paths handed credentials to a redirect target, which is a host chosen by the remote server rather than by the route, once followRedirects=true. OAuth2ClientConfigurer registers its interceptor with addRequestInterceptorFirst, and HttpClient runs protocol-level request interceptors inside ProtocolExec, which sits below RedirectExec in the exec chain; the interceptor therefore ran again for every redirect hop and re-attached Authorization: Bearer to whatever host the Location header named. Separately, credentials were registered against an AuthScope matching any host, so basic and digest credentials were presented to a redirect target as well. A remote endpoint - or anyone who can influence its responses - could therefore collect the bearer token or the configured credentials simply by answering with a redirect to a host it controls.\n\nUpgrade to Apache Camel 4.23.0, which fixes the issue. Users on the 4.18.x LTS releases stream should upgrade to 4.18.5. Users on the 4.22.x LTS releases stream should upgrade to 4.22.1. Credentials are now sent only to the authority the endpoint was configured with, and are not re-attached when a redirect crosses to another host. For deployments that cannot upgrade immediately, set followRedirects=false on endpoints that carry credentials, and handle any redirect explicitly in the route so that the destination is chosen by the route rather than by the remote server."
}
],
"metrics": [
{
"cvssV3_1": {
"attackComplexity": "LOW",
"attackVector": "NETWORK",
"availabilityImpact": "NONE",
"baseScore": 7.5,
"baseSeverity": "HIGH",
"confidentialityImpact": "HIGH",
"integrityImpact": "NONE",
"privilegesRequired": "NONE",
"scope": "UNCHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
"version": "3.1"
},
"format": "CVSS",
"scenarios": [
{
"lang": "en",
"value": "GENERAL"
}
]
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-200",
"description": "CWE-200 Exposure of Sensitive Information to an Unauthorized Actor",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-10-19T10:36:09.521Z",
"orgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
"shortName": "apache"
},
"references": [
{
"name": "Apache Camel Security Advisory - CVE-2026-85251",
"tags": [
"vendor-advisory"
],
"url": "https://camel.apache.org/security/CVE-2026-85251.html"
},
{
"name": "CAMEL-24452",
"tags": [
"issue-tracking"
],
"url": "https://issues.apache.org/jira/browse/CAMEL-24452"
},
{
"name": "Fix on main, released in 4.23.0 (commit 3a6c27bfae04e528f5a76494db6d6d97b9234551)",
"tags": [
"patch"
],
"url": "https://github.com/apache/camel/pull/25830"
},
{
"name": "Backport to camel-4.22.x, released in 4.22.1 (commit b0399b181d26cd8b136fa98b54ec8e5c283338da)",
"tags": [
"patch"
],
"url": "https://github.com/apache/camel/pull/25937"
},
{
"name": "Backport to camel-4.18.x, released in 4.18.5 (commit e23332aec12f7ec3a841e52d1821e2a580c2fbc7)",
"tags": [
"patch"
],
"url": "https://github.com/apache/camel/pull/25938"
}
],
"solutions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eUpgrade to Apache Camel 4.23.0, which fixes the issue. Users on the 4.18.x LTS releases stream should upgrade to 4.18.5. Users on the 4.22.x LTS releases stream should upgrade to 4.22.1. Credentials are now sent only to the authority the endpoint was configured with, and are not re-attached when a redirect crosses to another host.\u003c/p\u003e"
}
],
"value": "Upgrade to Apache Camel 4.23.0, which fixes the issue. Users on the 4.18.x LTS releases stream should upgrade to 4.18.5. Users on the 4.22.x LTS releases stream should upgrade to 4.22.1. Credentials are now sent only to the authority the endpoint was configured with, and are not re-attached when a redirect crosses to another host."
}
],
"source": {
"discovery": "UNKNOWN"
},
"title": "Apache Camel: Camel-HTTP Credential Disclosure to Cross-Host Redirect Targets",
"workarounds": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eFor deployments that cannot upgrade immediately, set followRedirects=false on endpoints that carry credentials, and handle any redirect explicitly in the route so that the destination is chosen by the route rather than by the remote server.\u003c/p\u003e"
}
],
"value": "For deployments that cannot upgrade immediately, set followRedirects=false on endpoints that carry credentials, and handle any redirect explicitly in the route so that the destination is chosen by the route rather than by the remote server."
}
],
"x_generator": {
"engine": "Vulnogram 1.0.3"
}
}
},
"cveMetadata": {
"assignerOrgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
"assignerShortName": "apache",
"cveId": "CVE-2026-85251",
"datePublished": "2026-10-19T10:36:09.521Z",
"dateReserved": "2026-09-03T16:31:52.210Z",
"dateUpdated": "2026-10-19T16:49:37.974Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2026-85250 (GCVE-0-2026-85250)
Vulnerability from cvelistv5
Published
2026-10-19 10:35
Modified
2026-10-19 16:50
Severity ?
VLAI Severity ?
EPSS score ?
CWE
- CWE-611 - Improper Restriction of XML External Entity Reference
Summary
Improper Restriction of XML External Entity Reference vulnerability in Apache Camel XPath component.
This issue affects Apache Camel: from 4.0.0 before 4.18.5, from 4.19.0 before 4.22.1.
With documentType set to InputSource, XPathBuilder handed the payload straight to javax.xml.xpath, which builds a DocumentBuilder of its own using the JDK defaults. The hardening applied to Camel's default document type was therefore bypassed: a DOCTYPE declaration that is refused on the default type was accepted here, and the external entity it declared was resolved and expanded into the evaluated document. An external sender whose XML reaches such an expression could read files readable by the Camel process and cause the process to issue requests to hosts it names. The two document types disagreeing on parser configuration is what made this reachable, since a deployment choosing InputSource for streaming reasons had no indication it was also choosing a weaker parser.
Upgrade to Apache Camel 4.23.0, which fixes the issue. Users on the 4.18.x LTS releases stream should upgrade to 4.18.5. Users on the 4.22.x LTS releases stream should upgrade to 4.22.1. The InputSource document type now goes through the same hardened parser as the default type, so a DOCTYPE is refused. Note that it also shares that type's documented escape hatch: the same DocumentBuilderFactory system properties that relax the default type relax this one, so a deployment that has set them remains unprotected by design. For deployments that cannot upgrade immediately, do not use documentType=InputSource on expressions evaluated over untrusted XML; the default document type already refuses a DOCTYPE.
References
| URL | Tags | |
|---|---|---|
Impacted products
| Vendor | Product | Version | ||
|---|---|---|---|---|
| Apache Software Foundation | Apache Camel |
Version: 4.0.0 Version: 4.19.0 |
{
"containers": {
"adp": [
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2026-85250",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "yes"
},
{
"Technical Impact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-10-19T16:50:01.891861Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-10-19T16:50:38.120Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"collectionURL": "https://repo.maven.apache.org/maven2",
"defaultStatus": "unaffected",
"packageName": "org.apache.camel:camel-xpath",
"packageURL": "pkg:maven/org.apache.camel/camel-xpath",
"product": "Apache Camel",
"vendor": "Apache Software Foundation",
"versions": [
{
"lessThan": "4.18.5",
"status": "affected",
"version": "4.0.0",
"versionType": "maven"
},
{
"lessThan": "4.22.1",
"status": "affected",
"version": "4.19.0",
"versionType": "maven"
},
{
"status": "unaffected",
"version": "4.18.5",
"versionType": "maven"
},
{
"status": "unaffected",
"version": "4.22.1",
"versionType": "maven"
},
{
"status": "unaffected",
"version": "4.23.0",
"versionType": "maven"
}
]
}
],
"credits": [
{
"lang": "en",
"type": "finder",
"value": "Claude Security"
},
{
"lang": "en",
"type": "remediation developer",
"value": "Andrea Cosentino"
}
],
"descriptions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eImproper Restriction of XML External Entity Reference vulnerability in Apache Camel XPath component.\u003cbr\u003e\u003cbr\u003eThis issue affects Apache Camel: from 4.0.0 before 4.18.5, from 4.19.0 before 4.22.1.\u003cbr\u003e\u003cbr\u003eWith documentType set to InputSource, XPathBuilder handed the payload straight to javax.xml.xpath, which builds a DocumentBuilder of its own using the JDK defaults. The hardening applied to Camel\u0027s default document type was therefore bypassed: a DOCTYPE declaration that is refused on the default type was accepted here, and the external entity it declared was resolved and expanded into the evaluated document. An external sender whose XML reaches such an expression could read files readable by the Camel process and cause the process to issue requests to hosts it names. The two document types disagreeing on parser configuration is what made this reachable, since a deployment choosing InputSource for streaming reasons had no indication it was also choosing a weaker parser.\u003cbr\u003e\u003cbr\u003eUpgrade to Apache Camel 4.23.0, which fixes the issue. Users on the 4.18.x LTS releases stream should upgrade to 4.18.5. Users on the 4.22.x LTS releases stream should upgrade to 4.22.1. The InputSource document type now goes through the same hardened parser as the default type, so a DOCTYPE is refused. Note that it also shares that type\u0027s documented escape hatch: the same DocumentBuilderFactory system properties that relax the default type relax this one, so a deployment that has set them remains unprotected by design. For deployments that cannot upgrade immediately, do not use documentType=InputSource on expressions evaluated over untrusted XML; the default document type already refuses a DOCTYPE.\u003c/p\u003e"
}
],
"value": "Improper Restriction of XML External Entity Reference vulnerability in Apache Camel XPath component.\n\nThis issue affects Apache Camel: from 4.0.0 before 4.18.5, from 4.19.0 before 4.22.1.\n\nWith documentType set to InputSource, XPathBuilder handed the payload straight to javax.xml.xpath, which builds a DocumentBuilder of its own using the JDK defaults. The hardening applied to Camel\u0027s default document type was therefore bypassed: a DOCTYPE declaration that is refused on the default type was accepted here, and the external entity it declared was resolved and expanded into the evaluated document. An external sender whose XML reaches such an expression could read files readable by the Camel process and cause the process to issue requests to hosts it names. The two document types disagreeing on parser configuration is what made this reachable, since a deployment choosing InputSource for streaming reasons had no indication it was also choosing a weaker parser.\n\nUpgrade to Apache Camel 4.23.0, which fixes the issue. Users on the 4.18.x LTS releases stream should upgrade to 4.18.5. Users on the 4.22.x LTS releases stream should upgrade to 4.22.1. The InputSource document type now goes through the same hardened parser as the default type, so a DOCTYPE is refused. Note that it also shares that type\u0027s documented escape hatch: the same DocumentBuilderFactory system properties that relax the default type relax this one, so a deployment that has set them remains unprotected by design. For deployments that cannot upgrade immediately, do not use documentType=InputSource on expressions evaluated over untrusted XML; the default document type already refuses a DOCTYPE."
}
],
"metrics": [
{
"cvssV3_1": {
"attackComplexity": "LOW",
"attackVector": "NETWORK",
"availabilityImpact": "NONE",
"baseScore": 7.5,
"baseSeverity": "HIGH",
"confidentialityImpact": "HIGH",
"integrityImpact": "NONE",
"privilegesRequired": "NONE",
"scope": "UNCHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
"version": "3.1"
},
"format": "CVSS",
"scenarios": [
{
"lang": "en",
"value": "GENERAL"
}
]
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-611",
"description": "CWE-611 Improper Restriction of XML External Entity Reference",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-10-19T10:35:21.670Z",
"orgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
"shortName": "apache"
},
"references": [
{
"name": "Apache Camel Security Advisory - CVE-2026-85250",
"tags": [
"vendor-advisory"
],
"url": "https://camel.apache.org/security/CVE-2026-85250.html"
},
{
"name": "CAMEL-24475",
"tags": [
"issue-tracking"
],
"url": "https://issues.apache.org/jira/browse/CAMEL-24475"
},
{
"name": "Fix on main, released in 4.23.0 (commit 1ead256f1bfcef36c2572a88809bcd7547bdc111)",
"tags": [
"patch"
],
"url": "https://github.com/apache/camel/pull/25683"
},
{
"name": "Backport to camel-4.22.x, released in 4.22.1 (commit 260989268cbc6d258b1fcba63770be8ebbec40cb)",
"tags": [
"patch"
],
"url": "https://github.com/apache/camel/pull/25940"
},
{
"name": "Backport to camel-4.18.x, released in 4.18.5 (commit af1efbcccf5882b1ef0094db718972da3190e7e9)",
"tags": [
"patch"
],
"url": "https://github.com/apache/camel/pull/25942"
}
],
"solutions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eUpgrade to Apache Camel 4.23.0, which fixes the issue. Users on the 4.18.x LTS releases stream should upgrade to 4.18.5. Users on the 4.22.x LTS releases stream should upgrade to 4.22.1. The InputSource document type now goes through the same hardened parser as the default type, so a DOCTYPE is refused. Note that it also shares that type\u0027s documented escape hatch: the same DocumentBuilderFactory system properties that relax the default type relax this one, so a deployment that has set them remains unprotected by design.\u003c/p\u003e"
}
],
"value": "Upgrade to Apache Camel 4.23.0, which fixes the issue. Users on the 4.18.x LTS releases stream should upgrade to 4.18.5. Users on the 4.22.x LTS releases stream should upgrade to 4.22.1. The InputSource document type now goes through the same hardened parser as the default type, so a DOCTYPE is refused. Note that it also shares that type\u0027s documented escape hatch: the same DocumentBuilderFactory system properties that relax the default type relax this one, so a deployment that has set them remains unprotected by design."
}
],
"source": {
"discovery": "UNKNOWN"
},
"title": "Apache Camel: Camel-XPath XML External Entity Processing and File Disclosure via the documentType=InputSource Option",
"workarounds": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eFor deployments that cannot upgrade immediately, do not use documentType=InputSource on expressions evaluated over untrusted XML; the default document type already refuses a DOCTYPE.\u003c/p\u003e"
}
],
"value": "For deployments that cannot upgrade immediately, do not use documentType=InputSource on expressions evaluated over untrusted XML; the default document type already refuses a DOCTYPE."
}
],
"x_generator": {
"engine": "Vulnogram 1.0.3"
}
}
},
"cveMetadata": {
"assignerOrgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
"assignerShortName": "apache",
"cveId": "CVE-2026-85250",
"datePublished": "2026-10-19T10:35:21.670Z",
"dateReserved": "2026-09-03T16:29:17.101Z",
"dateUpdated": "2026-10-19T16:50:38.120Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2026-85249 (GCVE-0-2026-85249)
Vulnerability from cvelistv5
Published
2026-10-19 10:34
Modified
2026-10-19 16:53
Severity ?
VLAI Severity ?
EPSS score ?
CWE
- CWE-20 - Improper Input Validation
Summary
Improper Input Validation vulnerability in Apache Camel Tika component.
This issue affects Apache Camel: from 4.0.0 before 4.18.5, from 4.19.0 before 4.22.1.
The Tika producer mapped every metadata key parsed out of the submitted document onto the Exchange as a header, with no filter applied. Document metadata is attacker-controlled content: the party that supplies the file chooses the metadata keys it carries. A crafted document could therefore set Exchange headers that the rest of the route depends on, including headers in the Camel namespace such as CamelFileName, which downstream components use to decide where content is written. The pattern is the same header-injection class as the consumer advisories published previously, reached here through parsed file content rather than through a protocol header.
Upgrade to Apache Camel 4.23.0, which fixes the issue. Users on the 4.18.x LTS releases stream should upgrade to 4.18.5. Users on the 4.22.x LTS releases stream should upgrade to 4.22.1. Parsed document metadata is now filtered through a HeaderFilterStrategy before it is mapped onto the Exchange. A route that was reading a metadata-derived header the filter now blocks will see it missing. For deployments that cannot upgrade immediately, strip the Camel namespace after the Tika producer with removeHeaders("Camel*") before any component that acts on those headers.
References
| URL | Tags | |
|---|---|---|
Impacted products
| Vendor | Product | Version | ||
|---|---|---|---|---|
| Apache Software Foundation | Apache Camel |
Version: 4.0.0 Version: 4.19.0 |
{
"containers": {
"adp": [
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2026-85249",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "yes"
},
{
"Technical Impact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-10-19T16:52:48.992017Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-10-19T16:53:06.515Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"collectionURL": "https://repo.maven.apache.org/maven2",
"defaultStatus": "unaffected",
"packageName": "org.apache.camel:camel-tika",
"packageURL": "pkg:maven/org.apache.camel/camel-tika",
"product": "Apache Camel",
"vendor": "Apache Software Foundation",
"versions": [
{
"lessThan": "4.18.5",
"status": "affected",
"version": "4.0.0",
"versionType": "maven"
},
{
"lessThan": "4.22.1",
"status": "affected",
"version": "4.19.0",
"versionType": "maven"
},
{
"status": "unaffected",
"version": "4.18.5",
"versionType": "maven"
},
{
"status": "unaffected",
"version": "4.22.1",
"versionType": "maven"
},
{
"status": "unaffected",
"version": "4.23.0",
"versionType": "maven"
}
]
}
],
"credits": [
{
"lang": "en",
"type": "finder",
"value": "Claude Security"
},
{
"lang": "en",
"type": "remediation developer",
"value": "Andrea Cosentino"
}
],
"descriptions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eImproper Input Validation vulnerability in Apache Camel Tika component.\u003cbr\u003e\u003cbr\u003eThis issue affects Apache Camel: from 4.0.0 before 4.18.5, from 4.19.0 before 4.22.1.\u003cbr\u003e\u003cbr\u003eThe Tika producer mapped every metadata key parsed out of the submitted document onto the Exchange as a header, with no filter applied. Document metadata is attacker-controlled content: the party that supplies the file chooses the metadata keys it carries. A crafted document could therefore set Exchange headers that the rest of the route depends on, including headers in the Camel namespace such as CamelFileName, which downstream components use to decide where content is written. The pattern is the same header-injection class as the consumer advisories published previously, reached here through parsed file content rather than through a protocol header.\u003cbr\u003e\u003cbr\u003eUpgrade to Apache Camel 4.23.0, which fixes the issue. Users on the 4.18.x LTS releases stream should upgrade to 4.18.5. Users on the 4.22.x LTS releases stream should upgrade to 4.22.1. Parsed document metadata is now filtered through a HeaderFilterStrategy before it is mapped onto the Exchange. A route that was reading a metadata-derived header the filter now blocks will see it missing. For deployments that cannot upgrade immediately, strip the Camel namespace after the Tika producer with removeHeaders(\"Camel*\") before any component that acts on those headers.\u003c/p\u003e"
}
],
"value": "Improper Input Validation vulnerability in Apache Camel Tika component.\n\nThis issue affects Apache Camel: from 4.0.0 before 4.18.5, from 4.19.0 before 4.22.1.\n\nThe Tika producer mapped every metadata key parsed out of the submitted document onto the Exchange as a header, with no filter applied. Document metadata is attacker-controlled content: the party that supplies the file chooses the metadata keys it carries. A crafted document could therefore set Exchange headers that the rest of the route depends on, including headers in the Camel namespace such as CamelFileName, which downstream components use to decide where content is written. The pattern is the same header-injection class as the consumer advisories published previously, reached here through parsed file content rather than through a protocol header.\n\nUpgrade to Apache Camel 4.23.0, which fixes the issue. Users on the 4.18.x LTS releases stream should upgrade to 4.18.5. Users on the 4.22.x LTS releases stream should upgrade to 4.22.1. Parsed document metadata is now filtered through a HeaderFilterStrategy before it is mapped onto the Exchange. A route that was reading a metadata-derived header the filter now blocks will see it missing. For deployments that cannot upgrade immediately, strip the Camel namespace after the Tika producer with removeHeaders(\"Camel*\") before any component that acts on those headers."
}
],
"metrics": [
{
"cvssV3_1": {
"attackComplexity": "LOW",
"attackVector": "NETWORK",
"availabilityImpact": "NONE",
"baseScore": 6.5,
"baseSeverity": "MEDIUM",
"confidentialityImpact": "LOW",
"integrityImpact": "LOW",
"privilegesRequired": "NONE",
"scope": "UNCHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N",
"version": "3.1"
},
"format": "CVSS",
"scenarios": [
{
"lang": "en",
"value": "GENERAL"
}
]
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-20",
"description": "CWE-20 Improper Input Validation",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-10-19T10:34:39.838Z",
"orgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
"shortName": "apache"
},
"references": [
{
"name": "Apache Camel Security Advisory - CVE-2026-85249",
"tags": [
"vendor-advisory"
],
"url": "https://camel.apache.org/security/CVE-2026-85249.html"
},
{
"name": "CAMEL-24423",
"tags": [
"issue-tracking"
],
"url": "https://issues.apache.org/jira/browse/CAMEL-24423"
},
{
"name": "Fix on main, released in 4.23.0 (commit b6f6b4708543677a8b6032304c66cbe7f687a2fb)",
"tags": [
"patch"
],
"url": "https://github.com/apache/camel/pull/25819"
},
{
"name": "Backport to camel-4.22.x, released in 4.22.1 (commit 260989268cbc6d258b1fcba63770be8ebbec40cb)",
"tags": [
"patch"
],
"url": "https://github.com/apache/camel/pull/25940"
},
{
"name": "Backport to camel-4.18.x, released in 4.18.5 (commit af1efbcccf5882b1ef0094db718972da3190e7e9)",
"tags": [
"patch"
],
"url": "https://github.com/apache/camel/pull/25942"
}
],
"solutions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eUpgrade to Apache Camel 4.23.0, which fixes the issue. Users on the 4.18.x LTS releases stream should upgrade to 4.18.5. Users on the 4.22.x LTS releases stream should upgrade to 4.22.1. Parsed document metadata is now filtered through a HeaderFilterStrategy before it is mapped onto the Exchange. A route that was reading a metadata-derived header the filter now blocks will see it missing.\u003c/p\u003e"
}
],
"value": "Upgrade to Apache Camel 4.23.0, which fixes the issue. Users on the 4.18.x LTS releases stream should upgrade to 4.18.5. Users on the 4.22.x LTS releases stream should upgrade to 4.22.1. Parsed document metadata is now filtered through a HeaderFilterStrategy before it is mapped onto the Exchange. A route that was reading a metadata-derived header the filter now blocks will see it missing."
}
],
"source": {
"discovery": "UNKNOWN"
},
"title": "Apache Camel: Camel-Tika Header Injection via Unfiltered Document Metadata",
"workarounds": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eFor deployments that cannot upgrade immediately, strip the Camel namespace after the Tika producer with removeHeaders(\u0026quot;Camel*\u0026quot;) before any component that acts on those headers.\u003c/p\u003e"
}
],
"value": "For deployments that cannot upgrade immediately, strip the Camel namespace after the Tika producer with removeHeaders(\"Camel*\") before any component that acts on those headers."
}
],
"x_generator": {
"engine": "Vulnogram 1.0.3"
}
}
},
"cveMetadata": {
"assignerOrgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
"assignerShortName": "apache",
"cveId": "CVE-2026-85249",
"datePublished": "2026-10-19T10:34:39.838Z",
"dateReserved": "2026-09-03T16:28:21.318Z",
"dateUpdated": "2026-10-19T16:53:06.515Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2026-85248 (GCVE-0-2026-85248)
Vulnerability from cvelistv5
Published
2026-10-19 10:34
Modified
2026-10-19 16:58
Severity ?
VLAI Severity ?
EPSS score ?
CWE
- CWE-362 - Concurrent Execution using Shared Resource with Improper Synchronization
Summary
Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition') vulnerability in Apache Camel PQC component.
This issue affects Apache Camel: from 4.12.0 before 4.18.5, from 4.19.0 before 4.22.1.
The producer held a single java.security.Signature instance and used it for every exchange without synchronizing access. Signature is stateful and is not thread safe: update() accumulates the data to be signed or verified, and verify() consumes that accumulated state. With concurrent exchanges sharing one instance the update and verify calls of different messages interleave, so a verification can complete against data that belongs to another exchange, or against a partially accumulated buffer. The outcome is non-deterministic and includes a verification reporting success for a message whose signature was never actually checked, which defeats the guarantee the component exists to provide. Reaching it requires concurrent traffic through the same endpoint, which is the ordinary condition for a Camel route under load.
Upgrade to Apache Camel 4.23.0, which fixes the issue. Users on the 4.18.x LTS releases stream should upgrade to 4.18.5. Users on the 4.22.x LTS releases stream should upgrade to 4.22.1. The Signature instance is no longer shared across concurrent exchanges. For deployments that cannot upgrade immediately, restrict the affected route to a single concurrent consumer so that no two exchanges use the instance at once.
References
| URL | Tags | |
|---|---|---|
Impacted products
| Vendor | Product | Version | ||
|---|---|---|---|---|
| Apache Software Foundation | Apache Camel |
Version: 4.12.0 Version: 4.19.0 |
{
"containers": {
"adp": [
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2026-85248",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "no"
},
{
"Technical Impact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-10-19T16:58:20.318907Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-10-19T16:58:32.142Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"collectionURL": "https://repo.maven.apache.org/maven2",
"defaultStatus": "unaffected",
"packageName": "org.apache.camel:camel-pqc",
"packageURL": "pkg:maven/org.apache.camel/camel-pqc",
"product": "Apache Camel",
"vendor": "Apache Software Foundation",
"versions": [
{
"lessThan": "4.18.5",
"status": "affected",
"version": "4.12.0",
"versionType": "maven"
},
{
"lessThan": "4.22.1",
"status": "affected",
"version": "4.19.0",
"versionType": "maven"
},
{
"status": "unaffected",
"version": "4.18.5",
"versionType": "maven"
},
{
"status": "unaffected",
"version": "4.22.1",
"versionType": "maven"
},
{
"status": "unaffected",
"version": "4.23.0",
"versionType": "maven"
}
]
}
],
"credits": [
{
"lang": "en",
"type": "finder",
"value": "Claude Security"
},
{
"lang": "en",
"type": "remediation developer",
"value": "Andrea Cosentino"
}
],
"descriptions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eConcurrent Execution using Shared Resource with Improper Synchronization (\u0027Race Condition\u0027) vulnerability in Apache Camel PQC component.\u003cbr\u003e\u003cbr\u003eThis issue affects Apache Camel: from 4.12.0 before 4.18.5, from 4.19.0 before 4.22.1.\u003c/p\u003e\u003cp\u003e\u003cbr\u003eThe producer held a single java.security.Signature instance and used it for every exchange without synchronizing access. Signature is stateful and is not thread safe: update() accumulates the data to be signed or verified, and verify() consumes that accumulated state. With concurrent exchanges sharing one instance the update and verify calls of different messages interleave, so a verification can complete against data that belongs to another exchange, or against a partially accumulated buffer. The outcome is non-deterministic and includes a verification reporting success for a message whose signature was never actually checked, which defeats the guarantee the component exists to provide. Reaching it requires concurrent traffic through the same endpoint, which is the ordinary condition for a Camel route under load.\u003cbr\u003e\u003cbr\u003eUpgrade to Apache Camel 4.23.0, which fixes the issue. Users on the 4.18.x LTS releases stream should upgrade to 4.18.5. Users on the 4.22.x LTS releases stream should upgrade to 4.22.1. The Signature instance is no longer shared across concurrent exchanges. For deployments that cannot upgrade immediately, restrict the affected route to a single concurrent consumer so that no two exchanges use the instance at once.\u003c/p\u003e"
}
],
"value": "Concurrent Execution using Shared Resource with Improper Synchronization (\u0027Race Condition\u0027) vulnerability in Apache Camel PQC component.\n\nThis issue affects Apache Camel: from 4.12.0 before 4.18.5, from 4.19.0 before 4.22.1.\n\n\n\n\nThe producer held a single java.security.Signature instance and used it for every exchange without synchronizing access. Signature is stateful and is not thread safe: update() accumulates the data to be signed or verified, and verify() consumes that accumulated state. With concurrent exchanges sharing one instance the update and verify calls of different messages interleave, so a verification can complete against data that belongs to another exchange, or against a partially accumulated buffer. The outcome is non-deterministic and includes a verification reporting success for a message whose signature was never actually checked, which defeats the guarantee the component exists to provide. Reaching it requires concurrent traffic through the same endpoint, which is the ordinary condition for a Camel route under load.\n\nUpgrade to Apache Camel 4.23.0, which fixes the issue. Users on the 4.18.x LTS releases stream should upgrade to 4.18.5. Users on the 4.22.x LTS releases stream should upgrade to 4.22.1. The Signature instance is no longer shared across concurrent exchanges. For deployments that cannot upgrade immediately, restrict the affected route to a single concurrent consumer so that no two exchanges use the instance at once."
}
],
"metrics": [
{
"cvssV3_1": {
"attackComplexity": "HIGH",
"attackVector": "NETWORK",
"availabilityImpact": "NONE",
"baseScore": 5.9,
"baseSeverity": "MEDIUM",
"confidentialityImpact": "NONE",
"integrityImpact": "HIGH",
"privilegesRequired": "NONE",
"scope": "UNCHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N",
"version": "3.1"
},
"format": "CVSS",
"scenarios": [
{
"lang": "en",
"value": "GENERAL"
}
]
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-362",
"description": "CWE-362 Concurrent Execution using Shared Resource with Improper Synchronization",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-10-19T10:34:16.177Z",
"orgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
"shortName": "apache"
},
"references": [
{
"name": "Apache Camel Security Advisory - CVE-2026-85248",
"tags": [
"vendor-advisory"
],
"url": "https://camel.apache.org/security/CVE-2026-85248.html"
},
{
"name": "CAMEL-24445",
"tags": [
"issue-tracking"
],
"url": "https://issues.apache.org/jira/browse/CAMEL-24445"
},
{
"name": "Fix on main, released in 4.23.0 (commit 91d5bdac51182fda8515e5b200e8aa842ccd1bc6)",
"tags": [
"patch"
],
"url": "https://github.com/apache/camel/pull/25825"
},
{
"name": "Backport to camel-4.22.x, released in 4.22.1 (commit 936a851a2b92c29712a77080fa0935b361179f83)",
"tags": [
"patch"
],
"url": "https://github.com/apache/camel/pull/25850"
},
{
"name": "Backport to camel-4.18.x, released in 4.18.5 (commit 1466b0fdf5a6e9a8fd859893f9b245218f30ea17)",
"tags": [
"patch"
],
"url": "https://github.com/apache/camel/pull/25851"
}
],
"solutions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eUpgrade to Apache Camel 4.23.0, which fixes the issue. Users on the 4.18.x LTS releases stream should upgrade to 4.18.5. Users on the 4.22.x LTS releases stream should upgrade to 4.22.1. The Signature instance is no longer shared across concurrent exchanges.\u003c/p\u003e"
}
],
"value": "Upgrade to Apache Camel 4.23.0, which fixes the issue. Users on the 4.18.x LTS releases stream should upgrade to 4.18.5. Users on the 4.22.x LTS releases stream should upgrade to 4.22.1. The Signature instance is no longer shared across concurrent exchanges."
}
],
"source": {
"discovery": "UNKNOWN"
},
"title": "Apache Camel: Camel-PQC Signature Verification Bypass via a Shared Unsynchronized Signature Instance",
"workarounds": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eFor deployments that cannot upgrade immediately, restrict the affected route to a single concurrent consumer so that no two exchanges use the instance at once.\u003c/p\u003e"
}
],
"value": "For deployments that cannot upgrade immediately, restrict the affected route to a single concurrent consumer so that no two exchanges use the instance at once."
}
],
"x_generator": {
"engine": "Vulnogram 1.0.3"
}
}
},
"cveMetadata": {
"assignerOrgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
"assignerShortName": "apache",
"cveId": "CVE-2026-85248",
"datePublished": "2026-10-19T10:34:16.177Z",
"dateReserved": "2026-09-03T16:26:19.164Z",
"dateUpdated": "2026-10-19T16:58:32.142Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2026-85247 (GCVE-0-2026-85247)
Vulnerability from cvelistv5
Published
2026-10-19 10:33
Modified
2026-10-19 17:00
Severity ?
VLAI Severity ?
EPSS score ?
CWE
- CWE-295 - Improper Certificate Validation
Summary
Improper Certificate Validation vulnerability in Apache Camel Knative component.
This issue affects Apache Camel: from 4.0.0 before 4.18.5, from 4.19.0 before 4.22.1.
When SSL was enabled on the Knative HTTP client but no truststore was configured, the client options fell back to trusting every presented certificate rather than to the JVM's default trust anchors. A deployment that switched TLS on without also configuring a truststore therefore obtained an encrypted connection with no peer authentication, which an attacker positioned on the network path can terminate and read. The dangerous state is reached by omission rather than by an explicit opt-in, which is what makes it a framework defect: turning TLS on should not be the thing that turns certificate validation off.
Upgrade to Apache Camel 4.23.0, which fixes the issue. Users on the 4.18.x LTS releases stream should upgrade to 4.18.5. Users on the 4.22.x LTS releases stream should upgrade to 4.22.1. With no truststore configured the trust options are now left unset so the JVM default trust anchors apply, the same fallback SSLContextParameters and the rest of Camel use. Trusting every certificate is now reached only by asking for it explicitly through the trust.all property, which remains available for development against a cluster with a self-signed certificate. For deployments that cannot upgrade immediately, configure a truststore explicitly wherever SSL is enabled. After upgrading, a deployment that was relying on the implicit trust-all behaviour must either configure a truststore or set the trust.all property deliberately.
References
| URL | Tags | |
|---|---|---|
Impacted products
| Vendor | Product | Version | ||
|---|---|---|---|---|
| Apache Software Foundation | Apache Camel |
Version: 4.0.0 Version: 4.19.0 |
{
"containers": {
"adp": [
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2026-85247",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "no"
},
{
"Technical Impact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-10-19T17:00:06.862739Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-10-19T17:00:20.717Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"collectionURL": "https://repo.maven.apache.org/maven2",
"defaultStatus": "unaffected",
"packageName": "org.apache.camel:camel-knative",
"packageURL": "pkg:maven/org.apache.camel/camel-knative",
"product": "Apache Camel",
"vendor": "Apache Software Foundation",
"versions": [
{
"lessThan": "4.18.5",
"status": "affected",
"version": "4.0.0",
"versionType": "maven"
},
{
"lessThan": "4.22.1",
"status": "affected",
"version": "4.19.0",
"versionType": "maven"
},
{
"status": "unaffected",
"version": "4.18.5",
"versionType": "maven"
},
{
"status": "unaffected",
"version": "4.22.1",
"versionType": "maven"
},
{
"status": "unaffected",
"version": "4.23.0",
"versionType": "maven"
}
]
}
],
"credits": [
{
"lang": "en",
"type": "finder",
"value": "Claude Security"
},
{
"lang": "en",
"type": "remediation developer",
"value": "Andrea Cosentino"
}
],
"descriptions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eImproper Certificate Validation vulnerability in Apache Camel Knative component.\u003cbr\u003e\u003cbr\u003eThis issue affects Apache Camel: from 4.0.0 before 4.18.5, from 4.19.0 before 4.22.1.\u003cbr\u003e\u003cbr\u003eWhen SSL was enabled on the Knative HTTP client but no truststore was configured, the client options fell back to trusting every presented certificate rather than to the JVM\u0027s default trust anchors. A deployment that switched TLS on without also configuring a truststore therefore obtained an encrypted connection with no peer authentication, which an attacker positioned on the network path can terminate and read. The dangerous state is reached by omission rather than by an explicit opt-in, which is what makes it a framework defect: turning TLS on should not be the thing that turns certificate validation off.\u003cbr\u003e\u003cbr\u003eUpgrade to Apache Camel 4.23.0, which fixes the issue. Users on the 4.18.x LTS releases stream should upgrade to 4.18.5. Users on the 4.22.x LTS releases stream should upgrade to 4.22.1. With no truststore configured the trust options are now left unset so the JVM default trust anchors apply, the same fallback SSLContextParameters and the rest of Camel use. Trusting every certificate is now reached only by asking for it explicitly through the trust.all property, which remains available for development against a cluster with a self-signed certificate. For deployments that cannot upgrade immediately, configure a truststore explicitly wherever SSL is enabled. After upgrading, a deployment that was relying on the implicit trust-all behaviour must either configure a truststore or set the trust.all property deliberately.\u003c/p\u003e"
}
],
"value": "Improper Certificate Validation vulnerability in Apache Camel Knative component.\n\nThis issue affects Apache Camel: from 4.0.0 before 4.18.5, from 4.19.0 before 4.22.1.\n\nWhen SSL was enabled on the Knative HTTP client but no truststore was configured, the client options fell back to trusting every presented certificate rather than to the JVM\u0027s default trust anchors. A deployment that switched TLS on without also configuring a truststore therefore obtained an encrypted connection with no peer authentication, which an attacker positioned on the network path can terminate and read. The dangerous state is reached by omission rather than by an explicit opt-in, which is what makes it a framework defect: turning TLS on should not be the thing that turns certificate validation off.\n\nUpgrade to Apache Camel 4.23.0, which fixes the issue. Users on the 4.18.x LTS releases stream should upgrade to 4.18.5. Users on the 4.22.x LTS releases stream should upgrade to 4.22.1. With no truststore configured the trust options are now left unset so the JVM default trust anchors apply, the same fallback SSLContextParameters and the rest of Camel use. Trusting every certificate is now reached only by asking for it explicitly through the trust.all property, which remains available for development against a cluster with a self-signed certificate. For deployments that cannot upgrade immediately, configure a truststore explicitly wherever SSL is enabled. After upgrading, a deployment that was relying on the implicit trust-all behaviour must either configure a truststore or set the trust.all property deliberately."
}
],
"metrics": [
{
"cvssV3_1": {
"attackComplexity": "HIGH",
"attackVector": "NETWORK",
"availabilityImpact": "NONE",
"baseScore": 5.9,
"baseSeverity": "MEDIUM",
"confidentialityImpact": "HIGH",
"integrityImpact": "NONE",
"privilegesRequired": "NONE",
"scope": "UNCHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N",
"version": "3.1"
},
"format": "CVSS",
"scenarios": [
{
"lang": "en",
"value": "GENERAL"
}
]
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-295",
"description": "CWE-295 Improper Certificate Validation",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-10-19T10:33:39.667Z",
"orgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
"shortName": "apache"
},
"references": [
{
"name": "Apache Camel Security Advisory - CVE-2026-85247",
"tags": [
"vendor-advisory"
],
"url": "https://camel.apache.org/security/CVE-2026-85247.html"
},
{
"name": "CAMEL-24443",
"tags": [
"issue-tracking"
],
"url": "https://issues.apache.org/jira/browse/CAMEL-24443"
},
{
"name": "Fix on main, released in 4.23.0 (commit 26c899d818b8f33732da3678ae00de6af351b622)",
"tags": [
"patch"
],
"url": "https://github.com/apache/camel/pull/25824"
},
{
"name": "Backport to camel-4.22.x, released in 4.22.1 (commit 95b4c1500001bc32877df5b8fca0bc7bdd080666)",
"tags": [
"patch"
],
"url": "https://github.com/apache/camel/pull/25944"
},
{
"name": "Backport to camel-4.18.x, released in 4.18.5 (commit 4ec9b37d70b08c478966000fb1bd653abfe410e3)",
"tags": [
"patch"
],
"url": "https://github.com/apache/camel/pull/25946"
}
],
"solutions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eUpgrade to Apache Camel 4.23.0, which fixes the issue. Users on the 4.18.x LTS releases stream should upgrade to 4.18.5. Users on the 4.22.x LTS releases stream should upgrade to 4.22.1. With no truststore configured the trust options are now left unset so the JVM default trust anchors apply, the same fallback SSLContextParameters and the rest of Camel use. Trusting every certificate is now reached only by asking for it explicitly through the trust.all property, which remains available for development against a cluster with a self-signed certificate.\u003c/p\u003e"
}
],
"value": "Upgrade to Apache Camel 4.23.0, which fixes the issue. Users on the 4.18.x LTS releases stream should upgrade to 4.18.5. Users on the 4.22.x LTS releases stream should upgrade to 4.22.1. With no truststore configured the trust options are now left unset so the JVM default trust anchors apply, the same fallback SSLContextParameters and the rest of Camel use. Trusting every certificate is now reached only by asking for it explicitly through the trust.all property, which remains available for development against a cluster with a self-signed certificate."
}
],
"source": {
"discovery": "UNKNOWN"
},
"title": "Apache Camel: Camel-Knative Improper Certificate Validation When SSL Is Enabled Without a Truststore",
"workarounds": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eFor deployments that cannot upgrade immediately, configure a truststore explicitly wherever SSL is enabled. After upgrading, a deployment that was relying on the implicit trust-all behaviour must either configure a truststore or set the trust.all property deliberately.\u003c/p\u003e"
}
],
"value": "For deployments that cannot upgrade immediately, configure a truststore explicitly wherever SSL is enabled. After upgrading, a deployment that was relying on the implicit trust-all behaviour must either configure a truststore or set the trust.all property deliberately."
}
],
"x_generator": {
"engine": "Vulnogram 1.0.3"
}
}
},
"cveMetadata": {
"assignerOrgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
"assignerShortName": "apache",
"cveId": "CVE-2026-85247",
"datePublished": "2026-10-19T10:33:39.667Z",
"dateReserved": "2026-09-03T16:24:48.857Z",
"dateUpdated": "2026-10-19T17:00:20.717Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2026-85246 (GCVE-0-2026-85246)
Vulnerability from cvelistv5
Published
2026-10-19 10:33
Modified
2026-10-19 18:31
Severity ?
VLAI Severity ?
EPSS score ?
CWE
- CWE-209 - Generation of Error Message Containing Sensitive Information
Summary
Generation of Error Message Containing Sensitive Information vulnerability in Apache Camel Mina component.
This issue affects Apache Camel: from 4.0.0 before 4.18.5, from 4.19.0 before 4.22.1.
When processing of an exchange failed, the Mina consumer wrote exchange.getException() straight back over the socket to the remote peer. Over a textline codec that hands the peer the exception's class name and message; over the object codec it hands over the serialised exception, cause chain included. A remote peer able to provoke a failure could therefore read internal detail about the deployment - class and package names, and whatever a message or nested cause happens to carry, which in practice can include paths, host names and connection detail. The consumer had no option to suppress this, unlike the HTTP-family consumers aligned by CAMEL-23651.
Upgrade to Apache Camel 4.23.0, which fixes the issue. Users on the 4.18.x LTS releases stream should upgrade to 4.18.5. Users on the 4.22.x LTS releases stream should upgrade to 4.22.1. A muteException consumer option, defaulting to true, replaces the route exception with a generic one carrying no class name, message or stack trace, while still writing a reply so that a synchronous peer is not left to time out. Set muteException=false to restore the previous behaviour. For deployments that cannot upgrade immediately, add an onException handler that sets the reply body explicitly, so the framework never writes the exception back to the peer.
References
| URL | Tags | |
|---|---|---|
Impacted products
| Vendor | Product | Version | ||
|---|---|---|---|---|
| Apache Software Foundation | Apache Camel |
Version: 4.0.0 Version: 4.19.0 |
{
"containers": {
"adp": [
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2026-85246",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "yes"
},
{
"Technical Impact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-10-19T18:31:11.636370Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-10-19T18:31:23.502Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"collectionURL": "https://repo.maven.apache.org/maven2",
"defaultStatus": "unaffected",
"packageName": "org.apache.camel:camel-mina",
"packageURL": "pkg:maven/org.apache.camel/camel-mina",
"product": "Apache Camel",
"vendor": "Apache Software Foundation",
"versions": [
{
"lessThan": "4.18.5",
"status": "affected",
"version": "4.0.0",
"versionType": "maven"
},
{
"lessThan": "4.22.1",
"status": "affected",
"version": "4.19.0",
"versionType": "maven"
},
{
"status": "unaffected",
"version": "4.18.5",
"versionType": "maven"
},
{
"status": "unaffected",
"version": "4.22.1",
"versionType": "maven"
},
{
"status": "unaffected",
"version": "4.23.0",
"versionType": "maven"
}
]
}
],
"credits": [
{
"lang": "en",
"type": "finder",
"value": "Claude Security"
},
{
"lang": "en",
"type": "remediation developer",
"value": "Andrea Cosentino"
}
],
"descriptions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eGeneration of Error Message Containing Sensitive Information vulnerability in Apache Camel Mina component.\u003cbr\u003e\u003cbr\u003eThis issue affects Apache Camel: from 4.0.0 before 4.18.5, from 4.19.0 before 4.22.1.\u003cbr\u003e\u003cbr\u003eWhen processing of an exchange failed, the Mina consumer wrote exchange.getException() straight back over the socket to the remote peer. Over a textline codec that hands the peer the exception\u0027s class name and message; over the object codec it hands over the serialised exception, cause chain included. A remote peer able to provoke a failure could therefore read internal detail about the deployment - class and package names, and whatever a message or nested cause happens to carry, which in practice can include paths, host names and connection detail. The consumer had no option to suppress this, unlike the HTTP-family consumers aligned by CAMEL-23651.\u003cbr\u003e\u003cbr\u003eUpgrade to Apache Camel 4.23.0, which fixes the issue. Users on the 4.18.x LTS releases stream should upgrade to 4.18.5. Users on the 4.22.x LTS releases stream should upgrade to 4.22.1. A muteException consumer option, defaulting to true, replaces the route exception with a generic one carrying no class name, message or stack trace, while still writing a reply so that a synchronous peer is not left to time out. Set muteException=false to restore the previous behaviour. For deployments that cannot upgrade immediately, add an onException handler that sets the reply body explicitly, so the framework never writes the exception back to the peer.\u003c/p\u003e"
}
],
"value": "Generation of Error Message Containing Sensitive Information vulnerability in Apache Camel Mina component.\n\nThis issue affects Apache Camel: from 4.0.0 before 4.18.5, from 4.19.0 before 4.22.1.\n\nWhen processing of an exchange failed, the Mina consumer wrote exchange.getException() straight back over the socket to the remote peer. Over a textline codec that hands the peer the exception\u0027s class name and message; over the object codec it hands over the serialised exception, cause chain included. A remote peer able to provoke a failure could therefore read internal detail about the deployment - class and package names, and whatever a message or nested cause happens to carry, which in practice can include paths, host names and connection detail. The consumer had no option to suppress this, unlike the HTTP-family consumers aligned by CAMEL-23651.\n\nUpgrade to Apache Camel 4.23.0, which fixes the issue. Users on the 4.18.x LTS releases stream should upgrade to 4.18.5. Users on the 4.22.x LTS releases stream should upgrade to 4.22.1. A muteException consumer option, defaulting to true, replaces the route exception with a generic one carrying no class name, message or stack trace, while still writing a reply so that a synchronous peer is not left to time out. Set muteException=false to restore the previous behaviour. For deployments that cannot upgrade immediately, add an onException handler that sets the reply body explicitly, so the framework never writes the exception back to the peer."
}
],
"metrics": [
{
"cvssV3_1": {
"attackComplexity": "LOW",
"attackVector": "NETWORK",
"availabilityImpact": "NONE",
"baseScore": 5.3,
"baseSeverity": "MEDIUM",
"confidentialityImpact": "LOW",
"integrityImpact": "NONE",
"privilegesRequired": "NONE",
"scope": "UNCHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N",
"version": "3.1"
},
"format": "CVSS",
"scenarios": [
{
"lang": "en",
"value": "GENERAL"
}
]
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-209",
"description": "CWE-209 Generation of Error Message Containing Sensitive Information",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-10-19T10:33:16.880Z",
"orgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
"shortName": "apache"
},
"references": [
{
"name": "Apache Camel Security Advisory - CVE-2026-85246",
"tags": [
"vendor-advisory"
],
"url": "https://camel.apache.org/security/CVE-2026-85246.html"
},
{
"name": "CAMEL-24476",
"tags": [
"issue-tracking"
],
"url": "https://issues.apache.org/jira/browse/CAMEL-24476"
},
{
"name": "Fix on main, released in 4.23.0 (commit 7af3e74d8448b5f1c6620bbae44d766e3f440704)",
"tags": [
"patch"
],
"url": "https://github.com/apache/camel/pull/25741"
},
{
"name": "Backport to camel-4.22.x, released in 4.22.1 (commit 9a6e8222085ed12f73ce76f826aeb69e9d111ff8)",
"tags": [
"patch"
],
"url": "https://github.com/apache/camel/pull/25934"
},
{
"name": "Backport to camel-4.18.x, released in 4.18.5 (commit e6986906e41b3e537d3a5d278525bc09b78b4127)",
"tags": [
"patch"
],
"url": "https://github.com/apache/camel/pull/25935"
}
],
"solutions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eUpgrade to Apache Camel 4.23.0, which fixes the issue. Users on the 4.18.x LTS releases stream should upgrade to 4.18.5. Users on the 4.22.x LTS releases stream should upgrade to 4.22.1. A muteException consumer option, defaulting to true, replaces the route exception with a generic one carrying no class name, message or stack trace, while still writing a reply so that a synchronous peer is not left to time out. Set muteException=false to restore the previous behaviour.\u003c/p\u003e"
}
],
"value": "Upgrade to Apache Camel 4.23.0, which fixes the issue. Users on the 4.18.x LTS releases stream should upgrade to 4.18.5. Users on the 4.22.x LTS releases stream should upgrade to 4.22.1. A muteException consumer option, defaulting to true, replaces the route exception with a generic one carrying no class name, message or stack trace, while still writing a reply so that a synchronous peer is not left to time out. Set muteException=false to restore the previous behaviour."
}
],
"source": {
"discovery": "UNKNOWN"
},
"title": "Apache Camel: Camel-Mina Information Disclosure via Unmuted Consumer Exceptions",
"workarounds": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eFor deployments that cannot upgrade immediately, add an onException handler that sets the reply body explicitly, so the framework never writes the exception back to the peer.\u003c/p\u003e"
}
],
"value": "For deployments that cannot upgrade immediately, add an onException handler that sets the reply body explicitly, so the framework never writes the exception back to the peer."
}
],
"x_generator": {
"engine": "Vulnogram 1.0.3"
}
}
},
"cveMetadata": {
"assignerOrgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
"assignerShortName": "apache",
"cveId": "CVE-2026-85246",
"datePublished": "2026-10-19T10:33:16.880Z",
"dateReserved": "2026-09-03T16:24:12.545Z",
"dateUpdated": "2026-10-19T18:31:23.502Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2026-85245 (GCVE-0-2026-85245)
Vulnerability from cvelistv5
Published
2026-10-19 10:32
Modified
2026-10-19 18:32
Severity ?
VLAI Severity ?
EPSS score ?
CWE
- CWE-488 - Exposure of Data Element to Wrong Session
Summary
Exposure of Data Element to Wrong Session vulnerability in Apache Camel Thrift component.
This issue affects Apache Camel: from 4.0.0 before 4.18.5, from 4.19.0 before 4.22.1.
The Thrift data format unmarshalled incoming data into the shared defaultInstance of the target type rather than into a fresh copy, and returned that shared object as the exchange body. Because the instance is shared process-wide, state written while unmarshalling one message stayed on the object and was visible to every later message that used the same type. Fields absent from a later payload retained the previous message's values, so content belonging to one sender could be read while processing another sender's message, and concurrent exchanges could observe each other's partially written state. In a deployment that serves more than one tenant or user through the same route, that is disclosure of one party's data to another.
Upgrade to Apache Camel 4.23.0, which fixes the issue. Users on the 4.18.x LTS releases stream should upgrade to 4.18.5. Users on the 4.22.x LTS releases stream should upgrade to 4.22.1. Unmarshalling now deserializes into a copy, so each exchange gets its own instance and no state carries between messages. For deployments that cannot upgrade immediately, copy the unmarshalled body into a new instance immediately after the data format runs, and do not retain references to the returned object.
References
| URL | Tags | |
|---|---|---|
Impacted products
| Vendor | Product | Version | ||
|---|---|---|---|---|
| Apache Software Foundation | Apache Camel |
Version: 4.0.0 Version: 4.19.0 |
{
"containers": {
"adp": [
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2026-85245",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "no"
},
{
"Technical Impact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-10-19T18:32:23.405683Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-10-19T18:32:37.783Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"collectionURL": "https://repo.maven.apache.org/maven2",
"defaultStatus": "unaffected",
"packageName": "org.apache.camel:camel-thrift",
"packageURL": "pkg:maven/org.apache.camel/camel-thrift",
"product": "Apache Camel",
"vendor": "Apache Software Foundation",
"versions": [
{
"lessThan": "4.18.5",
"status": "affected",
"version": "4.0.0",
"versionType": "maven"
},
{
"lessThan": "4.22.1",
"status": "affected",
"version": "4.19.0",
"versionType": "maven"
},
{
"status": "unaffected",
"version": "4.18.5",
"versionType": "maven"
},
{
"status": "unaffected",
"version": "4.22.1",
"versionType": "maven"
},
{
"status": "unaffected",
"version": "4.23.0",
"versionType": "maven"
}
]
}
],
"credits": [
{
"lang": "en",
"type": "finder",
"value": "Claude Security"
},
{
"lang": "en",
"type": "remediation developer",
"value": "Andrea Cosentino"
}
],
"descriptions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eExposure of Data Element to Wrong Session vulnerability in Apache Camel Thrift component.\u003c/p\u003e\u003cp\u003eThis issue affects Apache Camel: from 4.0.0 before 4.18.5, from 4.19.0 before 4.22.1.\u003cbr\u003e\u003cbr\u003eThe Thrift data format unmarshalled incoming data into the shared defaultInstance of the target type rather than into a fresh copy, and returned that shared object as the exchange body. Because the instance is shared process-wide, state written while unmarshalling one message stayed on the object and was visible to every later message that used the same type. Fields absent from a later payload retained the previous message\u0027s values, so content belonging to one sender could be read while processing another sender\u0027s message, and concurrent exchanges could observe each other\u0027s partially written state. In a deployment that serves more than one tenant or user through the same route, that is disclosure of one party\u0027s data to another.\u003cbr\u003e\u003cbr\u003eUpgrade to Apache Camel 4.23.0, which fixes the issue. Users on the 4.18.x LTS releases stream should upgrade to 4.18.5. Users on the 4.22.x LTS releases stream should upgrade to 4.22.1. Unmarshalling now deserializes into a copy, so each exchange gets its own instance and no state carries between messages. For deployments that cannot upgrade immediately, copy the unmarshalled body into a new instance immediately after the data format runs, and do not retain references to the returned object.\u003c/p\u003e"
}
],
"value": "Exposure of Data Element to Wrong Session vulnerability in Apache Camel Thrift component.\n\n\n\nThis issue affects Apache Camel: from 4.0.0 before 4.18.5, from 4.19.0 before 4.22.1.\n\nThe Thrift data format unmarshalled incoming data into the shared defaultInstance of the target type rather than into a fresh copy, and returned that shared object as the exchange body. Because the instance is shared process-wide, state written while unmarshalling one message stayed on the object and was visible to every later message that used the same type. Fields absent from a later payload retained the previous message\u0027s values, so content belonging to one sender could be read while processing another sender\u0027s message, and concurrent exchanges could observe each other\u0027s partially written state. In a deployment that serves more than one tenant or user through the same route, that is disclosure of one party\u0027s data to another.\n\nUpgrade to Apache Camel 4.23.0, which fixes the issue. Users on the 4.18.x LTS releases stream should upgrade to 4.18.5. Users on the 4.22.x LTS releases stream should upgrade to 4.22.1. Unmarshalling now deserializes into a copy, so each exchange gets its own instance and no state carries between messages. For deployments that cannot upgrade immediately, copy the unmarshalled body into a new instance immediately after the data format runs, and do not retain references to the returned object."
}
],
"metrics": [
{
"cvssV3_1": {
"attackComplexity": "HIGH",
"attackVector": "NETWORK",
"availabilityImpact": "NONE",
"baseScore": 5.9,
"baseSeverity": "MEDIUM",
"confidentialityImpact": "HIGH",
"integrityImpact": "NONE",
"privilegesRequired": "NONE",
"scope": "UNCHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N",
"version": "3.1"
},
"format": "CVSS",
"scenarios": [
{
"lang": "en",
"value": "GENERAL"
}
]
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-488",
"description": "CWE-488 Exposure of Data Element to Wrong Session",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-10-19T10:32:44.450Z",
"orgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
"shortName": "apache"
},
"references": [
{
"name": "Apache Camel Security Advisory - CVE-2026-85245",
"tags": [
"vendor-advisory"
],
"url": "https://camel.apache.org/security/CVE-2026-85245.html"
},
{
"name": "CAMEL-24442",
"tags": [
"issue-tracking"
],
"url": "https://issues.apache.org/jira/browse/CAMEL-24442"
},
{
"name": "Fix on main, released in 4.23.0 (commit c52d3cfa1c343a49261d77a5213dba92244a38f6)",
"tags": [
"patch"
],
"url": "https://github.com/apache/camel/pull/25823"
},
{
"name": "Backport to camel-4.22.x, released in 4.22.1 (commit 260989268cbc6d258b1fcba63770be8ebbec40cb)",
"tags": [
"patch"
],
"url": "https://github.com/apache/camel/pull/25940"
},
{
"name": "Backport to camel-4.18.x, released in 4.18.5 (commit af1efbcccf5882b1ef0094db718972da3190e7e9)",
"tags": [
"patch"
],
"url": "https://github.com/apache/camel/pull/25942"
}
],
"solutions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eUpgrade to Apache Camel 4.23.0, which fixes the issue. Users on the 4.18.x LTS releases stream should upgrade to 4.18.5. Users on the 4.22.x LTS releases stream should upgrade to 4.22.1. Unmarshalling now deserializes into a copy, so each exchange gets its own instance and no state carries between messages.\u003c/p\u003e"
}
],
"value": "Upgrade to Apache Camel 4.23.0, which fixes the issue. Users on the 4.18.x LTS releases stream should upgrade to 4.18.5. Users on the 4.22.x LTS releases stream should upgrade to 4.22.1. Unmarshalling now deserializes into a copy, so each exchange gets its own instance and no state carries between messages."
}
],
"source": {
"discovery": "UNKNOWN"
},
"title": "Apache Camel: Camel-Thrift Cross-Exchange Data Disclosure via a Shared Deserialization Target",
"workarounds": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eFor deployments that cannot upgrade immediately, copy the unmarshalled body into a new instance immediately after the data format runs, and do not retain references to the returned object.\u003c/p\u003e"
}
],
"value": "For deployments that cannot upgrade immediately, copy the unmarshalled body into a new instance immediately after the data format runs, and do not retain references to the returned object."
}
],
"x_generator": {
"engine": "Vulnogram 1.0.3"
}
}
},
"cveMetadata": {
"assignerOrgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
"assignerShortName": "apache",
"cveId": "CVE-2026-85245",
"datePublished": "2026-10-19T10:32:44.450Z",
"dateReserved": "2026-09-03T16:23:37.430Z",
"dateUpdated": "2026-10-19T18:32:37.783Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2026-85243 (GCVE-0-2026-85243)
Vulnerability from cvelistv5
Published
2026-10-19 10:32
Modified
2026-10-19 18:34
Severity ?
VLAI Severity ?
EPSS score ?
CWE
- CWE-354 - Improper Validation of Integrity Check Value
Summary
Improper Validation of Integrity Check Value vulnerability in Apache Camel Crypto PGP component.
This issue affects Apache Camel: from 4.0.0 before 4.18.5, from 4.19.0 before 4.22.1.
unmarshal() verified the modification detection code only when the message was an OpenPGP symmetrically encrypted integrity protected data packet. The older symmetrically encrypted data packet carries no such code, and OpenPGP's CFB mode is malleable without one, so a message using that packet skipped the check altogether. The packet type is chosen by whoever produced the message, which left the sender - or anyone able to rewrite the message in transit - deciding whether the integrity check applied at all. The existing integrity option governs marshalling only and had no decrypt-side counterpart, so a deployment could not require integrity protection on the messages it accepted.
Upgrade to Apache Camel 4.23.0, which fixes the issue. Users on the 4.18.x LTS releases stream should upgrade to 4.18.5. Users on the 4.22.x LTS releases stream should upgrade to 4.22.1. A requireIntegrityProtection option, defaulting to true, now rejects a message that is not integrity protected. Note that signatureVerificationOption still defaults to optional, so a message carrying no signature is accepted; the two options together are what give a decrypted message authenticity and not only confidentiality. For deployments that cannot upgrade immediately, reject messages that do not use the integrity protected packet before they reach the data format. Routes that must interoperate with a sender still emitting the legacy packet should set requireIntegrityProtection=false after upgrading, and treat the decrypted content as unauthenticated.
References
| URL | Tags | |
|---|---|---|
Impacted products
| Vendor | Product | Version | ||
|---|---|---|---|---|
| Apache Software Foundation | Apache Camel |
Version: 4.0.0 Version: 4.19.0 |
{
"containers": {
"adp": [
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2026-85243",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "no"
},
{
"Technical Impact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-10-19T18:34:06.410581Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-10-19T18:34:48.550Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"collectionURL": "https://repo.maven.apache.org/maven2",
"defaultStatus": "unaffected",
"packageName": "org.apache.camel:camel-crypto-pgp",
"packageURL": "pkg:maven/org.apache.camel/camel-crypto-pgp",
"product": "Apache Camel",
"vendor": "Apache Software Foundation",
"versions": [
{
"lessThan": "4.18.5",
"status": "affected",
"version": "4.0.0",
"versionType": "maven"
},
{
"lessThan": "4.22.1",
"status": "affected",
"version": "4.19.0",
"versionType": "maven"
},
{
"status": "unaffected",
"version": "4.18.5",
"versionType": "maven"
},
{
"status": "unaffected",
"version": "4.22.1",
"versionType": "maven"
},
{
"status": "unaffected",
"version": "4.23.0",
"versionType": "maven"
}
]
}
],
"credits": [
{
"lang": "en",
"type": "finder",
"value": "Claude Security"
},
{
"lang": "en",
"type": "remediation developer",
"value": "Andrea Cosentino"
}
],
"descriptions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eImproper Validation of Integrity Check Value vulnerability in Apache Camel Crypto PGP component.\u003cbr\u003e\u003cbr\u003eThis issue affects Apache Camel: from 4.0.0 before 4.18.5, from 4.19.0 before 4.22.1.\u003cbr\u003e\u003cbr\u003eunmarshal() verified the modification detection code only when the message was an OpenPGP symmetrically encrypted integrity protected data packet. The older symmetrically encrypted data packet carries no such code, and OpenPGP\u0027s CFB mode is malleable without one, so a message using that packet skipped the check altogether. The packet type is chosen by whoever produced the message, which left the sender - or anyone able to rewrite the message in transit - deciding whether the integrity check applied at all. The existing integrity option governs marshalling only and had no decrypt-side counterpart, so a deployment could not require integrity protection on the messages it accepted.\u003cbr\u003e\u003cbr\u003eUpgrade to Apache Camel 4.23.0, which fixes the issue. Users on the 4.18.x LTS releases stream should upgrade to 4.18.5. Users on the 4.22.x LTS releases stream should upgrade to 4.22.1. A requireIntegrityProtection option, defaulting to true, now rejects a message that is not integrity protected. Note that signatureVerificationOption still defaults to optional, so a message carrying no signature is accepted; the two options together are what give a decrypted message authenticity and not only confidentiality. For deployments that cannot upgrade immediately, reject messages that do not use the integrity protected packet before they reach the data format. Routes that must interoperate with a sender still emitting the legacy packet should set requireIntegrityProtection=false after upgrading, and treat the decrypted content as unauthenticated.\u003c/p\u003e"
}
],
"value": "Improper Validation of Integrity Check Value vulnerability in Apache Camel Crypto PGP component.\n\nThis issue affects Apache Camel: from 4.0.0 before 4.18.5, from 4.19.0 before 4.22.1.\n\nunmarshal() verified the modification detection code only when the message was an OpenPGP symmetrically encrypted integrity protected data packet. The older symmetrically encrypted data packet carries no such code, and OpenPGP\u0027s CFB mode is malleable without one, so a message using that packet skipped the check altogether. The packet type is chosen by whoever produced the message, which left the sender - or anyone able to rewrite the message in transit - deciding whether the integrity check applied at all. The existing integrity option governs marshalling only and had no decrypt-side counterpart, so a deployment could not require integrity protection on the messages it accepted.\n\nUpgrade to Apache Camel 4.23.0, which fixes the issue. Users on the 4.18.x LTS releases stream should upgrade to 4.18.5. Users on the 4.22.x LTS releases stream should upgrade to 4.22.1. A requireIntegrityProtection option, defaulting to true, now rejects a message that is not integrity protected. Note that signatureVerificationOption still defaults to optional, so a message carrying no signature is accepted; the two options together are what give a decrypted message authenticity and not only confidentiality. For deployments that cannot upgrade immediately, reject messages that do not use the integrity protected packet before they reach the data format. Routes that must interoperate with a sender still emitting the legacy packet should set requireIntegrityProtection=false after upgrading, and treat the decrypted content as unauthenticated."
}
],
"metrics": [
{
"cvssV3_1": {
"attackComplexity": "HIGH",
"attackVector": "NETWORK",
"availabilityImpact": "NONE",
"baseScore": 5.9,
"baseSeverity": "MEDIUM",
"confidentialityImpact": "NONE",
"integrityImpact": "HIGH",
"privilegesRequired": "NONE",
"scope": "UNCHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N",
"version": "3.1"
},
"format": "CVSS",
"scenarios": [
{
"lang": "en",
"value": "GENERAL"
}
]
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-354",
"description": "CWE-354 Improper Validation of Integrity Check Value",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-10-19T10:32:21.246Z",
"orgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
"shortName": "apache"
},
"references": [
{
"name": "Apache Camel Security Advisory - CVE-2026-85243",
"tags": [
"vendor-advisory"
],
"url": "https://camel.apache.org/security/CVE-2026-85243.html"
},
{
"name": "CAMEL-24441",
"tags": [
"issue-tracking"
],
"url": "https://issues.apache.org/jira/browse/CAMEL-24441"
},
{
"name": "Fix on main, released in 4.23.0 (commit 9d3108def6e8344f65a70ee86832b8f5237bc82d)",
"tags": [
"patch"
],
"url": "https://github.com/apache/camel/pull/25848"
},
{
"name": "Backport to camel-4.22.x, released in 4.22.1 (commit 95b4c1500001bc32877df5b8fca0bc7bdd080666)",
"tags": [
"patch"
],
"url": "https://github.com/apache/camel/pull/25944"
},
{
"name": "Backport to camel-4.18.x, released in 4.18.5 (commit 4ec9b37d70b08c478966000fb1bd653abfe410e3)",
"tags": [
"patch"
],
"url": "https://github.com/apache/camel/pull/25946"
}
],
"solutions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eUpgrade to Apache Camel 4.23.0, which fixes the issue. Users on the 4.18.x LTS releases stream should upgrade to 4.18.5. Users on the 4.22.x LTS releases stream should upgrade to 4.22.1. A requireIntegrityProtection option, defaulting to true, now rejects a message that is not integrity protected. Note that signatureVerificationOption still defaults to optional, so a message carrying no signature is accepted; the two options together are what give a decrypted message authenticity and not only confidentiality.\u003c/p\u003e"
}
],
"value": "Upgrade to Apache Camel 4.23.0, which fixes the issue. Users on the 4.18.x LTS releases stream should upgrade to 4.18.5. Users on the 4.22.x LTS releases stream should upgrade to 4.22.1. A requireIntegrityProtection option, defaulting to true, now rejects a message that is not integrity protected. Note that signatureVerificationOption still defaults to optional, so a message carrying no signature is accepted; the two options together are what give a decrypted message authenticity and not only confidentiality."
}
],
"source": {
"discovery": "UNKNOWN"
},
"title": "Apache Camel: Camel-Crypto-PGP Integrity Verification Downgrade via Attacker-Controlled Message Structure",
"workarounds": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eFor deployments that cannot upgrade immediately, reject messages that do not use the integrity protected packet before they reach the data format. Routes that must interoperate with a sender still emitting the legacy packet should set requireIntegrityProtection=false after upgrading, and treat the decrypted content as unauthenticated.\u003c/p\u003e"
}
],
"value": "For deployments that cannot upgrade immediately, reject messages that do not use the integrity protected packet before they reach the data format. Routes that must interoperate with a sender still emitting the legacy packet should set requireIntegrityProtection=false after upgrading, and treat the decrypted content as unauthenticated."
}
],
"x_generator": {
"engine": "Vulnogram 1.0.3"
}
}
},
"cveMetadata": {
"assignerOrgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
"assignerShortName": "apache",
"cveId": "CVE-2026-85243",
"datePublished": "2026-10-19T10:32:21.246Z",
"dateReserved": "2026-09-03T16:21:38.164Z",
"dateUpdated": "2026-10-19T18:34:48.550Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}