Unbound 1.26.1: actualiza tu resolver DNS para cerrar dos RCE críticas

septiembre 19, 2026 Alfonso Moreno | Sysadmin Senior 48 Visitas 9 min de lectura

TL;DR — Lo que vas a tener al final

Tiempo de setup: 30 minutos a 2 horas dependiendo de la complejidad del entorno.
Requisitos: Acceso root, Linux moderno, conexión a internet para descargar dependencias.
Resultado: Servicio funcional y estable, documentado paso a paso.
Troubleshooting: Logs estándar en /var/log/, comandos de verificación al final de cada sección.

Por qué Unbound importa en 2026

Unbound es uno de los resolvers DNS recursivos más usados en Linux: es el default en varias distribuciones como OpenBSD, se integra con Pi-hole y AdGuard Home para upstream, y corre como daemon ligero en miles de homelabs y servidores Linux que necesitan validación DNSSEC sin las complicaciones de BIND. Si tu red hace algo más que navegar (filtrado, DNS-over-HTTPS, caching masivo, split-horizon) probablemente lo estés corriendo, aunque no lo sepas.

El 16 de septiembre de 2026, NLnet Labs publicó Unbound 1.26.1, una versión de seguridad que corrige nueve vulnerabilidades en los releases previos, dos de ellas con potencial de ejecución remota de código. Si tienes Unbound expuesto a Internet o incluso solo resolviendo para tu LAN, este update toca actualizar.

Las dos críticas que sí importan

El advisory de NLnet Labs lista nueve CVEs, pero dos concentran la atención porque comparten un patrón: heap-based buffer overflow con posible RCE bajo ciertas configuraciones.

CVE-2026-81642 — heap overflow en el validador DNSSEC

Vector: un atacante que controla una zona maliciosa puede disparar el overflow cuando un resolver vulnerable la consulta. La falla está en la rutina que digiere registros DNSKEY durante la validación DNSSEC: no se valida correctamente el tamaño del buffer antes de escribir, así que un DNSKEY crafted puede sobrescribir memoria heap adyacente.

Impacto: denial of service garantizado y, según NLnet Labs y CWE-122, posible ejecución remota de código. CVSS base alrededor de 9.8 en el escenario de red. El atacante no necesita autenticación ni interacción del usuario; basta con que el resolver procese la zona maliciosa.

Mitigación: Unbound 1.26.1 incluye el fix. Si no puedes actualizar de inmediato, NLnet Labs distribuye el parche patch_CVE-2026-81642_with.diff que se aplica sobre 1.26.0.

CVE-2026-82717 — heap corruption en CNAME synthesis

Vector: durante la síntesis de un CNAME en una respuesta upstream, Unbound reescribe el TTL máximo dentro del buffer del paquete. Si el paquete contiene un compression pointer que apunta exactamente al valor sobrescrito, el nombre de dominio se invalida y la rutina de error no reposiciona correctamente el cursor del buffer. Resultado: heap overflow progresivo.

Credit: Ben Morris de Anthropic.

Impacto: denial of service por corrupción de heap, y posible RCE “bajo ciertos sistemas y opciones de compilación”, en palabras del advisory. Lo que significa: depende de tu allocator (glibc, jemalloc, musl) y de flags de compilación como fortificación, ASLR y sanitizers.

Mitigación: Unbound 1.26.1 también lo corrige. Parche independiente disponible en patch_CVE-2026-82717_with.diff.

Las otras siete que no debes ignorar

El resto del batch son severidad media-alta y se arreglan en el mismo 1.26.1, así que no hay razón para no actualizar completo:

CVE	Componente	Impacto
CVE-2026-81634	DNSSEC canonicalization	Heap overflow, DoS (High)
CVE-2026-78227	DoQ (DNS over QUIC) stream output buffer	Use-after-free en retransmisión
CVE-2026-82720	DoH (DNS over HTTPS) stream cleanup	Use-after-free en cleanup path
CVE-2026-42923	NSEC3 hash calculations	Degradación de servicio (alto consumo CPU)
CVE-2026-41292	EDNS options parsing	Degradación de rendimiento
CVE-2026-42955	Ghost domain en A/AAAA glue	Extensión de ventana ghost domain (Low)
CVE-2026-40622	NS glue (TTL clamp)	Ghost domain renewal vía glue

