CamelApplication · Apache

CVE-2026-48205

CRITICAL · 9.1 CVSS v3.1 Published 2026-07-06
Fix available
A fix is available. Upgrade to 4.14.8 / 4.18.3 or later.
See remediation →
100/100
Remediation priority · Urgent
Remotely reachable No privileges Zero-click 7 weeks old

Official description Straight from the sourceThe vendor's or NVD's own wording, published unedited. Authoritative, but often terse — it says what broke, rarely what to do.

NVD · unedited
Improper Input Validation, Server-Side Request Forgery (SSRF) vulnerability in Apache Camel DNS component. The camel-dns producers read DNS operation parameters - the resolver to query, the name or domain to look up, the record type and class, and the search term - from Exchange message headers whose constant values (DnsConstants.DNS_SERVER, DNS_NAME, DNS_DOMAIN, DNS_TYPE, DNS_CLASS, TERM) were the plain strings dns.server, dns.name, dns.domain, dns.type, dns.class and term. 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 dns: producer, any HTTP client could therefore set the dns.server header to make the dig producer build a SimpleResolver pointing at an attacker-controlled DNS server - a server-side request forgery via DNS, through which the attacker observes the queried name and can return poisoned responses - and set the dns.name / dns.domain headers to resolve arbitrary internal hostnames, disclosing whether they exist (internal network reconnaissance). 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 drive DNS operations via the raw header names must use CamelDnsServer / CamelDnsName / CamelDnsDomain / CamelDnsType / CamelDnsClass / CamelDnsTerm instead of the dns.* / term names. For deployments that cannot upgrade immediately, strip the dns.* and term headers from any untrusted ingress before the dns: producer, and set the DNS server and lookup parameters from a trusted source in the route.

Technical summary Written by usOur analysis, written from the advisory, the CVSS vector and the affected-version data. It adds context the advisory leaves out, and never invents facts that are not in the source.

dbcve analysis · high confidence

Apache Camel's DNS component allows DNS operation parameters (resolver, name, domain, record type/class, search term) to be set via HTTP request headers with names like 'dns.server' and 'dns.name'. Since these lack the Camel/ camel prefix, HttpHeaderFilterStrategy doesn't block them at the HTTP boundary, enabling attackers to inject arbitrary DNS headers and achieve SSRF by directing the DNS producer to attacker-controlled servers or probing internal network hostnames.

MitigationUpgrade to Apache Camel 4.21.0 (or 4.14.8 for LTS 4.14.x / 4.18.3 for 4.18.x) and update routes to use CamelDnsServer/ CamelDnsName/ CamelDnsDomain/ CamelDnsType/ CamelDnsClass/ CamelDnsTerm header names instead of the vulnerable dns.*/ term names; alternatively, strip these headers at the ingress point.

Verify against the referenced sources before acting — the references below are authoritative for this CVE, this summary is not.

Affected products & versions What the vendor confirmedThe version ranges the vendor confirmed as vulnerable. If your version sits inside a range here, treat yourself as exposed until you have upgraded.

NVD · CPE data
CamelApplication
Affected:>= 4.0.0, < 4.14.8>= 4.15.0, < 4.18.3>= 4.19.0, < 4.21.0

CVSS breakdown How the score is builtThe industry scoring standard. It rates how the flaw is reached, what it takes to exploit, and what an attacker gains — the score is derived from those, not the other way round.

From the vector
Attack vector
Network
Complexity
Low
Privileges
None
User interaction
None
Scope
Unchanged
Confidentiality
High
Integrity
High
Availability
None

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

Am I affected? How to checkSteps we derive from the advisory and the affected-version data, so you can decide whether this CVE reaches your setup. They are a guide, not a scan — your own configuration is the authority.

dbcve checks

Work through these to decide whether this CVE applies to you.

  1. Identify Apache Camel version
    Check the Camel version in your project pom.xml, dependencies, or running application (e.g., mvn dependency:tree, or check the Camel JAR manifest)
    Affected if The version is >= 4.0.0 and < 4.14.8, OR >= 4.15.0 and < 4.18.3, OR >= 4.19.0 and < 4.21.0
  2. Locate DNS component usage
    Search route definitions (Java, XML, or YAML) for 'dns:' component URIs, or search for imports of org.apache.camel.component.dns.DnsProducer or DnsEndpoint
    Affected if Routes use the DNS component (dns:...) to perform DNS lookups
  3. Confirm HTTP entry point exists
    Check route definitions for HTTP-based consumers such as servlet, jetty, netty-http, or rest-dsl bindings that accept incoming HTTP requests
    Affected if The application exposes an HTTP endpoint (consumer) that can receive external request headers
  4. Inspect header filtering configuration
    Examine HttpHeaderFilterStrategy configuration in your CamelContext or spring/camel configuration files, and check if headers named dns.server, dns.name, dns.domain, dns.type, dns.class, or dns.term are explicitly blocked or renamed to use Camel* prefix
    Affected if The vulnerable dns.* headers (without Camel/ camel prefix) are NOT being filtered or renamed before reaching the DNS component

