Executive brief
Apache Camel's ElasticSearch REST Client component fails to properly filter untrusted HTTP headers, allowing remote attackers to inject malicious query parameters without authentication. An attacker can exploit this to read all documents from a database, delete specific records, or exfiltrate sensitive data by crafting HTTP requests with specially-crafted headers that bypass the framework's inbound filtering. This affects any Camel integration that exposes an HTTP endpoint in front of an ElasticSearch operation.
Technical details
The vulnerability stems from improper input validation in the camel-elasticsearch-rest-client component. The component reads five Exchange headers (SEARCH_QUERY, OPERATION, INDEX_NAME, INDEX_SETTINGS, ID) to control Elasticsearch operations, but their constant names lack the "Camel" prefix used by other components. Camel's HttpHeaderFilterStrategy only blocks headers beginning with "Camel" or "camel", so these unprefixed headers pass through inbound filtering unchanged. When a route exposes an HTTP entry point (e.g., platform-http) before an elasticsearch-rest-client producer, an unauthenticated remote attacker can set these headers directly in HTTP requests to override the configured query and operation. Attack vectors include reading all index documents via SEARCH_QUERY with match_all, deleting records via OPERATION+ID, or field exfiltration. No credentials or user interaction are required. The fix (in versions 4.14.8, 4.18.3, and 4.21.0) renames header constants to carry the Camel prefix so they are properly filtered by HttpHeaderFilterStrategy.
Affected products
- Apache Camel 4.3.0 to 4.14.7, 4.15.0 to 4.18.2, 4.19.0 to 4.20.x
Timeline
- 2026-07-06: disclosed: Vulnerability published by GitHub Advisory Database
- 2026-07-06: patched: Fixes released: 4.14.8, 4.18.3, 4.21.0