Las dos primeras de la tabla son High severity. Las cuatro siguientes degradan disponibilidad o rendimiento. La última (CVE-2026-42955) es Low pero cierra una variante del problema “ghost domain” que NLnet Labs viene parcheando desde 2024.

Cómo saber si estás afectado

Primero, identifica qué versión tienes corriendo. En Debian/Ubuntu con el paquete oficial:

unbound -V | head -1
# unbound 1.20.0

El comando imprime versión + linked libs. Si devuelve 1.20.0, 1.24.x, 1.25.x o 1.26.0, estás en un release vulnerable. Solo 1.26.1 y superiores traen los fixes completos.

Si lo corres como servicio systemd, valida que el binario no esté pinned a una versión vieja por algún fork:

systemctl status unbound --no-pager | grep -E 'Active|version'
# Active: active (running)
ls -la /usr/sbin/unbound
# -rwxr-xr-x 1 root root 248912 sep 18 10:42 /usr/sbin/unbound

Confirma además que el binario NO viene de un backport o PPA propio de la distro: revisa /etc/apt/sources.list.d/ y busca entradas custom que puedan tener un Unbound más viejo que el del repo principal. Esto es común en routers y NAS que reciclan binarios viejos.

Cómo actualizar

El camino limpio es vía el package manager de tu distro. En Debian 12+ y Ubuntu 24.04 los paquetes se actualizaron al cierre de esta semana:

sudo apt update
sudo apt install --only-upgrade unbound
unbound -V | head -1
# unbound 1.26.1
sudo systemctl restart unbound
sudo systemctl status unbound --no-pager

El flag --only-upgrade evita que apt instale Unbound si no estaba presente. Después del restart, valida con unbound-control status que el daemon aceptó la configuración y quedó respondiendo queries.

En Fedora, RHEL y derivadas el flujo es equivalente:

sudo dnf upgrade unbound
unbound -V | head -1
sudo systemctl restart unbound

Si tu distro aún no tiene 1.26.1 en repos (puede pasar en stable branches de CentOS Stream o Rocky), tienes dos opciones: instalar desde el código fuente oficial, o aplicar el patch combinado sobre tu 1.26.0. NLnet Labs mantiene un patch que cubre las nueve CVE en un solo archivo:

wget https://nlnetlabs.nl/downloads/unbound/patch_combined-1.26.1_v2.diff
cd unbound-1.26.0
patch -p1 < ../patch_combined-1.26.1_v2.diff
./configure --prefix=/usr --sysconfdir=/etc/unbound
make -j$(nproc)
sudo make install
sudo systemctl restart unbound

El patch combinado existe en versión minimal (solo fixes de seguridad) y with (incluye code improvements y tests). Para producción, preferimos with: pesa unos pocos KB más pero agrega los tests que validan que el fix realmente cubrió el vector de ataque original.

Verificación post-update

Después de reiniciar el daemon, confirma tres cosas: que está resolviendo, que la validación DNSSEC sigue funcionando y que el puerto 53 (o 853 si usas DoT) responde.

# 1. Versión correcta
unbound -V | head -1
# 2. DNSSEC valida (debe devolver "secure")
dig +short +dnssec fail.freebsd.org A @127.0.0.1
# A 192.168.1.50
# ;Secure
# 3. Puerto abierto local
ss -tlnp | grep :53
# LISTEN 0 128 0.0.0.0:53 0.0.0.0:* users:(("unbound",pid=8421,fd=3))

El truco del fail.freebsd.org es un test clásico: es un dominio que deliberadamente tiene DNSSEC roto. Si tu resolver lo marca como SERVFAIL en vez de devolver la IP, está validando DNSSEC correctamente.

