Wazuh corrige trece fallos y una PoC encadena dos para dar root

Wazuh corrigió el 23 de septiembre de 2026 trece vulnerabilidades en su Manager, tres de ellas críticas que terminan en ejecución de comandos como root, y el 13 de octubre publicó los avisos que las detallan. Un día después apareció una prueba de concepto que encadena dos de esos fallos, CVE-2026-74034 y CVE-2026-74041, para tomar el servidor sin credenciales cuando el enrolamiento de agentes no pide contraseña.

Qué ha pasado

Wazuh es una plataforma SIEM y XDR de código abierto muy usada en centros de operaciones de seguridad, y su componente central, el Manager, concentra la recogida de eventos, las reglas de detección y la gestión de los agentes. La versión 4.14.8, publicada el 23 de septiembre de 2026 según las notas de esa versión, corrige trece vulnerabilidades del Manager. Los avisos de seguridad en GitHub y los registros CVE se hicieron públicos el 13 de octubre, en una divulgación coordinada posterior al parche. INCIBE-CERT se hizo eco el 16 de octubre con el aviso INCIBE-2026-753, de importancia crítica, que resume uno de los fallos y advierte de que permite «ejecutar comandos con privilegios de root en el servidor Wazuh Manager».

Las puntuaciones van de 4,3 a 9,1 en CVSS 3.1. Las tres críticas son CVE-2026-74041, un desajuste de mayúsculas entre el validador de configuración y el recolector de logs, CVE-2026-74040, una sobrescritura de ficheros del nodo maestro desde un nodo trabajador del clúster, y CVE-2026-74043, un salto de ruta al subir reglas y listas. Los descubridores que figuran en los avisos son namd0ng, vikman90, TarPeg007 y Jan Kahmen de turingpoint, entre otros.

El 14 de octubre, un día después de publicarse los avisos, apareció en Sploitus una prueba de concepto llamada wazuh-unauth-chain, atribuida al investigador roninreilly. Encadena CVE-2026-74034 y CVE-2026-74041 para lograr, según su descripción, ejecución de código como root sin autenticar y lectura de ficheros del servidor como root, siempre que el enrolamiento de agentes sin contraseña sea accesible. El autor dice haberla probado en un laboratorio contra Wazuh 4.14.5 y no acompaña un registro de ejecución independiente ni una prueba contra la versión parcheada, así que conviene tomar ese alcance con cautela.

El gráfico recoge las trece vulnerabilidades corregidas en 4.14.8 ordenadas por gravedad, con las tres críticas en cabeza.

Detalles técnicos

CVE-2026-74041 nace de una incoherencia entre dos componentes. El Manager valida la configuración ossec.conf que le suben con la función check_remote_commands, que distingue mayúsculas de minúsculas, pero el recolector wazuh-logcollector, escrito en C, interpreta el nombre del elemento sin distinguirlas. NVD lo describe como un «case-sensitivity mismatch between the ossec.conf validator and wazuh-logcollector» (un desajuste de mayúsculas entre el validador de ossec.conf y wazuh-logcollector). Un elemento LOG_FORMAT en mayúsculas pasa el filtro, pero el recolector lo ejecuta como comando con privilegios de root al recargar la configuración. El endpoint PUT /manager/configuration de la API y la ruta interna del clúster llegan al mismo validador, y el rol integrado cluster_admin ya trae el permiso manager:update_config que hace falta.

CVE-2026-74040 está en el método process_files_from_worker del maestro del clúster. Un nodo trabajador puede forzar al maestro a sobrescribir ficheros protegidos mediante una barra final en el nombre y la falta de comprobación de dirección de la transferencia. NVD resume que permite «a cluster worker to overwrite protected master files» (a un nodo trabajador sobrescribir ficheros protegidos del maestro). Sobrescribir ossec.conf da ejecución como root en el maestro y sobrescribir agent.conf empuja código a todos los agentes dados de alta. El atacante necesita controlar un nodo trabajador y la clave compartida del clúster, pero no credenciales de la API, según el aviso GHSA-88p6-7cm8-xwj8.

