Plugins CoreDNS : Cluster-DNS vulnérable sans authentification

Deux nouvelles vulnérabilités CoreDNS affectent le DNS des clusters : rewrite avec retour EDNS0 et proxyproto sous PROXY v2. Un client non authentifié peut compromettre la disponibilité – dans un cas, un simple datagramme UDP de 28 octets suffit. Corrections apportées dans les versions 1.14.5 et 1.14.4.

Contexte : 622 CVE : prioriser plutôt que patcher dans la panique  ·  Une faille CI/CD a publié le chargeur de botnet AsyncAPI  ·  Mini Shai-Hulud : un ver npm dévore la chaîne d’approvisionnement

Ce que déclenchent techniquement les deux vulnérabilités

CoreDNS constitue la couche DNS pour les services et les pods dans de nombreux stacks Kubernetes et cloud-native. Les vulnérabilités se situent dans deux plugins spécifiques et interviennent dans le traitement des réponses et des paquets.

CVE-2026-62299 concerne le plugin rewrite avant la version 1.14.5. Dans le cas de règles EDNS0 avec l’option revert, les règles de réponse accèdent à res.IsEdns0() et déréférencent le résultat sans vérification de nil, lorsqu’un plugin en aval fournit une réponse sans enregistrement OPT. Un client distant non authentifié peut, avec une requête DNS appropriée, provoquer une panique dans le ResponseReverter. Conséquence : un SERVFAIL et une perte de disponibilité. Avec le recovery désactivé via la directive debug, le processus peut s’arrêter brutalement. Source : NVD et GitHub Advisory GHSA-9pmm-cxww-rrr7, score CNA-CVSS 5.3 (Disponibilité Faible).

CVE-2026-62309 affecte proxyproto avant la version 1.14.4. Un seul datagramme UDP de 28 octets contenant un en-tête PROXY-v2 et un transport non-UDP (par exemple, un octet de famille 0x11) entraîne un pointeur nil dans PacketConn.ReadFrom lors de l’enregistrement de addr.String(), avant que le recovery de ServeDNS ne s’applique. Score CNA-CVSS 7.5 (Disponibilité Élevée). Source : NVD et GHSA-9rvv-m5g5-wc8r.

Pourquoi cela impacte le plan de contrôle

Les pannes DNS au sein d’un cluster agissent comme un multiplicateur silencieux : la découverte de services se bloque, les sidecars et les contrôleurs d’entrée perdent leurs cibles, les vérifications d’état échouent. Une attaque par déni de service (DoS) contre CoreDNS paralyse ainsi la capacité opérationnelle des charges de travail qui en dépendent.

Les deux vulnérabilités sont classées CWE-476 (référence de pointeur NULL). Elles concernent la disponibilité. Selon les vecteurs CNA, la confidentialité et l’intégrité des données ne sont pas affectées. La priorité reste élevée lorsque CoreDNS constitue la seule couche de résolution DNS du cluster et qu’il est dimensionné sans budget de disruption pour les pods.

Le cadre CISA-SSVC attribue à la CVE-2026-62299 les indicateurs automatable=yes et exploitation=poc. Pour la CVE-2026-62309, il s’agit de automatable=yes et exploitation=none (état actuel de l’enrichissement de l’avis). Pour les opérateurs, l’enjeu réside dans la surface d’attaque accessible : règles de réécriture avec retour à EDNS0 et proxyproto exposé avant l’application du correctif.

Contexte DACH : CoreDNS est un serveur DNS largement utilisé dans les environnements Kubernetes en Europe germanophone (DACH – Allemagne, Autriche, Suisse). Le CISA-SSVC (Stakeholder-Specific Vulnerability Categorization) est un cadre américain pour évaluer les vulnérabilités en fonction de leur impact et de leur exploitabilité, tandis que le CNA (CVE Numbering Authority) désigne les organisations habilitées à attribuer des identifiants CVE.

Ce que les équipes doivent vérifier dès maintenant

