CVE-2026-48203 in Camel
Summary
by MITRE • 07/06/2026
Improper Neutralization of Special Elements in Output Used by a Downstream Component ('Injection'), Improper Input Validation, Server-Side Request Forgery (SSRF) vulnerability in Apache Camel Solr component.
The camel-solr producer copies Exchange message headers whose names begin with the SolrParam. prefix into the parameters of the Solr request, and headers whose names begin with the SolrField. prefix into the fields of the indexed Solr document. The prefix constants (SolrConstants.HEADER_PARAM_PREFIX / HEADER_FIELD_PREFIX) were the plain strings SolrParam. / SolrField.. 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 bridges an HTTP consumer (for example platform-http) into a solr: producer, any HTTP client could therefore set SolrParam.* headers to inject arbitrary Solr request parameters - including shards or stream.url, which cause the Solr server to issue server-side requests to an attacker-chosen URL (server-side request forgery, for example to an internal service or a cloud metadata endpoint), or qt to reach administrative request handlers - and set SolrField.* headers to inject arbitrary fields into indexed documents. No credentials are required when the bridging 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 Solr parameters or fields via the raw header prefixes must use CamelSolrParam. / CamelSolrField. instead of SolrParam. / SolrField.. For deployments that cannot upgrade immediately, strip the SolrParam.* and SolrField.* headers from any untrusted ingress before the solr: producer, and set the required Solr parameters and fields from a trusted source in the route.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 07/06/2026
This vulnerability represents a critical injection flaw in Apache Camel's Solr component that stems from improper input validation and inadequate header filtering mechanisms. The issue manifests when the camel-solr producer processes Exchange message headers with specific prefixes, allowing malicious actors to inject arbitrary parameters into Solr requests through HTTP-boundary components. The root cause lies in the use of plain string prefixes SolrParam. and SolrField. instead of Camel-specific namespaces, which bypasses the HttpHeaderFilterStrategy that normally restricts only Camel-named headers at HTTP boundaries. This architectural oversight creates a pathway for server-side request forgery attacks where attackers can manipulate Solr parameters to make the server initiate requests to arbitrary URLs, including internal services or cloud metadata endpoints.
The technical exploitation of this vulnerability follows a well-defined pattern that aligns with CWE-74 and CWE-917 attack vectors. When an HTTP consumer bridges into a solr: producer, any unauthenticated client can set SolrParam. headers to inject parameters such as shards or stream.url that force Solr to make server-side requests to attacker-controlled destinations. Additionally, qt parameters can be used to access administrative request handlers, while SolrField. headers enable injection of arbitrary fields into indexed documents. This represents a classic case of insecure direct object reference combined with command injection, where the vulnerability exists at the interface between HTTP processing and downstream Solr operations. The attack surface is particularly dangerous because no authentication credentials are required when the bridging consumer is unauthenticated, making this a privilege escalation vector that can be exploited from external networks.
The operational impact of this vulnerability extends beyond simple data manipulation to potential system compromise and information disclosure. An attacker could exploit the SSRF capability to enumerate internal services, access cloud metadata APIs such as AWS EC2 instance metadata or Azure Instance Metadata Service, and potentially gain access to sensitive credentials stored in these endpoints. The injection of arbitrary Solr fields also enables data poisoning attacks that can corrupt indexed documents and potentially lead to denial of service conditions. This vulnerability affects multiple release streams of Apache Camel including versions 4.0.0 through 4.14.7, 4.15.0 through 4.18.2, and 4.19.0 through 4.20.9, indicating a widespread exposure across the product lifecycle. The vulnerability's severity is compounded by its ease of exploitation through standard HTTP client tools and its ability to bypass typical security controls that rely on header namespace filtering.
Mitigation strategies must address both immediate remediation and architectural prevention measures. The primary recommendation involves upgrading to patched versions 4.21.0, with specific LTS version upgrades for different release streams as noted. This upgrade ensures the use of proper Camel-specific header prefixes CamelSolrParam. and CamelSolrField. that are properly filtered by the HttpHeaderFilterStrategy. For deployments unable to upgrade immediately, administrators should implement explicit header stripping at ingress points before routing to solr: producers, removing all SolrParam. and SolrField. headers from untrusted sources. The recommended approach also includes configuring routes to set required Solr parameters and fields only from trusted internal sources rather than accepting them directly from external HTTP requests. This aligns with the principle of least privilege and defense-in-depth strategies outlined in MITRE ATT&CK framework for command and control activities. Organizations should also implement monitoring for suspicious Solr parameter usage patterns and consider network-level restrictions to prevent access to internal services from Solr servers, particularly when dealing with untrusted input sources.