Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessReach exposed gRPC consumer endpoint
-
ExploitSend input that provokes route failure
-
ImpactRead internal error detail leaked in status description
Vulnerability Assessment
| Weakness |
CWE
OWASP Top 10:2025
A10:2025 - Mishandling of Exceptional Conditions
ASVS 5.0
V16 - Security Logging and Error Handling Error message sanitization
MITRE ATT&CK
1 technique across 1 tactic: Discovery The technique list with ATT&CK links and the kill-chain view is part of the Basic plan and up. |
| Exploitation Conditions | Requires a deployment running an affected Apache Camel version (4.0.0 before 4.18.5, or 4.19.0 before 4.22.1) that exposes a gRPC consumer endpoint reachable by the attacker, AND a route behind that consumer that throws an exception the attacker can provoke. Disclosure only occurs when the exception message itself contains sensitive content (paths, host names, connection detail), so impact varies by what the route's exceptions carry. Key limiting factors: the fix introduces a muteException consumer option defaulting to true that substitutes a generic status description, so patched/default-configured deployments are not exposed; only pre-patch versions, or post-patch deployments that explicitly set muteException=false, leak the message. An onException handler mapping failures to an explicit status also prevents the leak. |
| Impact | This is a genuine but low-severity information-disclosure issue (CVSS 5.3, CWE-209) rather than a high-priority emergency. The CVSS vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N correctly reflects a network-reachable, unauthenticated, low-complexity flaw with only limited confidentiality impact and no integrity or availability effect - consistent with the description, which involves leaking an exception message, not code execution or data modification. No EPSS score was provided, the CVE is not in CISA KEV, and no POC was supplied, so exploitation status is 'no public exploit identified at time of analysis' and there is no evidence of widespread or targeted exploitation. Signals are therefore consistent (all point to low operational risk) with no contradiction between the CVSS network vector and the description, which also describes a remote caller provoking a failure. The practical impact is bounded: the disclosed data is whatever the exception carries (class/package names, file paths, host names, connection details) - useful for reconnaissance but not directly compromising. Reported by Apache with a patch available, this is a routine-patch item that should be scheduled, not a drop-everything priority. |
| Exploit ScenarioDerived | An external client sends a gRPC request that triggers a failure in the Camel route behind the gRPC consumer (for example by supplying input that causes a downstream exception). On vulnerable versions the route exception's message is copied into the gRPC status description and transmitted back to the caller, letting the attacker harvest internal details such as class/package names, file paths, host names, and connection strings for reconnaissance. No public exploit code is identified; the low attack complexity (AC:L) and lack of authentication (PR:N) make failures easy to provoke, but the payoff is limited to information leakage. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Oct 19, 2026
Error responses from the Apache Camel gRPC consumer component can leak internal exception details to remote callers: when a route behind a gRPC consumer fails, the exception's message is copied into the gRPC status description, which is transmitted back across the wire rather than kept server-side like the status cause. Unauthenticated remote callers who can provoke a route failure on an affected deployment (Camel 4.0.0 before 4.18.5, or 4.19.0 before 4.22.1) may read class and package names, filesystem paths, host names and connection detail embedded in those messages, at CVSS 5.3 with confidential-impact-only. The leak is conditional on the exception text itself carrying sensitive content and on the gRPC consumer being reachable, so real-world exposure varies by route; there is no public exploit identified at time of analysis and no confirmed active exploitation. Vendor patches are published (4.23.0, plus LTS 4.18.5 and 4.22.1), and the fixed builds default a new muteException option to true so patched deployments stop leaking unless they explicitly opt out.
RemediationAI
Vendor-released patch: upgrade to Apache Camel 4.23.0; users on the 4.18.x LTS stream should move to 4.18.5 and users on the 4.22.x LTS stream to 4.22.1, per https://camel.apache.org/security/CVE-2026-85315.html and https://issues.apache.org/jira/browse/CAMEL-24478. The fixed releases introduce a muteException consumer option on the gRPC component that defaults to true and substitutes a generic status description for the route exception's message - leave it at the default, since explicitly setting muteException=false reinstates the disclosure even on patched versions. For deployments that cannot upgrade immediately, add an onException handler on the gRPC consumer route that maps failures onto an explicit, non-revealing gRPC status so the framework never copies the exception message into the description; the trade-off is that legitimate non-sensitive diagnostic text is also suppressed for callers. As a complementary control, restrict network reachability of the gRPC consumer endpoint to trusted callers (mTLS, network policy or an authenticating proxy), which limits who can provoke a failing route but does not remove the leak for allowed clients. Note that the default-true muteException behaviour means upgraded deployments will see less descriptive error text in client responses, so update client-side troubleshooting expectations accordingly.
Affected VersionsENISA
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 1 package in euvd
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
Apache Camel's camel-grpc component implements both producer and consumer endpoints over gRPC/HTTP2, and the affected path is the consumer side, where Camel hosts a gRPC service and translates incoming RPCs into Camel exchanges that are then routed. This is CWE-209 (Generation of Error Message Containing Sensitive Information): the component's failure handling built a gRPC Status that carried the route exception's getMessage() as the status description. In gRPC semantics the status description is serialized into the trailer metadata returned to the client, while the status cause remains a local Java-side object, so the design intent of keeping the root cause server-side was undermined by placing the message in the transmitted field. The engineering fix in the referenced pull requests adds a muteException consumer parameter to the GrpcConfiguration (reflected in the generated camel-catalog grpc.json alongside existing consumer options such as routeControlledStreamObserver and bridgeErrorHandler), defaulting to true so a generic description is substituted; setting muteException=false restores the legacy behaviour and the legacy leak. The advisory is one of a family - the knative, mina and CXF advisories published alongside it - addressing the same 'unmuted consumer exception' pattern across multiple Camel consumers, so operators running several Camel consumer components should expect parallel fixes. Affected artifacts are the apache_camel distribution (CPE cpe:2.3:a:apache_software_foundation:apache_camel) at the gRPC consumer layer; the CVSS vector (AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N) denotes a remotely reachable, low-complexity, unauthenticated information-disclosure path with no integrity or availability effect, bounded to a low confidentiality impact because the disclosed content depends on what the application's own exceptions happen to contain.
Know when Apache Camel gets its next vulnerability
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N
Remote unauthenticated caller can easily provoke a route failure (AV:N/AC:L/PR:N/UI:N); only limited confidentiality loss from leaked exception text, no integrity or availability impact.
Primary rating from Vendor (apache).
CVSS VectorVendor: apache
DescriptionCVE.org
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.
Threat Intelligence Overview
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Attack Technique
Information disclosure occurs when an application unintentionally exposes sensitive data that aids attackers in reconnaissance or directly compromises security.
More in Apache Camel
View allRemote code execution in Apache Camel's camel-coap component (versions 4.14.0-4.14.5, 4.18.0 before 4.18.1, and 4.19.0)
Unsafe Java deserialization in Apache Camel's camel-infinispan component allows arbitrary code execution when the ProtoS
Unauthenticated remote code execution affects the camel-hazelcast component of Apache Camel 4.0.0 through 4.18.4 and 4.1
Header-injection in the Apache Camel camel-atmosphere-websocket producer lets an external sender hijack WebSocket messag
Header-filter bypass in the Apache Camel Undertow component (4.11.0-4.14.8, 4.15.0-4.18.3, and 4.19.0-4.21.x) lets remot
Remote code execution in Apache Camel 3.18.0-4.14.5 and 4.15.0-4.18.1 stems from CXF and Knative HeaderFilterStrategy im
Message header injection in Apache Camel's camel-mail component (3.0.0 before 4.14.6 and 4.15.0 before 4.18.1) lets an a
Remote code execution via unsafe Java deserialization affects the camel-pqc component of Apache Camel 4.18.0-4.18.2 and
Unsafe Java deserialization in Apache Camel's camel-consul component (ConsulRegistry / ConsulRegistryUtils.deserialize)
Unauthenticated deserialization of attacker-controlled messages in Apache Camel's camel-jgroups consumer can lead to rem
Expression language injection in the Apache Camel dynamic-router-control endpoint allows a party who can place a message
Deserialization of untrusted data in the Apache Camel Spring Redis component (camel-spring-redis) allows an authenticate
EUVD-2026-104203
GHSA-xj93-qh7c-f9w3
NVD
CVE.org
EPSS
Vulnrichment
VulDB
Exploit-DB