Loading vulnerability…
CVE-2026-59230 is an improper input validation flaw in Apache Camel's camel-mail MimeMultipart data format. When unmarshalling a MIME multipart message with headersInline enabled, the component copies incoming MIME headers to the Camel Exchange using setHeader without applying a HeaderFilterStrategy. Apart from Message-ID, MIME-Version, and Content-Type, attacker-controlled MIME header names may therefore be introduced as Camel message headers, including headers in Camel's internal control namespace. Downstream Camel processors or producers can consume such headers to override route behavior. The issue affects versions from 2.17.0 before 4.14.9, from 4.15.0 before 4.18.4, and from 4.19.0 before 4.22.0.
Mallory correlates every CVE against your assets, your vendors, and active adversary campaigns. Know which vulnerabilities matter for you, not just which ones are loud.
What it means. What to do now. Patch path, mitigations, and the assume-compromise checklist.
What an attacker gets, and what they’ve been doing with it.
If you can’t patch tonight, do this now.
Patch, then assume compromise.
1 valid exploit after Mallory filtered fakes, detection scripts, and README-only repos.
Repository contains two self-contained Java proof-of-concept applications demonstrating CVE-2026-59230 in Apache Camel’s camel-mail MimeMultipart data format when headersInline=true: one variant for Camel Spring Boot and one for Camel Quarkus. Both projects package a vulnerable route, an internal secret endpoint, a legitimate backend endpoint, and an attacker driver endpoint that automatically sends benign and malicious MIME bodies. Core exploit capability: attacker-controlled MIME headers are copied onto the Camel Exchange during MimeMultipart unmarshal without HeaderFilterStrategy filtering. By embedding 'CamelHttpUri' in the MIME body, the exploit reintroduces a Camel internal header after the route strips Camel* headers at the HTTP boundary. The downstream Camel HTTP producer then honors the injected URI, redirecting the request from the intended /legit-backend to /internal/secret, demonstrating SSRF and disclosure of a hardcoded secret. Repository structure: top-level README explains the vulnerability, affected/fixed versions, and reproduction steps. The 'camel-spring-boot' subtree contains a Spring Boot app with Application.java, ExploitController.java, VictimRoute.java, Dockerfile, docker-compose.yml, pom.xml, and application.properties. The 'camel-quarkus' subtree mirrors the same logic using Quarkus with ExploitResource.java and VictimRoute.java. Both exploit drivers use Java HttpClient to POST a crafted MIME multipart body to /ingest as application/octet-stream, first without and then with the injected CamelHttpUri header. This is a real exploit reproducer rather than a scanner: it actively triggers the vulnerable code path and proves exploitation by causing the application to return data from an internal endpoint. Payloads are fixed and local, so maturity is best classified as OPERATIONAL rather than weaponized.
Products and vendors Mallory has correlated with this vulnerability. Open in Mallory to drill down to specific CPE configurations and version ranges.
Vendor-confirmed product mapping. Mallory continuously reconciles this list against your asset inventory.
2 sources tracked across advisories, community write-ups, and news. New activity surfaces here as Mallory finds it.
Query your assets running an affected version, and investigate the blast radius.
Every observed campaign linking this CVE to a named adversary.
Malware families riding this exploit, with evidence and IOCs.
YARA, Sigma, Snort, and vendor rules, auto-deployed to your SIEM.
Cross-references every affected SKU, including bundled OEM variants.
Community discussion across Reddit, Mastodon, and other social sources.