- -

Árbol de páginas

Descripción

Una vulnerabilidad con CVSS 9.8 afecta a todas las versiones de Net-SNMP (Linux) anteriores a 5.9.5 y 5.10.pre2. La vulnerabilidad se encuentra en el servicio SnmpTrapd, que escucha por defecto en el puerto UDP 162. Debido a una validación incorrecta de la longitud de los datos proporcionados por el usuario antes de copiarlos en un búfer de pila de longitud fija, un paquete especialmente diseñado puede provocar que el demonio se bloquee o incluso permitir la ejecución remota de código sin necesidad de autenticación. (Fuente: https://www.vicarius.io/vsociety/vulnerabilities/cve-2025-68615)

Gravedad (15-Enero)

En estos momentos no se han emitido alertas por parte del CCN-CERT avisando de la vulnerabilidad. También los valores que indican peligrosidad están en un rango medio (a fecha de 15 de enero);

VPR = 7.4

EPSS = 0.00043  

Fuente; https://www.tenable.com/cve/CVE-2025-68615/

Estos valores los podemos interpretar como que la vulnerabilidad es peligrosa, pero su explotación en internet es muy baja. Esta interpretación es coherente con el hecho que el puerto y el servicio vulnerable (SNMP) rara vez se publica en internet (y no debería) y por lo tanto el valor EPSS no alcanzará el valor umbral para indicar que es una vulnerabilidad ampliamente explotada.

Sin embargo, y lo que sigue es una opinión personal, muchos dispositivos en vlanes privilegiadas se gestionan por SNMP, y dependiendo de si disponen de sistemas operativos completos, pueden no tener buenos procesos de actualización automática. Existe el riesgo de ataque dentro de la red interna. Por lo tanto es una vulnerabilidad a vigilar y resolver dentro de las vlanes más importantes de la organización.

Según nuestro procedimiento el plazo máximo de resolución de esta vulnerabilidad es de un mes (en equipos sin puertos abiertos a internet).

Permanezca atento, ya que esta situación puede cambiar.


Equipos afectados

Sistemas Linux o MacOs con la librería Net-SNMP y el demonio snmtrap escuchando en un puerto UDP (normalmente upd/162).


Versiones vulnerablesVersiones parcheadas
librería Net-SNMPTodas las anteriores

5.9.5

5.10.pre2

Sin embargo, las distribuciones Linux que realizan backporting, resuelven la vulnerabilidad en una versión diferente. Compruebe los boletines de seguridad de su distribución en concreto.

Debian

Fuente; https://security-tracker.debian.org/tracker/CVE-2025-68615 

RedHat Enterprise Linux

En la actualidad, sólo la versión Enterprise Linux 10 dispone de parche;



Versiones vulnerablesVersiones parcheadas
RedHat Enterprise Linux 10

net-snmp-5.9.4-15.el10_1.2


https://access.redhat.com/security/cve/cve-2025-68615#cve-affected-packages

https://access.redhat.com/errata/RHSA-2026:0668


Ubuntu

La vulnerabilidad puede estar presente en cualquiera de estas ediciones;

Recuerde que las versiones 20.04LTS e inferiores pueden contratar la suscripción "Ubuntu Pro" que les proporciona los parches oficiales para esta y otras vulnerabilidades.

Versiones corregidas:

https://ubuntu.com/security/notices/USN-7944-1 

https://ubuntu.com/security/CVE-2025-68615


Comprobar si tengo la vulnerabilidad

En esta página Vicarius ha publicado un script de detección y otro de mitigación https://www.vicarius.io/vsociety/vulnerabilities/cve-2025-68615 , sin embargo, tenga en cuenta que si su distribución usa backporting, no detectará correctamente las versiones parcheadas. Sin embargo, este script sigue siendo útil por otras comprobaciones que realiza.

Instrucciones para averiguar la versión de net-snmp:

snmptrapd -v
snmpget -V
/usr/sbin/snmptrapd -v
dpkg -l snmptrapd
rpm -q net-snmp


Comprobar  el estado del demonio:

systemctl is-active snmptrapd
systemctl is-enabled snmptrapd


Comprobar las reglas del firewall respecto el acceso al servicio SNMP (se asume el puerto udp/162)

iptables -L INPUT -n -v | grep -E 'udp'

firewall-cmd --list-rich-rules | grep -q "port.*162.*udp"

ufw status  | grep -qE "162/udp


Buenas prácticas

Seguir las recomendaciones de las buenas prácticas ayudan a resistir a ésta y a otras vulnerabilidades futuras.

  • NO publique el servicio SNMP directamente en internet. 
  • Restringa las subredes que tienen acceso a UDP/161 y UDP/162
    • sólo a subredes de gestión.
    • sólo a IPs de los puestos de trabajo que los administran.
  • Deshabilite las versiones SNMPv1 y SNMPv2. En su lugar, use únicamente SNMP v3 que es más seguro desde el diseño.
  • Implemente una buena gestión de usuarios y permisos.
    • No compartas el mismo usuario para distintos proyectos o personas.
    • Contraseñas largas y aleatorias, resistentes a ataques de fuerza bruta.
    • Deshabilita usuarios SNMP por defecto, sustitúyelos por otros nuevos.




  • Sin etiquetas