Apache Camel: Camel-CoAP Information Disclosure via Unmuted Consumer Exceptions
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. R
- Products
- Apache Camel
- Affected versions
- Not specified
- Fixed versions
- Not specified
- CVEs
- CVE-2026-101259
- Confirmed fixed CVEs
- Not specified
- Updated in this feed
- 29 Oct 2026, 21:33 UTC · Revision 1
Source evidence
Apache Camel: Camel-CoAP Information Disclosure via Unmuted Consumer Exceptions
core-cve · Original sourcePublished 26 Oct 2026, 08:36 UTC
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. R
cve:CVE-2026-101259
Apache Camel
Fixed versions: Not specified
Complete source record
{
"id": "1e850aa399851f080c9b2be229d53bb40524b7ce2ac1dff18cb220e1c86d82f9",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-101259",
"method": "structured",
"payload": {
"kind": "advisory",
"title": "Apache Camel: Camel-CoAP Information Disclosure via Unmuted Consumer Exceptions",
"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. R",
"evidence": "cve:CVE-2026-101259",
"products": [
{
"name": {
"value": "Apache Camel",
"evidence": "/containers/cna/affected/0/product"
},
"prerequisites": [],
"fixed_versions": [],
"affected_versions": []
}
],
"severity": "medium",
"structured": {
"id": "CVE-2026-101259",
"aliases": [
"CVE-2026-101259"
],
"metrics": [
{
"format": "CVSS",
"cvssV3_1": {
"scope": "UNCHANGED",
"version": "3.1",
"baseScore": 5.3,
"attackVector": "NETWORK",
"baseSeverity": "MEDIUM",
"vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N",
"integrityImpact": "NONE",
"userInteraction": "NONE",
"attackComplexity": "LOW",
"availabilityImpact": "NONE",
"privilegesRequired": "NONE",
"confidentialityImpact": "LOW"
},
"scenarios": [
{
"lang": "en",
"value": "GENERAL"
}
]
}
],
"affected": [
{
"vendor": "Apache Software Foundation",
"product": "Apache Camel",
"versions": [
{
"status": "affected",
"version": "4.0.0",
"lessThan": "4.18.5",
"versionType": "maven"
},
{
"status": "affected",
"version": "4.19.0",
"lessThan": "4.22.2",
"versionType": "maven"
}
],
"packageURL": "pkg:maven/org.apache.camel/camel-coap",
"packageName": "org.apache.camel:camel-coap",
"collectionURL": "https://repo.maven.apache.org/maven2",
"defaultStatus": "unaffected"
}
],
"modified": "2026-10-26T08:36:47.439Z",
"provider": "cve",
"references": [
"https://camel.apache.org/security/CVE-2026-101259.html",
"https://issues.apache.org/jira/browse/CAMEL-25087",
"https://github.com/apache/camel/pull/26994",
"https://github.com/apache/camel/pull/27046",
"https://github.com/apache/camel/pull/27048",
"https://camel.apache.org/security/CVE-2026-84180.html",
"https://camel.apache.org/security/CVE-2026-85246.html",
"https://camel.apache.org/security/CVE-2026-85257.html",
"https://camel.apache.org/security/CVE-2026-85315.html"
],
"provider_metadata": {
"cna": {
"orgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
"shortName": "apache",
"dateUpdated": "2026-10-26T08:36:47.439Z"
}
}
},
"related_cves": [
{
"value": "CVE-2026-101259",
"evidence": "/cveMetadata/cveId"
}
],
"security_relevant": true,
"severity_evidence": "/containers/cna/metrics"
},
"source_id": "core-cve",
"document_id": 273358,
"published_at": "2026-10-26T08:36:47.439+00:00"
}