Loading vulnerability…
CVE-2026-46585 is an authorization bypass and improper input-validation flaw in the Apache Camel Lucene component. In affected releases, the Lucene producer accepts query and return-document control values from legacy raw Exchange header names that do not use the Camel header namespace. Camel's HTTP header filtering therefore fails to remove these values when an HTTP request enters a route. An attacker can supply a query-control header to an HTTP consumer route that invokes a Lucene query producer, causing the producer to execute an attacker-selected Lucene query instead of the query intended by the route. The issue affects Apache Camel versions 4.0.0 through 4.14.7, 4.15.0 through 4.18.2, and 4.19.0 through 4.20.x.
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.
This repository is a self-contained Java/Spring Boot proof-of-concept for CVE-2026-46585, an Apache Camel camel-lucene header-injection/authorization-bypass issue. The exploit demonstrates that an HTTP client can supply the non-Camel-prefixed QUERY header to a public Camel HTTP route, and that header is forwarded into the Lucene query producer instead of being filtered at the HTTP boundary. As a result, attacker-controlled Lucene syntax is executed against the backend index. Repository structure is small and focused: Application.java is the Spring Boot entry point; IndexConfig.java defines the Lucene index directory bean; IndexBootstrap.java creates a demo index with 3 public documents and 1 secret document containing a benign flag; VictimRoute.java exposes the vulnerable platform-http:/search route and forwards requests to lucene:kb:query?indexDir=#kbIndexDir&maxHits=50 after only removing Camel* headers; ExploitController.java acts as the attacker and programmatically sends GET requests to the victim endpoint with injected QUERY headers. Supporting files include pom.xml pinning Camel 4.18.2, application.properties setting port 8080, and Docker/docker-compose files for containerized reproduction. Main exploit capability: unauthorized query override. The exploit first performs a benign search (QUERY=onboarding), then injects QUERY=visibility:secret to retrieve the secret document, and finally uses QUERY=*:* to dump the entire index. This is not RCE or deserialization; it is a web/network authorization-bypass and data-exfiltration PoC caused by unsafe trust in an inbound HTTP header. The code also highlights a secondary impact of denial of service through expensive Lucene query syntax. Overall, this is a valid operational PoC exploit rather than a detector or README-only repository.
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.
4 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.