Plugins de CoreDNS: DNS en clúster sin protección de

5 Min. Lectura

Dos vulnerabilidades recientes de CoreDNS afectan al DNS del clúster: reescritura con EDNS0-revert y proxyproto bajo PROXY v2. Un cliente no autenticado puede reducir la disponibilidad – en un caso basta con un paquete UDP de 28 bytes. Corregido en 1.14.5 o 1.14.4.

Relacionado: 622 CVE: Priorizar antes de parchear pánico  ·  CI/CD publicó el cargador del botnet AsyncAPI  ·  Mini Shai-Hulud: gusano npm devora la cadena de suministro

Qué provocan técnicamente estas brechas

CoreDNS es la capa DNS para servicios y pods en muchos stacks de Kubernetes y cloud‑native. Las brechas están en dos plugins concretos y actúan en la respuesta y el procesamiento de paquetes allí.

CVE-2026-62299 afecta al plugin rewrite antes de la versión 1.14.5. En reglas EDNS0 con revert opcional, las reglas de respuesta acceden a res.IsEdns0() y dereferecian el resultado sin verificación de nil cuando un plugin downstream entrega una respuesta sin registro OPT. Un cliente remoto y no autenticado puede provocar un pánico en ResponseReverter mediante una consulta DNS adecuada. Resultado: SERVFAIL y pérdida de disponibilidad. Con la directiva de recuperación desactivada a través de la directiva debug, el proceso se detiene abruptamente. Fuente: NVD y aviso de seguridad de GitHub GHSA-9pmm-cxww-rrr7, CNA-CVSS 5.3 (Disponibilidad baja).

CVE-2026-62309 afecta a proxyproto antes de la versión 1.14.4. Un único datagrama UDP de 28-Byte con encabezado PROXY-v2 y transporte no UDP (por ejemplo, byte de familia 0x11) produce un puntero nulo al hacer addr.String() en el registro antes de que ServeDNS-Recovery intervenga. CNA-CVSS 7.5 (Disponibilidad alta). Fuente: NVD y GHSA-9rvv-m5g5-wc8r.

Por qué el plano de control se ve afectado

Las interrupciones de DNS en el clúster actúan como un multiplicador silencioso: el descubrimiento de servicios se detiene, los sidecars e Ingress pierden objetivos, y los chequeos de salud se invierten. Un DoS en CoreDNS bloquea la operatividad de las cargas de trabajo superiores.

Ambos problemas son CWE-476 (Desreferencia nula de puntero). Se trata de disponibilidad. La confidencialidad y la integridad de los datos permanecen intactas según los vectores CNA. La prioridad sigue siendo alta cuando CoreDNS es la única capa de resolución en el clúster y se escala sin presupuesto de interrupción de pods.

CISA-SSVC marca CVE-2026-62299 con automatable=yes y exploitation=poc. CVE-2026-62309 con automatable=yes y exploitation=none (versión de la advisory). Para los operadores, la superficie de ataque alcanzable es clave: reglas de rewrite con EDNS0-revert y proxyproto expuesto antes del parche.

Qué deben revisar los equipos ahora

Primero, inventario: ¿Qué versión de CoreDNS se ejecuta en los clústers? ¿Qué plugins están en el Corefile? proxyproto es relativamente nuevo y suele ser útil solo detrás de balanceadores de carga. rewrite con EDNS0-revert es más específico – justo allí se encuentra 62299.

Quien utiliza Kubernetes gestionado, revisa el registro de cambios del plano de control del proveedor. Las implementaciones propias y on‑premise permanecen bajo tu responsabilidad de parcheo. Primero, los clústers de pruebas con los mismos plugins del Corefile, luego la producción con un despliegue controlado.

Clasificación sin parches de pánico

Dos vulnerabilidades en un plugin en un día disparan la alarma por lotes. El camino resistente sigue: clarificar la superficie de ataque y la ventana de parcheo, y luego priorizar. Los clusters con ruta DNS pública y proxyproto activo se enfrentan a clusters con rewrite interno sin revertir EDNS0. Los parches están publicados – 1.14.4 para proxyproto, 1.14.5 para rewrite. Quien ya actualiza, toma la rama más reciente.

Fuentes primarias para seguir: entradas NVD CVE-2026-62299 y CVE-2026-62309, los avisos de seguridad de GitHub y las etiquetas de lanzamiento de CoreDNS v1.14.4 y v1.14.5.

Preguntas frecuentes

Cada pregunta está bloqueada. Un toque desbloquea la respuesta.

¿Qué versiones de CoreDNS están afectadas?

CVE-2026-62299: reescritura antes de 1.14.5. CVE-2026-62309: proxyproto antes de 1.14.4. Ambos parches están incluidos en las versiones mencionadas.

¿Debe cada clúster de Kubernetes parchearse de inmediato?

En cuanto los complementos afectados estén activos y accesibles, priorizarlos. Sin proxyproto y sin EDNS0-revert en rewrite disminuye la exposición práctica – el mantenimiento de versiones sigue siendo obligatorio.

¿Es una filtración de datos o ejecución remota de código (RCE)?

Tras la evaluación de CNA, ambos CVE apuntan a Availability (DoS/Panic). Confidencialidad e integridad permanecen intactas en los vectores.

¿Sirve 1.14.4 como versión objetivo?

1.14.4 cierra proxyproto. Para rewrite (62299) la versión de corrección indicada es 1.14.5. Quien quiera cubrir ambos problemas planea 1.14.5 o superior.

¿Dónde están los avisos oficiales?

Advisories de seguridad de GitHub GHSA-9pmm-cxww-rrr7 y GHSA-9rvv-m5g5-wc8r, además del NVD y las notas de lanzamiento de CoreDNS v1.14.4/v1.14.5.

Selección de la redacción

Recomendado622 CVE: priorizar en lugar de parchear con pánicoRecomendadoDos vulnerabilidades de Joomla en la lista KEV de CISARecomendadoCI/CD publicó el cargador de botnet AsyncAPI

Más de la red MBF Media

cloudmagazinOrígenes de CloudFront 5xx: qué deben verificar los equipos de Orígenes VPCDigital ChiefsCómo frenar el código abierto sin prohibirlo