CVE-2026-74034 es una falta de comprobación de origen en el módulo wm_agent_upgrade, que corre como root. El módulo acepta órdenes de dos fuentes, la API y el canal de mensajes de los agentes, y no distingue cuál las envía. NVD indica que «allows enrolled agents to issue upgrade_custom commands with attacker-controlled file_path» (permite a agentes enrolados emitir órdenes upgrade_custom con una ruta de fichero controlada por el atacante). El Manager lee ese fichero como root y devuelve su contenido al agente, lo que expone /etc/shadow, client.keys y la clave de firma de la API. Con el enrolamiento sin contraseña, que es el valor por defecto, cualquier equipo puede darse de alta como agente y lanzar la petición sin credenciales, como recoge el aviso GHSA-r7hm-43xr-477j.

La prueba de concepto junta las dos piezas. Primero usa CVE-2026-74034 para leer como root la clave de firma de la API, con la que forja un token de administrador, y después aprovecha CVE-2026-74041 para colar un LOG_FORMAT en mayúsculas y ejecutar el comando al recargar. El diagrama reconstruye esa secuencia a partir de los avisos y de la descripción de la PoC, no de un detalle interno que Wazuh no ha publicado.

Para situar por qué el clúster y el canal de agentes son tan sensibles conviene mirar el despliegue típico. El maestro sincroniza reglas, decoders, listas y la configuración de los agentes hacia los nodos trabajadores y hacia cada endpoint, los agentes se conectan al puerto 1514, se enrolan en el 1515 y la API escucha en el 55000. Quien controla el maestro controla la detección y la flota entera.

A quién afecta

A cualquier organización con un Wazuh Manager en una versión anterior a la 4.14.8. El riesgo cambia según el despliegue. CVE-2026-74041 y CVE-2026-74034 afectan a instalaciones de un solo nodo, mientras que CVE-2026-74040 exige controlar un nodo trabajador del clúster. La sobrescritura de agent.conf convierte un problema del servidor en un problema de toda la flota, porque el código llega a cada agente, y pone en el punto de mira a la herramienta que precisamente debería vigilar esos equipos.

No hay un recuento de exposición específico de estos fallos en el momento de escribir esta noticia, el 17 de octubre de 2026, ni figuran en el catálogo KEV de CISA. Como referencia de cuántos servidores Wazuh llegan a quedar expuestos, Censys contó 17.329 servidores Wazuh accesibles desde Internet en junio de 2025, a raíz de otro fallo, CVE-2025-24016, incluido en el catálogo KEV de CISA y explotado entonces por botnets Mirai. El mapa de aquella medición muestra una concentración clara en Europa, con presencia en España.

El ángulo español va más allá del aviso de INCIBE-CERT. Wazuh nació en 2015 como un fork de OSSEC de la mano de Santiago Bassett, con raíces de desarrollo en Granada, y hoy es uno de los SIEM gratuitos más extendidos entre pymes, proveedores de servicios gestionados y equipos de seguridad del sector público en España. Esa adopción amplia es justo lo que amplía la superficie afectada.

Qué hacer

Las medidas las marcan el fabricante y el CERT nacional. Por orden de urgencia:

1. Actualizar el Manager a 4.14.8 o posterior. Las actualizaciones de Wazuh son acumulativas, así que esa versión trae las trece correcciones.
2. Comprobar qué versión corre cada despliegue antes y después de parchear, con el comando de información del servidor.
3. Si hay clúster, rotar la clave compartida del clúster y revisar los nodos trabajadores, porque CVE-2026-74040 y los saltos de ruta parten de un trabajador con esa clave.
4. Poner contraseña de enrolamiento y exigirla para quitar el escenario sin autenticar de CVE-2026-74034.
5. Revisar los roles de la API, quitar manager:update_config de los que no lo necesiten, auditar quién tiene cluster_admin e invalidar los tokens de usuarios run_as revocados.
6. Buscar en los registros ossec.log, cluster.log y api.log recargas de configuración no previstas, elementos LOG_FORMAT en mayúsculas en ossec.conf, órdenes upgrade_custom llegadas por el canal de agentes y sobrescrituras de ossec.conf o agent.conf.
7. Restringir en el firewall el acceso a los puertos 1514, 1515, 1516 y 55000 a las redes de confianza, y apoyarse en una buena rutina de respuesta a incidentes si aparece cualquier indicio.
8. Notificar a INCIBE-CERT (empresas y ciudadanos) o al CCN-CERT (sector público) si se confirma un compromiso.