You are affected if you run an affected Camel version, use the DNS component in a route exposed via HTTP, and do not filter or rename the dns.server, dns.name, dns.domain, dns.type, dns.class, or dns.term headers at your HTTP ingress point.

Generated from the published advisory. Verify against your own configuration.

Check your environment

Paste your version and any relevant configuration and it will be compared against the affected criteria above. Do not include secrets or credentials.

AI-assisted, checked against the advisory. Informational, not a guarantee.

Remediation Closing itWhat it takes to close this. Where a vendor fix exists we point at it; where none exists we say so plainly, and can build one. Effort estimates are scoped from the advisory, not from your codebase.

dbcve · scoped
Upgrade available Upgrade to 4.14.8 / 4.18.3 / 4.21.0 or later
Fixed in 4.14.84.18.34.21.0
Interim mitigation

Upgrade to Apache Camel 4.21.0 (or 4.14.8 for LTS 4.14.x / 4.18.3 for 4.18.x) and update routes to use CamelDnsServer/ CamelDnsName/ CamelDnsDomain/ CamelDnsType/ CamelDnsClass/ CamelDnsTerm header names instead of the vulnerable dns.*/ term names; alternatively, strip these headers at the ingress point.

Recommended fix High confidence

4.21.0 (or 4.14.8 for 4.14.x LTS, 4.18.3 for 4.18.x)

  1. Upgrade to Apache Camel 4.21.0 (or 4.14.8 for LTS / 4.18.3 for the 4.18.x stream)
  2. After upgrading, update all routes that drive DNS operations to use the Camel-prefixed header names: CamelDnsServer instead of dns.server, CamelDnsName instead of dns.name, CamelDnsDomain instead of dns.domain, CamelDnsType instead of dns.type, CamelDnsClass instead of dns.class, and CamelDnsTerm instead of term
  3. For deployments that cannot upgrade immediately, configure HttpHeaderFilterStrategy or another filter to strip the raw dns.* and term headers from any untrusted inbound HTTP requests before they reach the dns: producer
  4. Alternatively, set the DNS server and lookup parameters from a trusted static source in the route definition rather than from message headers
Caveat Routes that use the raw header names (dns.server, dns.name, etc.) must be updated to use the Camel-prefixed names (CamelDnsServer, CamelDnsName, etc.) after upgrading

Generated from the published advisory — verify against the referenced sources before acting.

Fix this in Camel Scoped from the published advisory
  • Consultation3.0 h
  • Implementation4.0 h
  • Testing2.0 h
  • Review / QA2.0 h
11.0 hours of engineering $1,980
Get the upgrade done

An estimate, not a bill — we confirm scope with you before any work starts. Need it this week? Rush from $3,168.

Scan for this in your stack

Free · runs locally
dbcve dependency scanner

Check whether your project pulls in CVE-2026-48205 — or any other known-vulnerable package — straight from your lock files. Free and open source; it runs locally and uploads nothing.

References Go to the primary sourcePrimary sources — vendor advisories, patches and trackers. Where our summary and a reference disagree, the reference wins.

Primary sources

Practitioner notes

Contributed

Peer-ranked notes from engineers who’ve handled CVE-2026-48205 in production — separate from our analysis above.

No notes yet

Be the first to add a field note for this CVE — a mitigation you’ve verified, a version caveat, or a link to a working fix. Sign in above to contribute.

What this is

A place for practitioners to share what actually worked: a mitigation you’ve tested, a configuration change, a version- or environment-specific caveat, or a link to a verified patch. The most useful notes rise to the top as peers upvote them, so the signal stays high.

What belongs here
  • Verified mitigations, workarounds, and config changes
  • Version or environment caveats, and links to real fixes
  • No weaponised exploit code, or anything meant to cause harm
  • No spam, self-promotion, credentials, or personal data