Première étape : l’inventaire. Quelle version de CoreDNS tourne dans vos clusters ? Quels plugins sont activés dans le Corefile ? proxyproto est relativement récent et souvent utile uniquement derrière des load-balancers. Quant à rewrite avec EDNS0-revert, c’est une configuration plus spécifique – et c’est précisément là que se niche la vulnérabilité CVE-62299.

Si vous utilisez un service Kubernetes managé, consultez le journal des modifications de la control plane fourni par votre prestataire. Pour les déploiements auto-gérés ou les distributions on-premise, la responsabilité des correctifs vous incombe. Commencez par les clusters de staging avec les mêmes plugins Corefile, puis passez à la production avec un déploiement contrôlé.

Gestion des correctifs sans précipitation

Deux vulnérabilités dans des plugins en une seule journée : de quoi déclencher une alerte groupée. La méthode la plus fiable reste pourtant la même : évaluer la surface d’attaque et la fenêtre de correction, puis établir les priorités. Les clusters exposés via un chemin DNS public et utilisant le protocole proxyproto passent avant ceux dotés d’une réécriture interne sans retour à EDNS0. Les correctifs sont déjà disponibles – la version 1.14.4 pour proxyproto, la 1.14.5 pour rewrite. Ceux qui mettent déjà à jour peuvent directement adopter la branche la plus récente.

Pour suivre les sources primaires : les entrées NVD pour les CVE-2026-62299 et CVE-2026-62309, les avis de sécurité GitHub, ainsi que les tags de release CoreDNS v1.14.4 et v1.14.5.

Questions fréquentes

Chaque question est fermée. Un clic révèle la réponse.

Quelles versions de CoreDNS sont concernées ?

CVE-2026-62299 : rewrite avant 1.14.5. CVE-2026-62309 : proxyproto avant 1.14.4. Les correctifs sont inclus dans les versions mentionnées.

Faut-il patcher immédiatement tous les clusters Kubernetes ?

Dès lors que les plugins concernés sont actifs et accessibles, priorisez. Sans proxyproto et sans EDNS0-revert dans rewrite, l’exposition pratique diminue – la gestion des versions reste toutefois obligatoire.

S’agit-il d’une fuite de données ou d’une exécution de code à distance ?

Selon l’évaluation de la CNA, les deux CVEs visent la disponibilité (DoS/Panic). La confidentialité et l’intégrité ne sont pas affectées dans ces vecteurs.

La version 1.14.4 suffit-elle comme version cible ?

1.14.4 corrige proxyproto. Pour rewrite (62299), 1.14.5 est la version de correctif indiquée. Pour couvrir les deux problèmes, planifiez 1.14.5 ou ultérieur.

Où se trouvent les avis officiels ?

GitHub Security Advisories GHSA-9pmm-cxww-rrr7 et GHSA-9rvv-m5g5-wc8r, ainsi que NVD et les notes de version de CoreDNS pour v1.14.4/v1.14.5.

Conseils de lecture de la rédaction

Conseil de lecture622 CVEs : Prioriser plutôt que paniquerConseil de lectureDeux téléchargements Joomla dans le CISA-KEVConseil de lectureCI/CD a publié le chargeur de botnet AsyncAPI

Plus du réseau MBF Media

cloudmagazinCloudFront 5xx : Ce que les équipes VPC Origins doivent vérifierMyBusinessFuture

Pour aller plus loin

Pratique & Mise en œuvre · 31 juillet 2026

Anthropic : Claude a compromis trois entreprises

Anthropic Claude : trois organisations testées en cybersécurité. Harness-Misconfig, PyPI-Malware, checklist CISO.

Pratique & Mise en œuvre · 29 juillet 2026

Codex Security : Client ouvert alimente OpenAI

Codex Security CLI : Code client sous Apache-2.0 ouvert, Backend de scan en phase beta limitée contre l'infrastructure OpenAI.

Pratique & Mise en œuvre · 29 juillet 2026

Perte de Hugging Face : l’alerte a sonné, le triage a échoué

Lors de la perte de Hugging Face, l’analyse en temps réel et le SIEM ont agi. La priorisation est restée trop faible et les …

WordPress multilingue avec WPML