EUVD-2026-41833
GHSA-566h-v38h-3xp3
Severity by source
AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N
Unauthenticated HTTP header injection (AV:N/AC:L/PR:N) gives high index disclosure (C:H); added A:L reflects described CPU-heavy regex queries; no integrity impact.
Primary rating from Vendor (apache).
CVSS VectorVendor: apache
Lifecycle Timeline
8Blast Radius
ecosystem impact- 9 maven packages depend on org.apache.camel:camel-lucene (3 direct, 6 indirect)
Ecosystem-wide dependent count for version 4.0.0.
DescriptionCVE.org
Improper Input Validation, Authorization Bypass Through User-Controlled Key vulnerability in Apache Camel Lucene Component.
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. 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. 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).
AnalysisAI
Query injection and authorization bypass in the Apache Camel Lucene component (camel-lucene) lets remote unauthenticated HTTP clients override the full-text search a route intends to run. Because the raw header names QUERY and RETURN_LUCENE_DOCS lack the Camel/camel prefix, HttpHeaderFilterStrategy does not strip them at the HTTP boundary, so an attacker-supplied header flows straight into the Exchange and executes against the index - enabling disclosure of documents the requester should not see (e.g. a match-all query dumping the whole index) and CPU-heavy regex queries. Affects 4.0.0-4.14.7, 4.15.0-4.18.2, and 4.19.0-4.20.x; no public exploit identified at time of analysis, and EPSS is low (0.16%, 6th percentile).
Technical ContextAI
The affected technology is Apache Camel, a widely-used Java enterprise integration framework, specifically its optional camel-lucene component which wraps Apache Lucene full-text search. The root cause (CWE-20, Improper Input Validation, combined with Authorization Bypass Through User-Controlled Key) is a header-namespace mismatch: the Lucene producer reads its search phrase from LuceneConstants.HEADER_QUERY, whose literal value is the un-prefixed string 'QUERY' (and 'RETURN_LUCENE_DOCS' for HEADER_RETURN_LUCENE_DOCS). Camel's HttpHeaderFilterStrategy only blocks headers in the Camel/camel namespace when crossing the HTTP boundary, so these un-namespaced keys are treated as legitimate inbound application headers and are copied into the Exchange. When a route exposes a Lucene query behind an HTTP consumer such as platform-http, the user-controlled header value becomes the effective search key, overriding the query the route author configured. CPE identifies the affected product as cpe:2.3:a:apache_software_foundation:apache_camel_lucene.
RemediationAI
Vendor-released patches are available: upgrade to Apache Camel 4.21.0 (primary fix), or on the LTS/maintenance streams to 4.14.8 (4.14.x) or 4.18.3 (4.18.x). After upgrading, routes that previously set the search via the raw header names must switch to the now-prefixed CamelLuceneQuery (and CamelLuceneReturnLuceneDocs) headers, since the old QUERY/RETURN_LUCENE_DOCS names will no longer be honored - treat this as a required code change, not optional. For deployments that cannot upgrade immediately, strip the attacker-controllable headers before the Lucene producer and set the query from a trusted source: removeHeader('QUERY') and removeHeader('RETURN_LUCENE_DOCS'), then setHeader('QUERY', constant(...)) at the start of the route; the trade-off is that any legitimate client that relied on passing these headers will break, so confirm no intended callers depend on them. Additionally, authenticating the HTTP consumer removes the no-credential path. See the advisory at https://camel.apache.org/security/CVE-2026-46585.html.
Same weakness CWE-20 – Improper Input Validation
View allSame technique Authentication Bypass
View allShare
External POC / Exploit Code
Leaving vuln.today