CVE-2026-59230
CVE-2026-59230 is a medium-severity vulnerability in Apache Camel with a CVSS 3.x base score of 6.5. It is not currently listed as actively exploited by CISA, and its EPSS exploit-prediction score is low. The underlying weakness is classified as CWE-20.
Key facts
- Severity: Medium (CVSS 3.x base score 6.5)
- EPSS exploit prediction: 1% (51st percentile)
- Actively exploited: Not listed in CISA KEV
- Weakness: CWE-20
- Affected product: Apache Camel
- Published:
- Last modified:
Description
Improper input validation vulnerability in Apache Camel. This issue affects Apache Camel: from 2.17.0 before 4.14.9, from 4.15.0 before 4.18.4, from 4.19.0 before 4.22.0. The camel-mail component ships a MimeMultipart data format that can unmarshal a MIME multipart message. When it is configured with headersInline set to true, the unmarshal path copies the MIME headers of the incoming message onto the Camel message: it enumerates every header that is not one of the three standard ones it generates itself - Message-ID, MIME-Version and Content-Type - and calls setHeader for each, applying no HeaderFilterStrategy. The names of those MIME headers come from the message being unmarshalled, so a sender able to influence the message could place a header whose name falls in the Camel-internal namespace and have it set on the Exchange. Camel components read control headers from that namespace to override their configured behaviour - the camel-sql producer, for instance, takes the statement to execute from a Camel header when one is present - so an injected header could redirect what a downstream step in the route does with data the route author never intended it to take from the message. Which sinks are reachable, and what the consequences are, depends entirely on what the route does after the unmarshal step. The camel-mail consumer already applied a header filter strategy on its own inbound path, so this was the parallel inbound path into the same component that the earlier hardening did not cover. The affected copy is reached only when headersInline is enabled, which is not the default: with the default setting the MIME headers are surfaced as attachments rather than as message headers, and are not affected. The behaviour dates back to the introduction of the data format in 2.17.0 and was present on every release line until this fix. Users are recommended to upgrade to version 4.22.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.9. If users are on the 4.18.x releases stream, then they are suggested to upgrade to 4.18.4. For deployments that cannot upgrade immediately, leave headersInline at its default of false where the inline headers are not needed, since the copy is only reached when it is enabled. Where it must stay enabled, strip Camel-internal headers immediately after the unmarshal step, for example with removeHeaders(“Camel*”) placed before any processor or producer that reads control headers, and do not unmarshal MIME content from an untrusted sender into a route that dispatches on header values. As defence in depth, treat the header names of any MIME message arriving from outside the trust boundary as untrusted input.
Frequently asked questions
- What is CVE-2026-59230?
- Improper input validation vulnerability in Apache Camel. This issue affects Apache Camel: from 2.17.0 before 4.14.9, from 4.15.0 before 4.18.4, from 4.19.0 before 4.22.0. The camel-mail component ships a MimeMultipart data format that can unmarshal a MIME multipart message. When it is configured with headersInline set to true, the unmarshal path copies the MIME headers of the incoming message onto the Camel message: it enumerates every header that is not one of the three standard ones it generates itself - Message-ID, MIME-Version and Content-Type - and calls setHeader for each, applying no HeaderFilterStrategy. The names of those MIME headers come from the message being unmarshalled, so a sender able to influence the message could place a header whose name falls in the Camel-internal namespace and have it set on the Exchange. Camel components read control headers from that namespace to override their configured behaviour - the camel-sql producer, for instance, takes the statement to execute from a Camel header when one is present - so an injected header could redirect what a downstream step in the route does with data the route author never intended it to take from the message. Which sinks are reachable, and what the consequences are, depends entirely on what the route does after the unmarshal step. The camel-mail consumer already applied a header filter strategy on its own inbound path, so this was the parallel inbound path into the same component that the earlier hardening did not cover. The affected copy is reached only when headersInline is enabled, which is not the default: with the default setting the MIME headers are surfaced as attachments rather than as message headers, and are not affected. The behaviour dates back to the introduction of the data format in 2.17.0 and was present on every release line until this fix. Users are recommended to upgrade to version 4.22.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.9. If users are on the 4.18.x releases stream, then they are suggested to upgrade to 4.18.4. For deployments that cannot upgrade immediately, leave headersInline at its default of false where the inline headers are not needed, since the copy is only reached when it is enabled. Where it must stay enabled, strip Camel-internal headers immediately after the unmarshal step, for example with removeHeaders(“Camel*”) placed before any processor or producer that reads control headers, and do not unmarshal MIME content from an untrusted sender into a route that dispatches on header values. As defence in depth, treat the header names of any MIME message arriving from outside the trust boundary as untrusted input.
- How severe is CVE-2026-59230?
- CVE-2026-59230 has a CVSS 3.x base score of 6.5, rated medium severity. It is exploitable over network with low attack complexity, requires no privileges and no user interaction. Impact on confidentiality is low, integrity low, and availability none.
- Is CVE-2026-59230 being actively exploited?
- It is not currently listed in CISA's KEV catalog. Its EPSS exploit-prediction score is 1% (51st percentile), an estimate of the probability of exploitation in the next 30 days.
- What products are affected by CVE-2026-59230?
- CVE-2026-59230 affects Apache Camel. See the affected-products list for the exact vulnerable versions.
- How do I fix CVE-2026-59230?
- Review the linked vendor and NVD advisories for patched versions and mitigations, then upgrade or apply the recommended workaround.
- When was CVE-2026-59230 published?
- CVE-2026-59230 was published on 2026-08-24 and last updated on 2026-08-27.
References
- https://camel.apache.org/security/CVE-2026-59230.html
- http://www.openwall.com/lists/oss-security/2026/08/24/7
Affected products (1)
- cpe:2.3:a:apache:camel:*:*:*:*:*:*:*:*
More vulnerabilities in Apache Camel
- CVE-2026-33453 — Critical (CVSS 10.0): Improperly Controlled Modification of Dynamically-Determined Object Attributes vulnerability in Apache Camel Camel-Coap…
- CVE-2026-40453 — Critical (CVSS 9.9): The fix for CVE-2025-27636 added setLowerCase(true) to HttpHeaderFilterStrategy so that case-variant header names such…
- CVE-2026-80352 — Critical (CVSS 9.8): Improper Control of Generation of Code ('Code Injection') vulnerability in Apache Camel K. A YAML injection…
- CVE-2026-80351 — Critical (CVSS 9.8): Improper neutralization of directives in dynamically evaluated code ('eval injection') vulnerability in Apache Camel…
- CVE-2026-78329 — Critical (CVSS 9.8): Improper input validation vulnerability in Apache Camel Undertow component. This issue affects Apache Camel: from…
- CVE-2026-71300 — Critical (CVSS 9.8): Improper input validation vulnerability in Apache Camel Atmosphere Websocket component. This issue affects Apache…
All CVEs affecting Apache Camel →
Other CWE-20 (Improper Input Validation) vulnerabilities
- CVE-2026-93952 — Critical (CVSS 10.0): VeloCloud Orchestrator (VCO) on-prem has a security issue where this issue may allow a remote attacker to access…
- CVE-2026-77554 — Critical (CVSS 10.0): A malicious actor with access to the network could exploit an Improper Input Validation vulnerability found in UniFi…
- CVE-2026-77537 — Critical (CVSS 10.0): A malicious actor with access to the network could exploit an Improper Input Validation vulnerability found in UniFi…
- CVE-2026-48056 — Critical (CVSS 10.0): Streambert is a cross-platform Electron Desktop App to stream and download video content. Versions prior to 2.5.0…
- CVE-2026-33267 — Critical (CVSS 10.0): Improper Input Validation vulnerability in Apache Traffic Server. This issue affects Apache Traffic Server: from 9.2.0…
- CVE-2026-47668 — Critical (CVSS 10.0): DbGate is cross-platform database manager. In versions 7.1.8 and prior, DbGate's JSON script runner (`POST…
Browse all CWE-20 (Improper Input Validation) vulnerabilities →