Si tu Unbound está detrás de Pi-hole o AdGuard Home (modo 127.0.0.1#5353 como upstream), reiniciá también esos servicios para que el cambio se propague:

sudo systemctl restart pihole-FTL
# o
sudo systemctl restart AdGuardHome

Algunos setups de Pi-hole cachean la versión del upstream y siguen mandando queries al viejo socket hasta que pihole-FTL relee su config. Si después del restart sigues viendo queries rechazadas, un pihole restartdns manual suele destrabarlo.

Cuándo NO te afecta

Si usas BIND, Knot Resolver, dnsmasq o PowerDNS Recursor, este batch no te toca. Cada resolver tiene su propia base de código y su propio advisory track. BIND publicó su propio update mensual en septiembre; Knot Resolver no tiene CVEs abiertos críticos en este momento; dnsmasq arrastra una serie de CVEs históricos pero ninguna con RCE reciente.

Si tu distro ya hizo EOL (Debian 10, Ubuntu 20.04, CentOS 7) y no tienes soporte comercial, vas a tener que backportear manualmente o migrar a una versión soportada. NLnet Labs distribuye los parches en formato upstream y se pueden aplicar sobre 1.24.x o 1.25.x con ajustes menores, pero no es trivial y requiere validación.

Operadores expuestos: revisen configs agresivas

Un detalle del advisory de CVE-2026-81642: el ataque requiere que Unbound consulte una zona controlada por el atacante. Si tu unbound.conf tiene access-control permisivo (default 0.0.0.0/0 allow) y estás resolviendo para hosts que hacen queries a dominios arbitrarios, el vector está abierto.

Si por el contrario tu Unbound solo resuelve para una LAN cerrada y los clientes son de confianza (caso típico homelab), el riesgo baja bastante, pero no a cero: una respuesta cacheada de una zona maliciosa consultada hace 30 días puede re-disparar el overflow si la cache no se purgó después del update.

El fix recomendado después de actualizar:

sudo unbound-control flush_zone .
sudo systemctl restart unbound

Esto purga toda la cache. Después va a tardar unos minutos en repoblarse, pero te aseguras de no estar sirviendo respuestas de una zona maliciosa que disparen el bug pre-patch si por algún motivo el binario se rollbacka.

Resumen

Unbound 1.26.1 cierra nueve CVEs, dos de ellas críticas con RCE potencial (CVE-2026-81642 y CVE-2026-82717). El update toca hacerlo esta semana: si tienes Unbound expuesto a Internet o resolviendo para tu LAN, estás dentro del universo afectado. El fix es estándar (package manager o patch oficial) y la verificación post-update es de cinco minutos.

Para la mayoría de los homelabs, el riesgo real es bajo porque las configuraciones típicas no exponen Unbound a Internet directamente. Pero un resolver vulnerable en una LAN grande es un excelente pivote para ataques internos una vez que un atacante entra por otro vector: actualizar cierra esa puerta antes de que alguien la encuentre.

Preguntas frecuentes

¿Por qué Unbound 1.26.1: actualiza tu resolver DNS para cerrar dos RCE críticas es relevante para sysadmins Linux?

Forma parte del flujo diario de administración. Los conceptos explicados se aplican directamente a servidores en producción y resuelven problemas reales que enfrentan sysadmins hispanohablantes.

¿Qué necesito para empezar con Unbound 1.26.1: actualiza tu resolver?

Distribución Linux actualizada (Debian, Ubuntu, RHEL, Fedora o Arch), acceso root, y conexión a internet. Para producción: entorno de staging separado antes de aplicar cambios.

¿Cuáles son los errores más comunes con Unbound 1.26.1: actualiza tu resolver?

Los tres más frecuentes: (1) saltar la lectura de logs, (2) aplicar cambios directos en producción sin probar, (3) olvidar permisos y ownership. La documentación y un plan de rollback siempre.

¿Cuándo usar Unbound 1.26.1: actualiza tu resolver y cuándo una alternativa?

Esta solución es ideal para el caso descrito. Alternativas como Docker, Ansible o configuración manual pueden ser mejores según contexto: portabilidad, escala y reproducibilidad son los factores clave.

¿Cómo migro desde una configuración previa a Unbound 1.26.1: actualiza tu resolver?

Documentar el estado actual, probar la nueva configuración en staging, validar funcionalmente, y aplicar en producción con rollback plan listo. Los posts de SoyLinux incluyen troubleshooting para los problemas más comunes.