CoreDNS-Plugins: Cluster-DNS fällt ohne Auth-Schutz

Zwei frische CoreDNS-Lücken treffen die Cluster-DNS: rewrite mit EDNS0-revert und proxyproto unter PROXY v2. Ein unauthentifizierter Client kann die Verfügbarkeit drücken – in einem Fall reicht ein 28-Byte-UDP-Datagramm. Fixed in 1.14.5 bzw. 1.14.4.

Verwandt: 622 CVEs: Priorisieren statt Panic-Patchen  ·  CI/CD publizierte den AsyncAPI-Botnet-Loader  ·  Mini Shai-Hulud: npm-Wurm frisst die Lieferkette

Was die beiden Lücken technisch auslösen

CoreDNS ist in vielen Kubernetes- und Cloud-native-Stacks die DNS-Schicht für Services und Pods. Die Lücken sitzen in zwei konkreten Plugins und greifen dort in die Antwort- und Paketverarbeitung ein.

CVE-2026-62299 betrifft das rewrite-Plugin vor Version 1.14.5. Bei EDNS0-Regeln mit optionalem revert greifen Response-Regeln auf res.IsEdns0() zu und dereferenzieren das Ergebnis ohne Nil-Check, wenn ein Downstream-Plugin eine Antwort ohne OPT-Record liefert. Ein entfernter, unauthentifizierter Client kann mit einer passenden DNS-Query den ResponseReverter in Panic treiben. Folge: SERVFAIL und Verfügbarkeitsverlust. Mit deaktiviertem Recovery über die debug-Direktive kann der Prozess hart beenden. Quelle: NVD und GitHub Advisory GHSA-9pmm-cxww-rrr7, CNA-CVSS 5.3 (Availability Low).

CVE-2026-62309 betrifft proxyproto vor 1.14.4. Ein einzelnes 28-Byte-UDP-Datagramm mit PROXY-v2-Header und non-UDP-Transport (etwa Family-Byte 0x11) führt in PacketConn.ReadFrom zu einem Nil-Pointer beim Logging von addr.String(), bevor ServeDNS-Recovery greift. CNA-CVSS 7.5 (Availability High). Quelle: NVD und GHSA-9rvv-m5g5-wc8r.

Warum das die Control-Plane trifft

DNS-Ausfälle im Cluster wirken wie ein stiller Multiplikator: Service-Discovery stockt, Sidecars und Ingress verlieren Ziele, Health-Checks kippen. Ein DoS auf CoreDNS blockiert die Betriebsfähigkeit der Workloads darüber.

Beide Issues sind CWE-476 (NULL Pointer Dereference). Es geht um Verfügbarkeit. Vertraulichkeit und Integrität der Daten sind laut CNA-Vektoren unberührt. Die Priorität bleibt hoch, wenn CoreDNS die einzige Resolver-Schicht im Cluster ist und ohne Pod-Disruption-Budget skaliert.

CISA-SSVC markiert CVE-2026-62299 mit automatable=yes und exploitation=poc. CVE-2026-62309 mit automatable=yes und exploitation=none (Stand der Advisory-Anreicherung). Für Operatoren zählt die erreichbare Angriffsfläche: rewrite-Regeln mit EDNS0-revert und exposed proxyproto vor dem Patch.

Was Teams jetzt prüfen

Zuerst Inventar: Welche CoreDNS-Version läuft in den Clustern? Welche Plugins stehen im Corefile? proxyproto ist relativ neu und oft nur hinter Load-Balancern sinnvoll. rewrite mit EDNS0-revert ist spezieller – genau dort sitzt 62299.

Wer managed Kubernetes nutzt, prüft den Control-Plane-Change-Log des Anbieters. Eigenbetrieb und On-Prem-Distributionen bleiben in der eigenen Patch-Verantwortung. Staging-Cluster mit denselben Corefile-Plugins zuerst, dann Produktion mit kontrolliertem Rollout.

Einordnung ohne Panic-Patchen

Zwei Plugin-Lücken an einem Tag laden zum Batch-Alarm. Der belastbare Weg bleibt: Angriffsfläche und Fix-Fenster klären, dann priorisieren. Cluster mit öffentlichem DNS-Pfad und aktivem proxyproto stehen vor Cluster mit internem rewrite ohne EDNS0-revert. Die Fixes sind veröffentlicht – 1.14.4 für proxyproto, 1.14.5 für rewrite. Wer sowieso aktualisiert, nimmt die neuere Linie.

Primärquellen zum Nachziehen: NVD-Einträge CVE-2026-62299 und CVE-2026-62309, die GitHub Security Advisories und die CoreDNS-Release-Tags v1.14.4 sowie v1.14.5.

Häufige Fragen

Jede Frage ist verschlossen. Ein Tippen entriegelt die Antwort.

Welche CoreDNS-Versionen sind betroffen?

CVE-2026-62299: rewrite vor 1.14.5. CVE-2026-62309: proxyproto vor 1.14.4. Beide Fixes sind in den genannten Releases enthalten.

Muss jedes Kubernetes-Cluster sofort patchen?

Sobald die betroffenen Plugins aktiv und erreichbar sind, priorisieren. Ohne proxyproto und ohne EDNS0-revert im rewrite sinkt die praktische Exposition – die Versionspflege bleibt trotzdem Pflicht.

Ist das ein Datenleck oder RCE?

Nach CNA-Bewertung zielen beide CVEs auf Availability (DoS/Panic). Vertraulichkeit und Integrität sind in den Vektoren unberührt.

Reicht 1.14.4 als Zielversion?

1.14.4 schließt proxyproto. Für rewrite (62299) ist 1.14.5 die genannte Fix-Version. Wer beide Issues abdecken will, plant 1.14.5 oder neuer.

Wo liegen die offiziellen Advisories?

GitHub Security Advisories GHSA-9pmm-cxww-rrr7 und GHSA-9rvv-m5g5-wc8r, plus NVD und die CoreDNS-Release-Notes zu v1.14.4/v1.14.5.

Lesetipps der Redaktion

Lesetipp622 CVEs: Priorisieren statt Panic-PatchenLesetippZwei Joomla-Uploads landen im CISA-KEVLesetippCI/CD publizierte den AsyncAPI-Botnet-Loader

Mehr aus dem MBF Media Netzwerk

cloudmagazinCloudFront 5xx: Was VPC Origins Teams prüfen müssenMyBusinessFutureDer blinde Fleck der Digitalisierungsführer: Warum Banken trotz hoher IT-Investitionen an ihrem Datenchaos scheiternDigital ChiefsWie man Open Source ausbremst, ohne es zu verbieten

Bildquelle: KI-generiert (Juli 2026)