Apache Camel EUVD-2026-104183

Requires a Camel route that uses the camel-knative component as an HTTP consumer (Knative eventing/serving HTTP consumer) reachable by the attacker, AND an exchange that fails during processing on the consumer side. In vulnerable versions the exception was written back by default, so no special option was needed to trigger disclosure. Limiting factors: the deployment must actually expose the Knative HTTP consumer to untrusted callers, the attacker must be able to induce a processing failure, and the value of the leak depends on whether exception messages carry sensitive detail (host names, file paths, or connection strings). After upgrade the new muteException option defaults to true, returning an empty body with the error status; explicitly setting muteException=false re-exposes the behaviour.

This is a genuine but modest-severity information-disclosure issue, correctly rated CVSS 5.3 (MEDIUM). The vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N is internally consistent with the description: a remote, unauthenticated sender reachable over the network can provoke an exchange processing failure and receive the exception class, message, and stack trace in the HTTP response body. Only confidentiality is affected (C:L); there is no integrity or availability impact, so this is a reconnaissance/disclosure aid rather than a direct code-execution or takeover flaw. No EPSS score was provided in the input, and the issue is NOT in CISA KEV and has no public exploit code referenced - exploitation signals are therefore low. The practical risk is low-to-moderate: exploitation is trivial where the vulnerable Knative HTTP consumer is exposed, but the payoff is leaked internal detail (package/class names, host/file names, and potentially connection strings embedded in exception messages) that primarily enables follow-on targeting, not immediate compromise. No conflicting signals: the network vector matches the HTTP-consumer deployment model described. Priority should be driven by whether camel-knative is actually exposed to untrusted callers and whether sensitive data appears in exception messages in a given deployment.

An external sender sends a request to a Camel route whose Knative HTTP consumer is reachable, crafting input that causes processing of the exchange to fail. The framework writes the resulting Java exception - class name, message, and full stack trace - back as the HTTP response body, revealing internal package structure, host or file names, and any connection strings embedded in the exception message. No public exploit code is referenced; the attack requires only the ability to reach the endpoint and trigger a processing error.