Apache Camel DNS: The dns.* and term Exchange header constants used non-Camel-prefixed names that bypass the HTTP header filter, allowing an HTTP client to influence internal behaviour
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 use
- Products
- Not specified
- Affected versions
- Not specified
- Fixed versions
- Not specified
- CVEs
- CVE-2026-48205
- Confirmed fixed CVEs
- Not specified
- Updated in this feed
- 4 Nov 2026, 03:53 UTC · Revision 1
Source evidence
Apache Camel DNS: The dns.* and term Exchange header constants used non-Camel-prefixed names that bypass the HTTP header filter, allowing an HTTP client to influence internal behaviour
core-osv · Original sourcePublished 6 Jul 2026, 08:08 UTC
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 use
osv:CVE-2026-48205
Complete source record
{
"id": "9cfdeac1574ed928d50f385df14da9a6eb409bd3bcaf1a1bb7916d3221fd191c",
"url": "https://osv.dev/vulnerability/CVE-2026-48205",
"method": "structured",
"payload": {
"kind": "advisory",
"title": "Apache Camel DNS: The dns.* and term Exchange header constants used non-Camel-prefixed names that bypass the HTTP header filter, allowing an HTTP client to influence internal behaviour",
"summary": "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 use",
"evidence": "osv:CVE-2026-48205",
"products": [],
"severity": "critical",
"structured": {
"id": "CVE-2026-48205",
"aliases": [
"CVE-2026-48205",
"GHSA-hcm8-x79p-wx2w"
],
"metrics": [
{
"type": "CVSS_V3",
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N"
}
],
"affected": [
{
"ranges": [
{
"repo": "https://github.com/apache/camel",
"type": "GIT",
"events": [
{
"introduced": "8d135894cd73970c82da5da0dc71ecc7f5521ad5"
},
{
"fixed": "1451d25df0fbfc7020514dc30f8ec9a59f759ae9"
},
{
"introduced": "038f1b2acd0b2ee78e4bb84cd3139e64610bb259"
},
{
"fixed": "ee3bff8b44b38deff7b4f1b665691954e08b2ccd"
},
{
"introduced": "3e9f3011ad48de66fef582ade9794c7340c23af7"
},
{
"fixed": "1d22f8df5d2dab2c309243879373230f4b24487d"
}
],
"database_specific": {
"extracted_events": [
{
"cpe": "cpe:2.3:a:apache:camel:*:*:*:*:*:*:*:*",
"range": [
{
"introduced": "4.0.0"
},
{
"fixed": "4.14.8"
}
],
"source": "CPE_RANGE"
},
{
"cpe": "cpe:2.3:a:apache:camel:*:*:*:*:*:*:*:*",
"range": [
{
"introduced": "4.15.0"
},
{
"fixed": "4.18.3"
}
],
"source": "CPE_RANGE"
},
{
"cpe": "cpe:2.3:a:apache:camel:*:*:*:*:*:*:*:*",
"range": [
{
"introduced": "4.19.0"
},
{
"fixed": "4.21.0"
}
],
"source": "CPE_RANGE"
}
]
}
}
],
"database_specific": {
"source": "https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2026-48205.json"
}
}
],
"modified": "2026-10-28T02:30:32.889301250Z",
"provider": "osv",
"references": [
"https://repo.maven.apache.org/maven2",
"https://camel.apache.org/security/CVE-2026-48205.html",
"https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/48xxx/CVE-2026-48205.json",
"https://nvd.nist.gov/vuln/detail/CVE-2026-48205"
],
"provider_metadata": {
"cwe_ids": [
"CWE-20",
"CWE-918"
],
"cna_assigner": "apache",
"unresolved_ranges": [
{
"extracted_events": [
{
"range": [
{
"introduced": "4.0.0"
},
{
"fixed": "4.14.8"
},
{
"introduced": "4.15.0"
},
{
"fixed": "4.18.3"
},
{
"introduced": "4.19.0"
},
{
"fixed": "4.21.0"
}
],
"source": "AFFECTED_FIELD",
"strategy": "StandardRange"
}
]
}
],
"osv_generated_from": "https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/48xxx/CVE-2026-48205.json"
}
},
"related_cves": [
{
"value": "CVE-2026-48205",
"evidence": "/id"
}
],
"security_relevant": true,
"severity_evidence": "/severity/0/score"
},
"source_id": "core-osv",
"document_id": 500159,
"published_at": "2026-07-06T08:08:19.869+00:00"
}