# UnrealIRCd CVE-2026-114713 ya está en KEV y manda en el servidor > El fallo en labeled-response permite inyectar comandos de confianza entre servidores enlazados; CISA da hasta el 16 de noviembre para parchear. > Por José Maldonado · Ciberseguridad · 2026-11-14 UnrealIRCd publicó el 7 de noviembre de 2026 la versión 6.2.7.1 y un parche en caliente que cierra nueve fallos de seguridad a la vez. Uno de ellos permite que un usuario cualquiera, sin privilegio alguno, ejecute comandos con la autoridad de un servidor de la red. La [nota de la versión 6.2.7.1](https://www.unrealircd.org/) lo describe como el problema más grave encontrado en el proyecto en quince años. El 13 de noviembre, la agencia de ciberseguridad de Estados Unidos lo metió en su catálogo de explotación confirmada y fijó el 16 como fecha límite. El identificador es CVE-2026-114713 y el error vive en labeled-response, una extensión del estándar IRCv3 que permite a un cliente etiquetar una petición para reconocer después qué respuesta le corresponde. El servidor devuelve esa etiqueta sin limpiar los saltos de línea que el cliente haya metido dentro. En un protocolo de texto donde cada línea es un comando, un salto de línea sobrante es una orden nueva, y la clasificación oficial encaja: CWE-140, neutralización incorrecta de delimitadores. La distancia entre un fallo curioso y un incidente la marca la topología. En un servidor suelto, la línea inyectada se queda en la misma máquina que ya la recibió del cliente y el atacante no gana nada. En una red con dos o más servidores enlazados, ese texto entra por el canal de administración y el nodo vecino lo ejecuta como si lo hubiera firmado un par de confianza. IRC sigue vivo en comunidades de software libre, en servidores de videojuegos y en canales de soporte técnico, y muchos de esos nodos se autoalojan en una sola máquina. ## Un canal de administración que no vuelve a pedir credenciales El enlace entre dos servidores de una red es una relación de confianza ya establecida. No hay usuario que suplantar ni contraseña que adivinar: hay un canal que el diseño trata como interno, y ahí es donde este fallo encuentra su hueco. Los dos extremos de ese canal no son usuarios: se autentican una vez con una contraseña compartida o con una huella de clave, y desde ese momento intercambian mensajes con un prefijo que identifica al emisor. El receptor no vuelve a comprobar credenciales en cada línea porque el enlace ya está establecido, y ahí está el sentido de la confianza entre pares. La [especificación de labeled-response](https://ircv3.net/specs/extensions/labeled-response) añade la pieza que aquí se rompe: un tag \`label\` cuyo valor elige el cliente, opaco y de 64 bytes como máximo, que el servidor debe repetir tal cual en su respuesta. En UnrealIRCd, la rutina que validaba ese valor miraba el formato y no escapaba el contenido al devolverlo. El [registro de CVE-2026-114713 en el NVD](https://nvd.nist.gov/vuln/detail/CVE-2026-114713) señala la función labeled\_response\_mtag\_is\_ok() dentro de labeled-response.c y resume el resultado sin adornos: cualquier usuario de una red con dos o más servidores enlazados puede inyectar comandos entre servidores que se ejecutan con autoridad de servidor. La nota CVSS 3.1 es 8,6 sobre 10 con alcance cambiado y complejidad baja, sin privilegios previos ni interacción del usuario. Lo que consigue ese cliente lo enumera el propio aviso: matar conexiones ajenas, imponer bloqueos de red y actuar en general con permisos de operador sin serlo. El [texto firmado por el mantenedor](https://www.openwall.com/lists/oss-security/2026/11/08/1) añade que el paquete de nueve arreglos incluye dos fugas de dirección IP, una de ellas un «decloak» que revela la IP de la víctima a cualquier interesado. El resto de la cadena tampoco es nuevo. Los servidores de una red se autentican entre sí desde los años noventa, y lo nuevo es que un campo de correlación haya acabado siendo una vía de escritura hacia dentro. ## Dos caminos de corrección y cuatro estados posibles El rango declarado va de la 6.0.0 a la 6.2.7, y ahí no termina el problema. La rama 5 también está expuesta y lleva en fin de vida desde el 1 de julio de 2023, así que no habrá binario corregido para ella. Bram Matthys, responsable del proyecto, escribe que las versiones más antiguas no se han revisado y que es probable que varios de los fallos arreglados se remonten a la 3.2.x, lo que deja a esas instalaciones sin diagnóstico ni fecha de reparación. La corrección llega por dos vías y la primera ahorra la ventana de mantenimiento. El parche en caliente se lanza con ./unrealircd hot-patch bundle-20261107 sobre cualquier versión entre la 6.0.0 y la 6.2.7, sustituye el módulo en memoria y recarga la configuración sin cortar el servicio. La segunda es actualizar a la 6.2.7.1 y reiniciar el proceso. La comprobación posterior distingue los dos estados y conviene ejecutarla, porque el fallo más caro de este tipo es el que se cree parcheado. Versión Estado Qué hacer Cómo verificarlo 6.2.7.1 Corregida actualizar y reiniciar module-status devuelve 6.2.7.1 6.0.0 a 6.2.7 Afectada hot-patch sin reinicio module-status devuelve 5.0-hot-patch-bundle-20261107 5.x, fin de vida el 1 de julio de 2023 Afectada blacklist-module y reinicio el módulo desaparece de MODULE -all 3.2.x y 4 Sin revisar migrar a la 6.2.7.1 no hay comprobación posible El paso previo que recomienda el aviso tiene truco. Antes de parchear, pide lanzar como operador un filtro de spam con una expresión regular que bloquea las etiquetas con caracteres prohibidos, y avisa de que esa red solo queda cubierta si todos los servidores están en la 6.0.4 o superior. En una red mixta, el filtro protege a los nodos nuevos y deja fuera a los viejos, que es exactamente el escenario donde el salto entre servidores convierte un error de escapado en un mando a distancia. Los ocho fallos restantes no escalan privilegios, pero ninguno es cosmético. Dos revelan la dirección IP de un usuario, uno cuelga el servidor al revisar listas negras y otro lo tumba al cambiar la identidad desde los servicios. Entre los demás hay un contador que responde «servidor lleno», un tope a los bloqueos y una caída de whowas. ## Tres días de plazo en un catálogo de 1.781 entradas El [catálogo KEV](https://www.cisa.gov/known-exploited-vulnerabilities-catalog) incorporó el fallo el 13 de noviembre de 2026 con fecha de cierre el 16. Son tres días, lo que en la práctica significa que un administrador federal pasa el fin de semana aplicando el parche. La ficha añade tres etiquetas de evaluación: explotación activa, automatizable e impacto técnico total. La primera la firma la agencia y no el proyecto, porque el aviso de UnrealIRCd no menciona campañas ni un exploit público, y tampoco víctimas. Ese plazo se lee mejor al lado de los demás y del trabajo que exige cada producto. El [Patch Tuesday de noviembre de 2026](https://observatorioblockchain.com/ciberseguridad/patch-tuesday-noviembre-2026-outlook-cero-dia/) entró en el mismo catálogo el 10 de noviembre con un cero-día de Outlook y plazo hasta el 24. El [CVE-2026-125350 de Chrome](https://observatorioblockchain.com/ciberseguridad/chrome-cve-2026-125350-octavo-cero-dia/) recibió la misma fecha. Dos semanas para parches que obligan a reiniciar escritorios y navegadores; tres días para un servidor que se arregla con un comando y una recarga. Fuera de las agencias federales no hay plazo que valga. Un nodo comunitario puede seguir meses en la 6.2.7 sin que nadie lo revise, y ese es el público real de este fallo. Para el perfil que corre UnrealIRCd, la ventana es más realista de lo que aparenta. Un operador de IRC ya sabe rehashear sin cortar el servicio porque lo hace cada vez que cambia una configuración, y el parche se verifica con una orden que devuelve el nombre del bundle instalado. Lo que no existe es la coacción: nadie va a auditar el cumplimiento de una red de cinco servidores montada por aficionados, y el olvido es tan probable como la pereza. ## La confianza entre pares honestos se rompe por el lado del cliente El diseño de IRC asume que los servidores de una red son pares que se conocen y se autentican una vez. Este fallo no rompe esa autenticación, la esquiva: usa una extensión pensada para que un cliente ordene sus respuestas y la convierte en un canal de escritura hacia el interior de la red. El patrón se repite en cualquier protocolo de texto donde un campo elegido por el cliente vuelve al emisor sin sanear, y esta semana el [fallo de OpenSSH y musl](https://observatorioblockchain.com/ciberseguridad/openssh-sshole-cve-2026-123158-musl-contrasena/) recordó que las piezas que casi nadie revisa siguen dando sustos. Matthys añade el dato que más incomoda. La auditoría que encontró estos nueve fallos fue interna, con ayuda de inteligencia artificial, y suma unas cien horas desde febrero de 2026. Su conclusión es que cualquier demonio de red sin arreglos de seguridad recientes probablemente no ha recibido visitas de un modelo, o las ha recibido de alguien que no las contó. Quien administre un nodo autoalojado tiene una decisión simple estos días: aplicar bundle-20261107, actualizar a la 6.2.7.1 o cortar el enlace con el resto de la red mientras lo decide.