What is the CVSS score of CVE-2026-46453?

CVE-2026-46453 has a CVSS 3.1 base score of 5.3 (Medium). CVSS vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N. EPSS exploitation probability: 0.2%.

Is there a patch available for CVE-2026-46453?

Yes, a patch is available for CVE-2026-46453. Update the affected software to the latest version immediately.

Apache Camel CVE-2026-46453

EUVD-2026-41827 MEDIUM

Improper Input Validation (CWE-20)

2026-07-06 apache

GHSA-rp9m-hfv5-pfvr

Authentication Bypass Apache Java Microsoft Red Hat Elastic Apache Camel Apache Software Foundation

5.3

CVSS 3.1 · Vendor: apache

Severity by source

Vendor (apache) PRIMARY

5.3 MEDIUM

AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N

vuln.today AI

10.0 CRITICAL

Network-reachable HTTP endpoint, no credentials required per description, scope changes to Elasticsearch backend; deletion capability adds low availability impact.

3.1 AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:L

4.0 AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:L/SC:H/SI:H/SA:L

Red Hat

5.3 MEDIUM

qualitative

Primary rating from Vendor (apache).

CVSS VectorVendor: apache

Attack Vector

Network

Attack Complexity

Low

Privileges Required

None

User Interaction

None

Scope

Unchanged

Confidentiality

Low

Integrity

None

Availability

None

Lifecycle Timeline

CVSS changed

Jul 06, 2026 - 19:22 NVD

5.3 (MEDIUM)

Patch available

Jul 06, 2026 - 10:01 EUVD

Analysis Generated

Jul 06, 2026 - 09:30 vuln.today

Blast Radius

ecosystem impact

† from your stack dependencies † transitive graph · vuln.today resolves 4-path depth

5 maven packages depend on org.apache.camel:camel-elasticsearch-rest-client (2 direct, 3 indirect)

Ecosystem-wide dependent count for version 4.3.0.

DescriptionCVE.org

Improper Input Validation, Authorization Bypass Through User-Controlled Key vulnerability in Apache Camel ElasticSearch Rest Client.

The camel-elasticsearch-rest-client component reads several Exchange headers to control its behaviour - SEARCH_QUERY (an advanced query body), OPERATION (which Elasticsearch operation to run), INDEX_NAME, INDEX_SETTINGS and ID. The string values of these header constants, defined in ElasticSearchRestClientConstant, are plain unprefixed names ('SEARCH_QUERY', 'OPERATION', 'INDEX_NAME', 'INDEX_SETTINGS', 'ID') rather than the 'Camel'-prefixed names used by every other Camel component (for example CamelSqlQuery, CamelMongoDbCriteria, CamelCqlQuery). Camel's inbound HTTP header filter, HttpHeaderFilterStrategy, blocks only header names that begin with 'Camel' or 'camel'. Because the Elasticsearch header names do not carry that prefix, they pass through the inbound filter unchanged. When a Camel route exposes an HTTP entry point (for example platform-http) in front of an elasticsearch-rest-client producer, an untrusted HTTP client can set these headers directly on its request and override the query and operation that the route author configured: reading every document in the index (SEARCH_QUERY with a match_all query), deleting documents (OPERATION set to Delete together with ID), or exfiltrating selected fields. No credentials are required and the producer reads the headers unconditionally. This issue affects Apache Camel: from 4.3.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. The fix renames the camel-elasticsearch-rest-client Exchange header constant string values (ID, SEARCH_QUERY, INDEX_SETTINGS, INDEX_NAME, OPERATION) to carry the Camel prefix (CamelElasticsearchId, CamelElasticsearchSearchQuery, CamelElasticsearchIndexSettings, CamelElasticsearchIndexName, CamelElasticsearchOperation) so that they are blocked by the inbound HttpHeaderFilterStrategy; the Java field names are unchanged. For deployments that cannot upgrade immediately, strip the affected headers from untrusted inbound messages before they reach the producer (for example removeHeader('SEARCH_QUERY'), removeHeader('OPERATION'), removeHeader('INDEX_NAME'), removeHeader('INDEX_SETTINGS') and removeHeader('ID') in front of the elasticsearch-rest-client endpoint), or apply a custom HeaderFilterStrategy that blocks these names.

AnalysisAI

Authorization bypass in Apache Camel's camel-elasticsearch-rest-client component allows unauthenticated remote attackers to override Elasticsearch query operations by injecting HTTP headers. Because the component uses unprefixed header constants ('SEARCH_QUERY', 'OPERATION', 'INDEX_NAME', 'INDEX_SETTINGS', 'ID') that are not blocked by Camel's inbound HttpHeaderFilterStrategy - which filters only 'Camel'-prefixed names - any HTTP client reaching a Camel route that fronts an elasticsearch-rest-client producer can substitute their own query body, operation type, or target index. Practical outcomes include full index enumeration via match_all, targeted document deletion, and field-level data exfiltration. No public exploit has been identified at time of analysis and this CVE is not listed in CISA KEV, but the attack requires no credentials and is trivially reproducible from the description alone.

Technical ContextAI

Apache Camel (CPE: cpe:2.3:a:apache_software_foundation:apache_camel) is a Java-based enterprise integration framework implementing the Enterprise Integration Patterns. Its camel-elasticsearch-rest-client component acts as an Elasticsearch HTTP REST API producer, driven by Exchange message headers that parameterize queries and operations. The root cause (CWE-20: Improper Input Validation) manifests as a naming convention inconsistency: ElasticSearchRestClientConstant defines header names as bare strings ('SEARCH_QUERY', 'OPERATION', etc.) rather than the 'Camel'-prefixed convention used universally elsewhere in the framework. Camel's HttpHeaderFilterStrategy - which enforces the security boundary between untrusted inbound HTTP headers and internal route processing - applies a prefix-based blocklist ('Camel' and 'camel'). Since the Elasticsearch header names lack this prefix, they are passed through unmodified into the Exchange, where the producer unconditionally reads and acts on them. A secondary CWE-639 (Authorization Bypass Through User-Controlled Key) characterizes the semantic outcome: the attacker controls which operation and data targets are sent to Elasticsearch by supplying their own key values in the Exchange headers.

RemediationAI

Upgrade Apache Camel to one of the following patched releases: 4.21.0 (main stream), 4.14.8 (4.14.x LTS stream), or 4.18.3 (4.18.x stream). The fix renames the ElasticSearch header constant string values to carry the 'CamelElasticsearch' prefix (e.g., CamelElasticsearchSearchQuery, CamelElasticsearchOperation, CamelElasticsearchId, CamelElasticsearchIndexName, CamelElasticsearchIndexSettings), which causes HttpHeaderFilterStrategy to block them at the inbound boundary. Note: the Java field names in ElasticSearchRestClientConstant are unchanged, so application code referencing the field constants does not require modification - only deployments using raw string header names will need updates. For deployments that cannot upgrade immediately, apply explicit header removal in the Camel route before the elasticsearch-rest-client endpoint using removeHeader('SEARCH_QUERY'), removeHeader('OPERATION'), removeHeader('INDEX_NAME'), removeHeader('INDEX_SETTINGS'), and removeHeader('ID'). Alternatively, implement a custom HeaderFilterStrategy that explicitly blocks these names. The header-stripping workaround is effective but requires remembering to maintain the blocklist if new header constants are added in future component versions - prefer upgrading. The vendor advisory is at https://camel.apache.org/security/CVE-2026-46453.html.