La alarma ha circulado con tono de “crítico” en listas y redes: un fallo en OpenSSL que permitiría tumbar servicios o incluso ejecutar código con un simple mensaje especialmente diseñado. Detrás del ruido, hay un hecho sólido: OpenSSL ha publicado un aviso de seguridad (27 de enero de 2026) que corrige varias vulnerabilidades, entre ellas CVE-2025-15467, catalogada por el proyecto como High (alta) por su potencial impacto en aplicaciones que procesan CMS/PKCS#7 —un estándar muy presente en S/MIME—.
Qué ocurre exactamente con CVE-2025-15467
Según el aviso oficial, el problema reside en el parsing de mensajes CMS AuthEnvelopedData cuando se usan cifrados AEAD (por ejemplo, AES-GCM). La vulnerabilidad se desencadena porque el IV (Initialization Vector) que viene codificado en los parámetros ASN.1 se copia a un buffer fijo en la pila sin comprobar su longitud. En un escenario malicioso, un atacante puede inflar ese IV y provocar un desbordamiento de pila (stack buffer overflow).
Dos detalles convierten este fallo en especialmente delicado:
- Ocurre antes de cualquier autenticación o verificación de tag, por lo que no hace falta material criptográfico válido para alcanzar el punto vulnerable.
- El impacto va desde Denial of Service (DoS) por caída del proceso hasta posible ejecución remota de código (RCE), condicionada por mitigaciones del sistema, compilador y protecciones de memoria.
En otras palabras: no es “un bug teórico”. Es una primitiva de escritura fuera de límites en la pila, y eso en seguridad rara vez se queda en anécdota.
¿Es “crítico” y tiene CVSS 9,8?
Aquí conviene separar la clasificación de OpenSSL de las puntuaciones de terceros. El proyecto lo marca como High, pero varias fuentes externas ya lo están tratando como riesgo crítico en sus sistemas de scoring (con cifras alrededor de 9,8 en CVSS v3 en algunos casos).
La matización importante es que, en el momento de publicación de estos avisos, la ficha de NVD para CVE-2025-15467 mostraba que NVD aún no había aportado su evaluación CVSS (aparece como “N/A” pendiente).
Esto no reduce el riesgo técnico, pero sí ayuda a entender por qué hay mensajes circulando con “estimaciones” o puntuaciones variables según el proveedor.
Quién está realmente expuesto: el matiz que cambia la historia
El fallo afecta a aplicaciones y servicios que parsean contenido CMS/PKCS#7 no confiable usando OpenSSL. En la práctica, el perímetro más típico incluye:
- S/MIME: clientes de correo, pasarelas de seguridad de email, servicios que inspeccionan o transforman mensajes.
- Sistemas que consumen CMS/PKCS#7 como formato de intercambio (firmas, envolturas, autenticación de objetos), especialmente si reciben entradas desde terceros.
- APIs internas que aceptan blobs CMS “porque vienen de un sistema externo”.
No significa que “todo TLS esté roto”: este CVE está en la implementación de CMS (mensajería criptográfica), no en el handshake TLS habitual. Aun así, para organizaciones con mucha automatización alrededor de correo, firma y flujos documentales, el vector es real.
Otro punto relevante para sectores regulados: el aviso remarca que los módulos FIPS de OpenSSL 3.x no se ven afectados porque la parte CMS está fuera del “boundary” del módulo FIPS.
Esto no equivale a “inmunidad total” (una aplicación puede usar OpenSSL con FIPS para unas cosas y CMS fuera de ese perímetro), pero sí aclara el alcance.
Versiones afectadas y versiones corregidas
OpenSSL indica que OpenSSL 3.6, 3.5, 3.4, 3.3 y 3.0 son vulnerables a CVE-2025-15467, mientras que 1.1.1 y 1.0.2 no lo son.
Las versiones a las que recomienda actualizar son:
- OpenSSL 3.6.1
- OpenSSL 3.5.5
- OpenSSL 3.4.4
- OpenSSL 3.3.6
- OpenSSL 3.0.19
En entornos Linux, lo normal es que la corrección llegue por paquetes del proveedor (backports incluidos), así que la recomendación práctica es seguir los avisos de seguridad de la distribución. Ubuntu, por ejemplo, publicó un aviso específico el mismo día del advisory, incluyendo CVE-2025-15467.
No solo CVE-2025-15467: otras correcciones del mismo aviso
El advisory del 27 de enero no se limita a CMS. Incluye, entre otras, una vulnerabilidad Moderate en PKCS#12 (CVE-2025-11187) por validación incorrecta de parámetros PBMAC1, con potencial de DoS y posibilidad de ejecución de código según mitigaciones, aunque requiere que una aplicación procese un archivo PKCS#12 malicioso.
También aparecen problemas de severidad baja, como un NULL dereference en un escenario poco común con QUIC (CVE-2025-15468) o un comportamiento peligroso del comando openssl dgst que puede truncar entradas de más de 16 MB sin avisar en algoritmos “one-shot”.
Además, el aviso se publicó “corregido” incorporando CVE-2026-22795 y CVE-2026-22796, ambos de severidad baja por confusión de tipos ASN.1 que acaban en DoS.
Qué deberían hacer los administradores hoy
La respuesta razonable es menos dramática que el “🚨” de algunos mensajes… pero igual de urgente:
- Inventariar dónde se usa OpenSSL 3.x y, sobre todo, dónde se parsea CMS/PKCS#7/S/MIME desde entradas no confiables.
- Actualizar por la vía del sistema (repositorios/boletines del proveedor) o, si se compila embebido, subir a las versiones corregidas.
- Revisar flujos donde se acepten PKCS#12 de terceros, aunque el riesgo ahí sea más contextual.
Preguntas frecuentes
¿Qué productos están más en riesgo con CVE-2025-15467?
Cualquier servicio o aplicación que procese CMS/PKCS#7 no confiable, especialmente flujos S/MIME (gateways de correo, análisis/archivado, transformación de mensajes), o APIs que acepten blobs CMS desde el exterior.
¿Hace falta autenticación o una clave válida para explotar el fallo?
El advisory indica que el desbordamiento ocurre antes de la autenticación/verificación, por lo que no se requiere material criptográfico válido para provocar el fallo.
¿Qué versiones de OpenSSL hay que actualizar para estar protegidos?
OpenSSL recomienda actualizar a 3.6.1, 3.5.5, 3.4.4, 3.3.6 o 3.0.19, según la rama en uso.
¿Es realmente un CVSS 9,8 “crítico”?
OpenSSL lo clasifica como High, mientras que algunos proveedores externos lo puntúan cerca de 9,8. En el momento del aviso, NVD aún mostraba la evaluación CVSS como pendiente (“N/A”).
Fuente: google seguridad
