Apache Camel security advisory: CVE-2026-46585
Severity
MEDIUMSummary
Camel-Lucene: The query control headers used non-Camel-prefixed names (QUERY, RETURN_LUCENE_DOCS) that bypass the HTTP header filter, allowing an HTTP client to inject the full-text search queryVersions affected
From 4.0.0 before 4.14.8, from 4.15.0 before 4.18.3, from 4.19.0 before 4.21.0.Versions fixed
4.14.8, 4.18.3 and 4.21.0Description
The camel-lucene producer reads the search phrase from an Exchange header (LuceneConstants.HEADER_QUERY) whose value was the plain string QUERY (and RETURN_LUCENE_DOCS for HEADER_RETURN_LUCENE_DOCS). Because these names do not start with the Camel / camel prefix, HttpHeaderFilterStrategy - which blocks only the Camel header namespace on the HTTP boundary - let them pass from an inbound HTTP request straight into the Exchange. In a route that exposes a Lucene query operation behind an HTTP consumer (for example platform-http), any HTTP client could therefore set the QUERY header and have its value executed against the full-text index, overriding the query the route intended to run. Depending on what is indexed, this allows reading documents the request should not have access to (for example a match-all query returns the entire index, or the route's intended per-user filter can be replaced), and expensive regular-expression queries can consume significant CPU. No credentials are required when the HTTP consumer is unauthenticated.Notes
The JIRA ticket: https://issues.apache.org/jira/browse/CAMEL-23509 refers to the various commits that resolved the issue, and have more details. The fix was merged on main in https://github.com/apache/camel/pull/23208 (commit 878ea07996caff19ed227984bf6cb6cf01983422) and backported to camel-4.18.x (commit 16a70d48145605c1a35e909d308bf9e5e2d3e7d8) and camel-4.14.x (commit 349f197115d60e0c180cf9836e08f4aeb5a87872). The fix renames the camel-lucene Exchange header values to the Camel convention - HEADER_QUERY from QUERY to CamelLuceneQuery, and HEADER_RETURN_LUCENE_DOCS from RETURN_LUCENE_DOCS to CamelLuceneReturnLuceneDocs - so they are filtered on the HTTP boundary like every other Camel control header. The constant field names are unchanged, so routes referencing LuceneConstants.HEADER_QUERY keep working; this is a breaking change for routes that set or read these headers by their raw string value (see the 4.21 upgrade guide). The issue is classified as CWE-20 (Improper Input Validation) and CWE-639 (Authorization Bypass Through User-Controlled Key). It belongs to the same Camel header-injection family as CVE-2025-27636, CVE-2025-29891, CVE-2025-30177, CVE-2026-40453, CVE-2026-46454 and CVE-2026-47323, and shares the non-Camel-prefixed-header-constant root cause with the camel-elasticsearch SEARCH_QUERY sibling.
Mitigation
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. After upgrading, routes that set the query via the raw header name must use CamelLuceneQuery (and CamelLuceneReturnLuceneDocs) instead of QUERY / RETURN_LUCENE_DOCS. For deployments that cannot upgrade immediately, strip the attacker-controllable headers before the Lucene producer and set the query from a trusted source (for example removeHeader(‘QUERY’) and removeHeader(‘RETURN_LUCENE_DOCS’), then setHeader(‘QUERY’, constant(…)) at the start of the route).Credit
This issue was discovered by Andrea Cosentino from the Apache Software Foundation and Yu Bao from PayPalReferences
- PGP signed advisory data: CVE-2026-46585.txt.asc
- Mitre CVE Entry: https://www.cve.org/CVERecord?id=CVE-2026-46585