CamelApplication · Apache
CVE-2026-56139
Official description Straight from the sourceThe vendor's or NVD's own wording, published unedited. Authoritative, but often terse — it says what broke, rarely what to do.
NVD · uneditedGeneration of Error Message Containing Sensitive Information vulnerability in Apache Camel Undertow Component. The camel-undertow HTTP server consumer exposes a muteException option that controls what is returned to the client when a route processing error occurs. This option defaulted to false, whereas the other Camel HTTP server components (camel-http / camel-jetty / camel-servlet and camel-platform-http) default it to true. With muteException=false, when a request triggers an exception during route processing the consumer writes the full Throwable stack trace into the HTTP response body as text/plain instead of returning an empty body. Any unauthenticated client that can reach the endpoint and cause a processing error - for example by sending a malformed request body, an invalid parameter, or otherwise triggering a route-internal failure - therefore receives a complete Java stack trace. Such a stack trace can disclose sensitive internal information, including credentials embedded in exception messages, internal host names and IP addresses, filesystem paths, dependency and version details, database and class names, and the application's internal structure, which an attacker can use to plan further attacks. In addition, for Rest DSL consumers the muteException option was not honoured at all: the RestUndertowHttpBinding was created with a hard-coded false, so the stack trace was returned even when muteException=true had been configured. This issue affects Apache Camel: from 4.0.0 before 4.14.8, from 4.15.0 before 4.18.3, from 4.19.0 before 4.21.0. Users are recommended to upgrade to version 4.21.0, which fixes the issue. If users are on the 4.14.x LTS releases stream, then they are suggested to upgrade to 4.14.8. If users are on the 4.18.x releases stream, then they are suggested to upgrade to 4.18.3. For deployments that cannot upgrade immediately, set muteException=true explicitly on the camel-undertow consumer (for example undertow: http://0.0.0.0:8080/api?muteException=true , or globally via the camel.component.undertow.mute-exception=true property), so that processing errors no longer return the stack trace to the client; note that on affected releases this workaround does not cover Rest DSL consumers, whose binding ignores the option until the fix is applied.
Technical summary Written by usOur analysis, written from the advisory, the CVSS vector and the affected-version data. It adds context the advisory leaves out, and never invents facts that are not in the source.
dbcve analysis · high confidenceThe camel-undertow HTTP consumer defaults muteException to false (unlike other Camel HTTP components), causing full Java stack traces to be written to HTTP response bodies on processing errors, exposing sensitive internal information including credentials, hostnames, IP addresses, and application structure. Additionally, for Rest DSL consumers, muteException was not honored at all due to a hard-coded false in RestUndertowHttpBinding.
Verify against the referenced sources before acting — the references below are authoritative for this CVE, this summary is not.
Affected products & versions What the vendor confirmedThe version ranges the vendor confirmed as vulnerable. If your version sits inside a range here, treat yourself as exposed until you have upgraded.
NVD · CPE data
CamelApplication
>= 4.0.0, < 4.14.8>= 4.15.0, < 4.18.3>= 4.19.0, < 4.21.0CVSS breakdown How the score is builtThe industry scoring standard. It rates how the flaw is reached, what it takes to exploit, and what an attacker gains — the score is derived from those, not the other way round.
From the vector- Attack vector
- Network
- Complexity
- Low
- Privileges
- None
- User interaction
- None
- Scope
- Unchanged
- Confidentiality
- Low
- Integrity
- None
- Availability
- None
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N
Am I affected? How to checkSteps we derive from the advisory and the affected-version data, so you can decide whether this CVE reaches your setup. They are a guide, not a scan — your own configuration is the authority.
dbcve checksWork through these to decide whether this CVE applies to you.
-
Identify the installed Apache Camel versionInspect your project's Maven/Gradle dependencies, or check the Camel version reported in application startup logs, or run 'jar -tf' on the camel-core jar to find the version manifestAffected if the installed version falls within any of the affected ranges: >=4.0.0 and <4.14.8, or >=4.15.0 and <4.18.3, or >=4.19.0 and <4.21.0
-
Confirm camel-undertow component is in useSearch your project dependencies for 'camel-undertow' in pom.xml, build.gradle, or your application's classpath. Check Camel route definitions for 'undertow:' consumer endpointsAffected if the camel-undertow dependency is present and used in your routes
-
Check muteException configuration on undertow consumersInspect your Camel route definitions for undertow consumers. Look for 'muteException' parameter in the endpoint URI (e.g., '?muteException=true') or in the component configuration property 'camel.component.undertow.mute-exception'Affected if muteException is not explicitly set to 'true' on the undertow consumer (the vulnerable default is 'false')
-
Check for Rest DSL consumers using undertowInspect your Camel route definitions for Rest DSL configurations using the undertow component. Look for rest() DSL blocks with 'to('undertow:...')' or undertow as the rest componentAffected if you use Rest DSL with the undertow component regardless of muteException setting (the binding hardcodes muteException=false)
You are affected if you run a vulnerable Camel version (4.0.0-4.14.7, 4.15.0-4.18.2, or 4.19.0-4.20.x) AND use the camel-undertow component without explicitly setting muteException=true on your consumers.
Generated from the published advisory. Verify against your own configuration.
Remediation Closing itWhat it takes to close this. Where a vendor fix exists we point at it; where none exists we say so plainly, and can build one. Effort estimates are scoped from the advisory, not from your codebase.
dbcve · scoped4.14.84.18.34.21.0
Set muteException=true explicitly on the camel-undertow consumer (e.g., ?muteException=true or camel.component.undertow.mute-exception=true property), or upgrade to 4.21.0/4.14.8/4.18.3 as appropriate. Note: the workaround does not cover Rest DSL consumers until the fix is applied.
4.21.0 (or 4.14.8 for 4.14.x LTS stream, or 4.18.3 for 4.18.x stream)
- Identify the current Apache Camel version in use by checking project dependencies or Camel runtime configuration
- Determine which release stream you are on: 4.14.x LTS, 4.18.x, or 4.19.x/4.20.x
- If on 4.14.x LTS stream: upgrade Apache Camel to version 4.14.8
- If on 4.18.x stream: upgrade Apache Camel to version 4.18.3
- If on 4.19.x or 4.20.x stream: upgrade Apache Camel to version 4.21.0
- After upgrading, verify that the muteException option defaults to true and that Rest DSL consumers properly honor the setting
- Test that error responses no longer expose stack traces to clients
- Alternatively, if immediate upgrade is not possible, configure muteException=true on the undertow consumer endpoint (e.g., undertow:http://0.0.0.0:8080/api?muteException=true) or set camel.component.undertow.mute-exception=true globally; note this workaround does not cover Rest DSL consumers until the fix is applied
Generated from the published advisory — verify against the referenced sources before acting.
Fix this in Camel
Scoped from the published advisory
- Consultation1.0 h
- Implementation1.0 h
- Testing2.0 h
- Review / QA1.0 h
An estimate, not a bill — we confirm scope with you before any work starts. Need it this week? Rush from $1,376.
Scan for this in your stack
Free · runs locallyCheck whether your project pulls in CVE-2026-56139 — or any other known-vulnerable package — straight from your lock files. Free and open source; it runs locally and uploads nothing.
References Go to the primary sourcePrimary sources — vendor advisories, patches and trackers. Where our summary and a reference disagree, the reference wins.
Primary sourcesPractitioner notes
ContributedPeer-ranked notes from engineers who’ve handled CVE-2026-56139 in production — separate from our analysis above.
The advisory tells you what broke. It rarely tells you what actually worked. If you’ve dealt with this one, that detail is what the next engineer is searching for.
- The version that genuinely resolved it — not the one the vendor claimed
- A config change or rule that shut the vector down
- A gotcha in the upgrade path that cost you an afternoon
No notes yet
Be the first to add a field note for this CVE — a mitigation you’ve verified, a version caveat, or a link to a working fix. Sign in above to contribute.
A place for practitioners to share what actually worked: a mitigation you’ve tested, a configuration change, a version- or environment-specific caveat, or a link to a verified patch. The most useful notes rise to the top as peers upvote them, so the signal stays high.
- Verified mitigations, workarounds, and config changes
- Version or environment caveats, and links to real fixes
- No weaponised exploit code, or anything meant to cause harm
- No spam, self-promotion, credentials, or personal data