Netdata ha publicado la versión 2.12.2 de su Agente de monitorización, y el motivo no es cosmético. El propio estado de servicio de Netdata reveló el 23 de octubre una vulnerabilidad que permite a quien tenga acceso al puerto web del Agente (el 19999 de toda la vida) ejecutar comandos arbitrarios como el usuario netdata. La 2.12.2 corrige el fallo, y Netdata recomienda además limitar el acceso a ese puerto: enlazarlo solo a localhost, exigir un token de autenticación (bearer token), o desactivarlo del todo si no lo necesitas expuesto. Los Agentes padre que reciben streaming de Agentes hijo siguen necesitando el puerto disponible, pero pueden restringirlo con listas de acceso.

Si en algún momento expusiste el puerto 19999 a internet — por comodidad, por una regla de firewall que se quedó abierta, por NAT en el router — esta es la actualización que no conviene posponer.

El resto del parche endurece varias cosas que no dependían de ese fallo concreto: las peticiones SNMPv3 que se saltan la autenticación cuando el usuario la exige ya se rechazan y se contabilizan como fallo; las contraseñas SNMP han dejado de aparecer en los logs de depuración; y las peticiones a funciones y configuración dinámica ahora exigen JSON estricto (RFC 8259), lo que evita que una petición malformada se cuele como si fuera un comando. También hay correcciones de estabilidad: un plugin externo que antes se desactivaba para siempre tras un error de protocolo ahora se reinicia solo, y los charts y alertas de un objeto de Kubernetes ya no desaparecen si se borra otro objeto con un nombre parecido (por ejemplo, borrar web-1 dejaba de forma incorrecta sin alertas a web-10).

Qué significa para ti

Si tienes Netdata corriendo en tu homelab, actualiza a la 2.12.2 y, aproveches o no el fallo para algo crítico, repasa cómo expones el puerto 19999: lo más simple es dejarlo solo en tu red interna (o detrás de tu VPN/tailnet) y no en absoluto accesible desde internet. Si administras varios Agentes con SNMP, el endurecimiento de la autenticación también te afecta: un dispositivo que dependiera de que Netdata aceptara mensajes SNMPv3 sin autenticar dejará de funcionar hasta que lo configures correctamente — lo cual, en la práctica, es lo que debería haber pasado desde el principio.

Fuentes: status.netdata.cloud · github.com