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

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

Which versions of Apache Camel are affected by CVE-2026-48203?

Apache Camel's solr component (versions 4.0.0 through 4.20.x) contains a server-side request forgery vulnerability allowing attackers to hijack Solr requests and access internal services or metadata…. A patch is available.

How to fix or mitigate CVE-2026-48203?

Within 24 hours: Identify and audit all Camel routes using HTTP consumers (e.g., platform-http) connected to solr: producers. Within 7 days: Upgrade Apache Camel from affected versions (4.0.0-4.14.7, 4.15.0-4.18.2, 4.19.0-4.20.x) to the patched release per vendor advisory; confirm patch version through Apache Camel security advisories. Within 30 days: Validate through integration testing and confirm network segmentation prevents untrusted client access to HTTP-exposed Camel routes.

Apache Camel CVE-2026-48203

EUVD-2026-41838 CRITICAL

Improper Input Validation (CWE-20)

2026-07-05

GHSA-4h4f-v54q-7pq8

SSRF Microsoft Apache Camel Red Hat

9.1

CVSS 3.1 · Vendor

Severity by source

Vendor (CNA) PRIMARY

9.1 MEDIUM

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

vuln.today AI

9.1 CRITICAL

Unauthenticated HTTP header injection (PR:N, AC:L, AV:N) yields SSRF disclosure (C:H) and document/field injection (I:H); no availability impact and scope kept unchanged, though the SSRF pivot could justify S:C.

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

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

Red Hat

7.5 HIGH

qualitative

Primary rating from Vendor (CNA).

CVSS VectorVendor

Attack Vector

Network

Attack Complexity

Low

Privileges Required

None

User Interaction

None

Scope

Unchanged

Confidentiality

High

Integrity

High

Availability

None

Lifecycle Timeline

Analysis Updated

Jul 06, 2026 - 21:20 vuln.today

v3 (cvss_changed)

Analysis Updated

Jul 06, 2026 - 21:20 vuln.today

v2 (cvss_changed)

Re-analysis Queued

Jul 06, 2026 - 20:22 vuln.today

cvss_changed

CVSS changed

Jul 06, 2026 - 20:22 NVD

9.1 (CRITICAL)

Patch available

Jul 06, 2026 - 10:01 EUVD

Analysis Generated

Jul 05, 2026 - 20:47 vuln.today

Description PRE-NVD

Disclosed via oss-security. NVD scoring and full description are pending.

Articles & Coverage 4

News 15 New Kubernetes Vulnerabilities - 8 Critical, 7 High Severity Jul 06, 2026 News 15 New Java Vulnerabilities - 8 Critical, 7 High Severity Patched Jul 06, 2026 News 15 New Apache Vulnerabilities - 8 Critical, 7 High Severity Patched Jul 06, 2026 News 15 New Java Vulnerabilities - 8 Critical, 7 High Severity Patched Jul 05, 2026

AnalysisAI

Server-side request forgery and parameter/field injection in the Apache Camel camel-solr component (versions 4.0.0 through 4.14.7, 4.15.0 through 4.18.2, and 4.19.0 through 4.20.x) allow remote attackers to hijack Solr requests issued by a Camel route. Because the SolrParam. and SolrField. header prefixes lack the Camel/camel namespace, HttpHeaderFilterStrategy does not strip them at the HTTP boundary, so any client hitting a route that bridges an HTTP consumer (e.g. platform-http) into a solr: producer can inject arbitrary Solr parameters - notably shards or stream.url to force the Solr server into attacker-chosen outbound requests (internal services, cloud metadata endpoints), or qt to reach admin handlers - and inject arbitrary indexed-document fields. Rated CVSS 9.1; there is no public exploit identified at time of analysis and EPSS is low (0.18%), but SSVC marks the flaw as automatable with total technical impact.

Technical ContextAI

Apache Camel is a widely used Java integration framework whose routes wire together 'consumers' (inbound endpoints) and 'producers' (outbound endpoints) via a message Exchange carrying headers. The camel-solr producer maps Exchange headers by prefix: names beginning SolrParam. become Solr request parameters and names beginning SolrField. become fields on the indexed document. The root cause is CWE-20 (Improper Input Validation), manifesting as header injection: the constants SolrConstants.HEADER_PARAM_PREFIX / HEADER_FIELD_PREFIX were the bare strings 'SolrParam.' and 'SolrField.', which do not carry the 'Camel'/'camel' prefix that HttpHeaderFilterStrategy uses to block internal headers crossing the HTTP boundary. As a result, untrusted inbound HTTP headers flow unfiltered into the Exchange and then into the downstream Solr request. The downstream sinks are legitimate Solr features abused as an SSRF primitive - shards and stream.url (the ContentStream/RemoteStreaming capability) cause the Solr server itself to issue outbound HTTP requests, and qt can route to administrative request handlers - turning a header-injection flaw into a genuine SSRF against whatever the Solr instance can reach.

RemediationAI

Vendor-released patch: upgrade to Apache Camel 4.21.0; users on the 4.14.x LTS stream should upgrade to 4.14.8 and users on the 4.18.x stream to 4.18.3, per http://camel.apache.org/security/CVE-2026-48203.html. Note a breaking behavioral change after upgrading: routes that intentionally set Solr parameters or fields via header prefixes must switch from the raw SolrParam. / SolrField. prefixes to the namespaced CamelSolrParam. / CamelSolrField. prefixes, or those headers will no longer be honored. For deployments that cannot upgrade immediately, the concrete workaround is to explicitly strip (remove) all SolrParam.* and SolrField.* headers from any untrusted ingress before the message reaches the solr: producer - for example with a removeHeaders step keyed on those prefixes - and instead set the required Solr parameters and fields from a trusted source within the route; the trade-off is that any legitimate client-supplied Solr parameters are lost and must be reconstructed server-side. Additionally restricting or authenticating the bridging HTTP consumer removes the no-credentials path.