CVE-2026-48205
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 · uneditedImproper 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 confidenceApache 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.
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>= 4.0.0, < 4.14.8>= 4.15.0, < 4.18.3>= 4.19.0, < 4.21.0CVSS 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 checksWork through these to decide whether this CVE applies to you.
-
Identify Apache Camel versionCheck 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
-
Locate DNS component usageSearch route definitions (Java, XML, or YAML) for 'dns:' component URIs, or search for imports of org.apache.camel.component.dns.DnsProducer or DnsEndpointAffected if Routes use the DNS component (dns:...) to perform DNS lookups
-
Confirm HTTP entry point existsCheck route definitions for HTTP-based consumers such as servlet, jetty, netty-http, or rest-dsl bindings that accept incoming HTTP requestsAffected if The application exposes an HTTP endpoint (consumer) that can receive external request headers
-
Inspect header filtering configurationExamine 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* prefixAffected 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.
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 · scoped4.14.84.18.34.21.0
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.
4.21.0 (or 4.14.8 for 4.14.x LTS, 4.18.3 for 4.18.x)
- Upgrade to Apache Camel 4.21.0 (or 4.14.8 for LTS / 4.18.3 for the 4.18.x stream)
- 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
- 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
- Alternatively, set the DNS server and lookup parameters from a trusted static source in the route definition rather than from message headers
Generated from the published advisory — verify against the referenced sources before acting.
- Consultation3.0 h
- Implementation4.0 h
- Testing2.0 h
- Review / QA2.0 h
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 locallyCheck 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 sourcesPractitioner notes
ContributedPeer-ranked notes from engineers who’ve handled CVE-2026-48205 in production — separate from our analysis above.
The advisory tells you what broke. It rarely tells you what actually worked. If you’ve dealt with this one, that detail is what the next engineer is searching for.
- The version that genuinely resolved it — not the one the vendor claimed
- A config change or rule that shut the vector down
- A gotcha in the upgrade path that cost you an afternoon
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.
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.
- 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