Wazuh expone la versión instalada con la utilidad de control del servidor, útil para confirmar que el parche ha entrado:

/var/ossec/bin/wazuh-control info

Exigir una contraseña de enrolamiento cierra la puerta sin autenticar de CVE-2026-74034. En el bloque de enrolamiento de ossec.conf del Manager:

<auth>
  <use_password>yes</use_password>
  <purge>yes</purge>
  <use_source_ip>no</use_source_ip>
</auth>

Análisis

Lo incómodo de esta tanda es dónde están los fallos. Wazuh es la herramienta que vigila el resto de la infraestructura, corre con privilegios altos y toca cada endpoint de la flota. Cuando el que cae es el vigilante, caen con él la detección y la capacidad de respuesta, y el atacante hereda un punto de observación privilegiado. Las reglas de detección y los decoders que el maestro reparte dejan de ser una defensa si alguien puede reescribirlos.

El calendario también deja una lectura. El parche salió el 23 de septiembre y los avisos detallados, el 13 de octubre. Publicar primero la corrección y después los detalles es lo correcto, pero abre una ventana para quien no actualiza enseguida. En cuanto salieron los avisos y, al día siguiente, una prueba de concepto encadenada, cualquier Manager sin parchear quedó a tiro de un atacante que ya tenía el mapa.

Varios de estos fallos abusan de la confianza implícita entre piezas, entre maestro y trabajador o entre agente y Manager, el mismo patrón que venimos viendo en los dispositivos de borde con los zero-days de Ivanti Connect Secure. No es un fallo de memoria exótico, es un modelo de confianza demasiado generoso. La recomendación práctica es tratar el enrolamiento sin contraseña como lo que es, una comodidad peligrosa, y asumir que habrá escaneos oportunistas ahora que la PoC es pública.

Preguntas frecuentes

¿Me afecta si tengo un solo Manager y no un clúster?

Sí. CVE-2026-74041 y CVE-2026-74034 no necesitan clúster y se explotan contra una instalación de un solo nodo a través de la API y del canal de agentes. La que sí exige un clúster es CVE-2026-74040, porque parte de un nodo trabajador con la clave compartida. En cualquier caso, la respuesta es la misma, actualizar a 4.14.8.

¿La prueba de concepto funciona contra la versión 4.14.8?

No. La versión 4.14.8 corrige tanto CVE-2026-74034 como CVE-2026-74041, los dos eslabones de la cadena. La cadena, para colmo, depende de que el enrolamiento de agentes esté disponible sin contraseña, así que exigir una contraseña de enrolamiento rompe el primer paso aunque el parche aún no esté instalado. El autor dice haberla probado contra la 4.14.5, no contra una versión corregida.

¿Por qué el parche es del 23 de septiembre y los avisos del 13 de octubre?

Es divulgación coordinada. Wazuh publicó la corrección en la versión 4.14.8 y esperó varias semanas antes de difundir los detalles técnicos de cada fallo, para dar margen a actualizar. El efecto secundario es que la ventana peligrosa se abre al publicar los avisos, cuando los detalles y, enseguida, una prueba de concepto quedan al alcance de cualquiera.

¿Qué pasa si un atacante controla un nodo trabajador?

Con CVE-2026-74040 puede forzar al maestro a sobrescribir ossec.conf, lo que da ejecución como root en el servidor, y agent.conf, lo que empuja código a todos los agentes. También puede manipular reglas y listas con los saltos de ruta CVE-2026-74043 y CVE-2026-74033. Por eso el nodo trabajador y la clave del clúster merecen el mismo cuidado que el maestro, algo que repasamos en nuestra guía para implementar una estrategia SIEM.