FKIE_CVE-2026-35579
Vulnerability from fkie_nvd - Published: 2026-05-05 21:16 - Updated: 2026-07-24 21:10
Severity
9.8 (Critical) - CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
7.5 (High) - CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N
7.5 (High) - CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N
Summary
CoreDNS is a DNS server written in Go. In versions prior to 1.14.3, the gRPC, QUIC, DoH, and DoH3 transport implementations incorrectly handle TSIG authentication. For gRPC and QUIC, the server checks whether the TSIG key name exists in the configuration but never calls dns.TsigVerify() to validate the HMAC. If the key name matches a configured key, the tsigStatus field remains nil and the tsig plugin treats the request as successfully authenticated regardless of the MAC value. For DoH and DoH3, the issue is more severe: the DoHWriter.TsigStatus() method unconditionally returns nil, and the server never inspects the TSIG record at all. Any request containing a TSIG record is treated as authenticated over DoH and DoH3, even if the key name is invalid and the MAC is arbitrary.
An unauthenticated network attacker can exploit this to bypass TSIG-protected functionality such as AXFR/IXFR zone transfers, dynamic DNS updates, or other TSIG-gated plugin behavior. The DoH and DoH3 variants have a lower exploitation bar because the attacker does not need to know a valid TSIG key name.
This issue has been fixed in version 1.14.3. As a workaround, disable gRPC, QUIC, DoH, and DoH3 listeners where TSIG authentication is required, or restrict network-level access to affected transport ports to trusted sources only.
References
Impacted products
| Vendor | Product | Version | |
|---|---|---|---|
| coredns.io | coredns | * |
{
"affected": [
{
"affectedData": [
{
"product": "coredns",
"vendor": "coredns",
"versions": [
{
"status": "affected",
"version": "\u003c 1.14.3"
}
]
}
],
"source": "security-advisories@github.com"
},
{
"affectedData": [
{
"collectionURL": "https://catalog.redhat.com/software/containers/",
"cpes": [
"cpe:/a:redhat:acm:2.14::el9"
],
"defaultStatus": "affected",
"packageName": "rhacm2/lighthouse-coredns-rhel9",
"product": "Red Hat Advanced Cluster Management for Kubernetes 2.14",
"vendor": "Red Hat",
"versions": [
{
"lessThan": "*",
"status": "unaffected",
"version": "1780204249",
"versionType": "rpm"
}
]
},
{
"collectionURL": "https://access.redhat.com/downloads/content/package-browser/",
"cpes": [
"cpe:/a:redhat:acm:2"
],
"defaultStatus": "unaffected",
"packageName": "rhacm2/lighthouse-agent-rhel9",
"product": "Red Hat Advanced Cluster Management for Kubernetes 2",
"vendor": "Red Hat"
},
{
"collectionURL": "https://access.redhat.com/downloads/content/package-browser/",
"cpes": [
"cpe:/a:redhat:openshift:4"
],
"defaultStatus": "unaffected",
"packageName": "openshift4/ose-coredns-rhel9",
"product": "Red Hat OpenShift Container Platform 4",
"vendor": "Red Hat"
}
],
"source": "0b0ca135-0b70-47e7-9f44-1890c2a1c46c"
}
],
"configurations": [
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:a:coredns.io:coredns:*:*:*:*:*:*:*:*",
"matchCriteriaId": "0B1F8FE2-314C-4C38-9F18-099ACCFF0AAD",
"versionEndExcluding": "1.14.3",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
]
}
],
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "CoreDNS is a DNS server written in Go. In versions prior to 1.14.3, the gRPC, QUIC, DoH, and DoH3 transport implementations incorrectly handle TSIG authentication. For gRPC and QUIC, the server checks whether the TSIG key name exists in the configuration but never calls dns.TsigVerify() to validate the HMAC. If the key name matches a configured key, the tsigStatus field remains nil and the tsig plugin treats the request as successfully authenticated regardless of the MAC value. For DoH and DoH3, the issue is more severe: the DoHWriter.TsigStatus() method unconditionally returns nil, and the server never inspects the TSIG record at all. Any request containing a TSIG record is treated as authenticated over DoH and DoH3, even if the key name is invalid and the MAC is arbitrary.\n\nAn unauthenticated network attacker can exploit this to bypass TSIG-protected functionality such as AXFR/IXFR zone transfers, dynamic DNS updates, or other TSIG-gated plugin behavior. The DoH and DoH3 variants have a lower exploitation bar because the attacker does not need to know a valid TSIG key name.\n\nThis issue has been fixed in version 1.14.3. As a workaround, disable gRPC, QUIC, DoH, and DoH3 listeners where TSIG authentication is required, or restrict network-level access to affected transport ports to trusted sources only."
},
{
"lang": "es",
"value": "CoreDNS es un servidor DNS escrito en Go. En versiones anteriores a la 1.14.3, las implementaciones de transporte gRPC, QUIC, DoH y DoH3 manejan incorrectamente la autenticaci\u00f3n TSIG. Para gRPC y QUIC, el servidor verifica si el nombre de la clave TSIG existe en la configuraci\u00f3n, pero nunca llama a dns.TsigVerify() para validar el HMAC. Si el nombre de la clave coincide con una clave configurada, el campo tsigStatus permanece nulo y el plugin tsig trata la solicitud como autenticada con \u00e9xito, independientemente del valor MAC. Para DoH y DoH3, el problema es m\u00e1s grave: el m\u00e9todo DoHWriter.TsigStatus() devuelve nulo incondicionalmente, y el servidor nunca inspecciona el registro TSIG en absoluto. Cualquier solicitud que contenga un registro TSIG se trata como autenticada a trav\u00e9s de DoH y DoH3, incluso si el nombre de la clave es inv\u00e1lido y el MAC es arbitrario.\n\nUn atacante de red no autenticado puede explotar esto para eludir la funcionalidad protegida por TSIG, como las transferencias de zona AXFR/IXFR, las actualizaciones din\u00e1micas de DNS u otro comportamiento de plugin restringido por TSIG. Las variantes de DoH y DoH3 tienen una barrera de explotaci\u00f3n m\u00e1s baja porque el atacante no necesita conocer un nombre de clave TSIG v\u00e1lido.\n\nEste problema ha sido corregido en la versi\u00f3n 1.14.3. Como soluci\u00f3n alternativa, deshabilite los oyentes gRPC, QUIC, DoH y DoH3 donde se requiera la autenticaci\u00f3n TSIG, o restrinja el acceso a nivel de red a los puertos de transporte afectados solo a fuentes confiables."
}
],
"id": "CVE-2026-35579",
"lastModified": "2026-07-24T21:10:00.143",
"metrics": {
"cvssMetricV31": [
{
"cvssData": {
"attackComplexity": "LOW",
"attackVector": "NETWORK",
"availabilityImpact": "HIGH",
"baseScore": 9.8,
"baseSeverity": "CRITICAL",
"confidentialityImpact": "HIGH",
"integrityImpact": "HIGH",
"privilegesRequired": "NONE",
"scope": "UNCHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
"version": "3.1"
},
"exploitabilityScore": 3.9,
"impactScore": 5.9,
"source": "nvd@nist.gov",
"type": "Primary"
},
{
"cvssData": {
"attackComplexity": "LOW",
"attackVector": "NETWORK",
"availabilityImpact": "NONE",
"baseScore": 7.5,
"baseSeverity": "HIGH",
"confidentialityImpact": "HIGH",
"integrityImpact": "NONE",
"privilegesRequired": "NONE",
"scope": "UNCHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
"version": "3.1"
},
"exploitabilityScore": 3.9,
"impactScore": 3.6,
"source": "0b0ca135-0b70-47e7-9f44-1890c2a1c46c",
"type": "Secondary"
}
],
"cvssMetricV40": [
{
"cvssData": {
"Automatable": "NOT_DEFINED",
"Recovery": "NOT_DEFINED",
"Safety": "NOT_DEFINED",
"attackComplexity": "LOW",
"attackRequirements": "PRESENT",
"attackVector": "NETWORK",
"availabilityRequirement": "NOT_DEFINED",
"baseScore": 8.2,
"baseSeverity": "HIGH",
"confidentialityRequirement": "NOT_DEFINED",
"exploitMaturity": "NOT_DEFINED",
"integrityRequirement": "NOT_DEFINED",
"modifiedAttackComplexity": "NOT_DEFINED",
"modifiedAttackRequirements": "NOT_DEFINED",
"modifiedAttackVector": "NOT_DEFINED",
"modifiedPrivilegesRequired": "NOT_DEFINED",
"modifiedSubAvailabilityImpact": "NOT_DEFINED",
"modifiedSubConfidentialityImpact": "NOT_DEFINED",
"modifiedSubIntegrityImpact": "NOT_DEFINED",
"modifiedUserInteraction": "NOT_DEFINED",
"modifiedVulnAvailabilityImpact": "NOT_DEFINED",
"modifiedVulnConfidentialityImpact": "NOT_DEFINED",
"modifiedVulnIntegrityImpact": "NOT_DEFINED",
"privilegesRequired": "NONE",
"providerUrgency": "NOT_DEFINED",
"subAvailabilityImpact": "NONE",
"subConfidentialityImpact": "NONE",
"subIntegrityImpact": "NONE",
"userInteraction": "NONE",
"valueDensity": "NOT_DEFINED",
"vectorString": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
"version": "4.0",
"vulnAvailabilityImpact": "NONE",
"vulnConfidentialityImpact": "HIGH",
"vulnIntegrityImpact": "NONE",
"vulnerabilityResponseEffort": "NOT_DEFINED"
},
"source": "security-advisories@github.com",
"type": "Secondary"
}
],
"ssvcV203": [
{
"source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"ssvcData": {
"id": "CVE-2026-35579",
"options": [
{
"exploitation": "poc"
},
{
"automatable": "yes"
},
{
"technicalImpact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-05-06T14:30:00.602863Z",
"version": "2.0.3"
}
}
]
},
"published": "2026-05-05T21:16:22.247",
"references": [
{
"source": "security-advisories@github.com",
"tags": [
"Exploit",
"Mitigation",
"Vendor Advisory"
],
"url": "https://github.com/coredns/coredns/security/advisories/GHSA-vp29-5652-4fw9"
},
{
"source": "0b0ca135-0b70-47e7-9f44-1890c2a1c46c",
"url": "https://access.redhat.com/errata/RHSA-2026:25127"
},
{
"source": "0b0ca135-0b70-47e7-9f44-1890c2a1c46c",
"url": "https://access.redhat.com/security/cve/CVE-2026-35579"
},
{
"source": "0b0ca135-0b70-47e7-9f44-1890c2a1c46c",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=2466905"
},
{
"source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"tags": [
"Exploit",
"Mitigation",
"Vendor Advisory"
],
"url": "https://github.com/coredns/coredns/security/advisories/GHSA-vp29-5652-4fw9"
},
{
"source": "0b0ca135-0b70-47e7-9f44-1890c2a1c46c",
"url": "https://security.access.redhat.com/data/csaf/v2/vex/2026/cve-2026-35579.json"
}
],
"sourceIdentifier": "security-advisories@github.com",
"vulnStatus": "Modified",
"weaknesses": [
{
"description": [
{
"lang": "en",
"value": "CWE-287"
}
],
"source": "security-advisories@github.com",
"type": "Secondary"
},
{
"description": [
{
"lang": "en",
"value": "CWE-303"
}
],
"source": "0b0ca135-0b70-47e7-9f44-1890c2a1c46c",
"type": "Secondary"
}
]
}
Loading…
Loading…
Experimental. This forecast is provided for visualization only and may change without notice. Do not use it for operational decisions.
Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
Loading…
The MITRE ATT&CK techniques below are AI-generated suggestions, inferred from the description of the
vulnerability by the CIRCL/vulnerability-attack-technique-classification-roberta-base
model, served locally by ML-Gateway.
They have not been verified by an analyst and are provided for guidance only.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Loading…
Loading…