CVE-2025-15467, el fallo de análisis de OpenSSL que convierte un CMS no fiable en un incidente real

Las vulnerabilidades de OpenSSL suelen desencadenar una alarma inmediata, y con razón. Cuando la biblioteca que está detrás de una gran parte de las comunicaciones cifradas envía un aviso de seguridad de alta gravedad, todos los equipos de seguridad saben que está a punto de ocurrir lo mismo: los escáneres se encienden, los cuadros de mando se llenan de rojo y las organizaciones se apresuran a determinar si se enfrentan a un ejercicio de aplicación de parches o a un incidente real.

CVE-2025-15467 merece esa atención, pero también precisión.

Esto no es una historia genérica de "todos los servicios TLS respaldados por OpenSSL son de repente explotables remotamente". CVE-2025-15467 es un desbordamiento de búfer de pila de alta gravedad en la lógica de análisis de CMS de OpenSSL, específicamente en el manejo de código maliciosamente diseñado AuthEnvelopedData con parámetros AEAD como AES-GCM. El aviso de OpenSSL dice que el fallo puede causar un bloqueo y potencialmente la ejecución remota de código. La descripción de NVD añade el detalle más importante desde el punto de vista operativo: el desbordamiento puede producirse antes de la autenticación o verificación de la etiqueta, lo que significa que no se requiere una clave válida para activar la ruta vulnerable. (NVD)

Ese detalle es exactamente por lo que esta vulnerabilidad importa. Es remota en flujos de trabajo realistas, pre-auth en la ruta del analizador que importa, y lo suficientemente grave como para que la puntuación CISA-ADP adjunta en NVD sea de 9,8. Al mismo tiempo, la exposición real depende de si sus sistemas realmente analizan contenido CMS, PKCS#7 o S/MIME no fiable. Si lo hacen, CVE-2025-15467 es una prioridad. Si no lo hacen, el panorama de riesgo cambia significativamente. (NVD)

Qué es realmente CVE-2025-15467

Según OpenSSL y NVD, CVE-2025-15467 es un desbordamiento de búfer basado en pila que se desencadena al analizar CMS AuthEnvelopedData que utilizan cifrados AEAD como AES-GCM. El comportamiento vulnerable proviene de copiar el IV codificado en parámetros ASN.1 en un búfer de pila de tamaño fijo sin confirmar que la longitud del IV se ajusta al destino. Un atacante que pueda suministrar un objeto CMS crafteado puede, por tanto, provocar una corrupción de memoria que conduzca a un fallo y, en las condiciones adecuadas, a una posible ejecución remota de código. (NVD)

El informe técnico de JFrog enfatiza la misma causa raíz en términos más directos de desarrollo de exploits: un IV sobredimensionado se copia en un búfer de pila de tamaño fijo, y el desbordamiento se produce antes de que cualquier comprobación de autenticación tenga éxito. Esto significa que el ataque no depende de tener claves válidas o de completar primero un intercambio criptográfico de confianza. Se basa en llegar al analizador. (Investigación sobre seguridad de JFrog)

Esta distinción es algo más que un matiz técnico. Es la diferencia entre un fallo criptográfico teórico y la exposición de un analizador sintáctico desencadenable externamente. El analizador sintáctico es la historia.

Versiones afectadas, versiones corregidas, y una no historia importante

OpenSSL publicó el aviso el 27 de enero de 2026. Las ramas afectadas son:

OpenSSL 1.1.1 y 1.0.2 no están afectados. OpenSSL también afirma que los módulos FIPS 3.x no están afectados porque la implementación de CMS está fuera del límite del módulo FIPS. (NVD)

Esa matriz de versiones es importante, pero la presencia de versiones por sí sola no basta para saber si tiene una crisis.

Node.js proporciona un ejemplo útil. Node se entrega con OpenSSL, pero la propia evaluación de seguridad de Node dice que CVE-2025-15467 no afecta a Node.js en ninguna rama porque Node.js no utiliza las API de CMS implicadas. Este es un recordatorio importante de que la presencia de dependencias y el alcance de vulnerabilidades no son lo mismo. (Node.js)

Por qué el riesgo es real, pero no universal

El análisis público más sólido de CVE-2025-15467 converge en el mismo encuadre. OpenSSL lo denomina desbordamiento de búfer de pila en el análisis sintáctico de CMS. NVD describe el fallo y la posible ejecución remota de código. Datadog lo caracteriza como un desbordamiento del búfer de la pila de preautenticación que afecta a OpenSSL 3.0, 3.3, 3.4, 3.5 y 3.6. JFrog lo califica de potencialmente crítico. Estos hechos apoyan la urgencia. (NVD)

Lo que no admiten es el pánico sin contexto.

El análisis de Datadog hace explícito el problema de la accesibilidad: esta vulnerabilidad es más importante para los entornos que analizan CMS que no son de confianza. AuthEnvelopedData, un patrón visto en el manejo de S/MIME y flujos de trabajo PKCS#7 relacionados. Si una aplicación utiliza OpenSSL sólo para los apretones de manos TLS ordinarios y nunca procesa datos CMS o PKCS#7 no fiables, es mucho menos probable que CVE-2025-15467 sea alcanzable en la práctica. El resumen del aviso de Red Hat dice lo mismo con otras palabras, señalando que el problema afecta a aplicaciones y servicios que analizan contenidos CMS o PKCS#7 no fiables utilizando cifrados AEAD. (securitylabs.datadoghq.com)

Esa es la verdad operativa fundamental. Las organizaciones con más probabilidades de tener una exposición significativa no son simplemente "las que ejecutan OpenSSL". Son las que utilizan las versiones de OpenSSL afectadas. y exponiendo flujos de trabajo de análisis de mensajes vulnerables a entradas no fiables.

Los entornos que deben moverse primero

Los objetivos de revisión más prioritarios son los sistemas que manejan contenedores criptográficos hostiles o semiconfiables. En la práctica, esto incluye a menudo pasarelas de correo con capacidad S/MIME, productos de seguridad para el correo electrónico, portales de importación de certificados, herramientas PKI y CA, plataformas de mensajería segura, canalización de documentos firmados o cifrados y productos de seguridad que envuelven las API CMS de OpenSSL tras una interfaz de alto nivel. (securitylabs.datadoghq.com)

La razón por la que estos sistemas son importantes es simple. Ellos ingieren los tipos exactos de objetos que pueden conducir a la ruta de análisis vulnerable. Un sitio HTTPS genérico respaldado por OpenSSL no es el primer lugar donde buscar. Una pasarela de seguridad de correo o un servicio de procesamiento de certificados sí lo son.

Por eso, los equipos de seguridad que traten CVE-2025-15467 como un evento genérico de actualización de bibliotecas perderán el tiempo. El mejor uso del tiempo es responder a una pregunta más concreta: ¿en qué parte del entorno puede un atacante hacer que la aplicación analice datos no fiables de la familia CMS?

Qué aporta el análisis técnico público

El escrito de JFrog es útil porque señala funciones concretas asociadas a la lógica vulnerable, entre ellas CMS_descifrar, PKCS7_descifrar, CMS_RecipientInfo_decrypt, CMS_Datos_descifradosy EVP_CIPHER_asn1_to_param. Para la revisión interna del código, eso es importante. Proporciona a los equipos de ingeniería y seguridad de aplicaciones símbolos específicos en los que buscar, en lugar de obligarles a empezar con un linaje abstracto de bibliotecas. (Investigación sobre seguridad de JFrog)

El informe de Datadog es útil por la razón contraria. No se limita a discutir el fallo desde el punto de vista técnico, sino que enmarca la respuesta desde el punto de vista operativo. Destaca el riesgo para los sistemas que analizan contenidos CMS o de la familia PKCS#12 que no son de confianza y recuerda a los defensores que los ecosistemas con tiempos de ejecución incluidos o paquetes personalizados pueden requerir una inspección más allá de los gestores de paquetes del sistema operativo. (securitylabs.datadoghq.com)

En conjunto, esas perspectivas dan a los defensores el modelo correcto. Buscar las versiones vulnerables, pero verificar la accesibilidad del analizador. Buscar en el código fuente las API relevantes, pero validar la exposición externa. Tratar el fallo como grave, pero no exagerar sus implicaciones para los sistemas que nunca se acercan a las rutas relevantes del CMS. (securitylabs.datadoghq.com)

Un modelo práctico de triaje de la exposición

Un buen plan de respuesta para CVE-2025-15467 empieza por separar la presencia de paquetes de la superficie de ataque alcanzable.

Este tipo de matriz coincide con las pruebas públicas. También es la forma más rápida de evitar tanto las reacciones insuficientes como los simulacros de incendio innecesarios. (securitylabs.datadoghq.com)

¿Significa esto que la ejecución remota de código es fácil

Ningún defensor serio debería responder a eso con un sí rotundo o con un no rotundo.

El registro público apoya claramente la posibilidad de ejecución remota de código. OpenSSL dice "potencialmente ejecución remota de código". NVD repite ese resultado. JFrog explícitamente enmarca el problema como potencialmente crítico porque el fallo es un desbordamiento de pila pre-auth en una biblioteca criptográfica ampliamente desplegada. (NVD)

Al mismo tiempo, la explotabilidad sigue dependiendo del entorno de destino, la compilación y la configuración de endurecimiento, el comportamiento del proceso, las mitigaciones circundantes y si la ruta vulnerable del analizador está realmente expuesta a la entrada no fiable. El marco de Datadog es útil en este caso porque mantiene la conversación en la base: una amplia denegación de servicio es la expectativa de caso común más defendible, mientras que la ejecución de código sigue siendo una posibilidad grave pero dependiente de las condiciones. (securitylabs.datadoghq.com)

Esa es la postura correcta. Los equipos deberían tratar CVE-2025-15467 como lo suficientemente peligroso como para parchearlo urgentemente cuando sea posible, sin pretender que cada instancia de paquete vulnerable se traduzca en un RCE a escala de Internet sin esfuerzo.

El panorama general de OpenSSL en enero de 2026

CVE-2025-15467 llegó como parte de una versión de seguridad de OpenSSL más amplia de enero de 2026. Datadog señala que el mismo ciclo de actualización también incluía CVE-2025-11187un problema de gravedad moderada relacionado con la validación incorrecta de los parámetros PBMAC1 durante la verificación MAC PKCS#12, junto con otros problemas de menor gravedad. La evaluación de Node de enero de 2026 también hace referencia a CVE-2025-15468aunque dice que Node tampoco se ve afectado por ese problema. (securitylabs.datadoghq.com)

Ese contexto es importante porque sugiere una lección más amplia: la lógica del analizador sintáctico y la gestión de contenedores sigue siendo un límite de seguridad recurrente en las bibliotecas criptográficas. Las organizaciones que solo hacen inventario de los puntos finales TLS pero no hacen inventario de la gestión de certificados, el análisis sintáctico de mensajes, la ingestión segura de correo o los flujos de trabajo de contenedores criptográficos es probable que repitan el mismo punto ciego en el próximo ciclo de divulgación.

Cómo validar su entorno rápidamente

El primer paso sigue siendo el descubrimiento de versiones.

openssl versión -a

# Debian o Ubuntu
dpkg -l | grep -E 'openssl|libssl'

# RHEL, Rocky, Alma, CentOS
rpm -qa | grep -E '^openssl|^openssl-libs|^libssl'

# Alpine
apk info | grep -E 'openssl|libssl'

En el caso de los contenedores, no confíe en que el inventario del host le cuente toda la historia.

docker run --rm tu-nombre-de-imagen sh -c '
  openssl version -a 2>/dev/null || true
  find / -type f \( -name "libssl*.so*" -o -name "libcrypto*.so*" \\) 2>/dev/null
'

Si tiene acceso a las bibliotecas fuente o wrapper, busque el uso directo de la API relacionado con CMS y el descifrado PKCS#7 o el análisis sintáctico de parámetros.

grep -RInE 'CMS_decrypt|PKCS7_decrypt|CMS_RecipientInfo_decrypt|CMS_EnvelopedData_decrypt|EVP_CIPHER_asn1_to_param' .

Estas comprobaciones no bastan por sí solas, pero son rápidas y útiles. El siguiente paso es asignar esos resultados a productos que acepten contenido S/MIME suministrado externamente, archivos CMS, blobs PKCS#7, material de certificado importado o contenedores de documentos cifrados. Ahí es donde reside la verdadera exposición. (securitylabs.datadoghq.com)

Detección durante la ventana de parcheo

CVE-2025-15467 no es el tipo de fallo que garantiza firmas IDS elegantes. En muchos entornos reales, los indicadores más prácticos son de comportamiento: caídas inesperadas, reinicios repetidos del servicio, volcados de núcleo que implican... libcryptofallos en el procesamiento de mensajes de la pasarela de correo o comportamiento errático repentino de los servicios de importación de certificados. (NVD)

Un punto de partida ligero al estilo Sigma para la telemetría orientada a los accidentes podría tener este aspecto:

título: Posible patrón de fallo en el análisis de CMS de OpenSSL
id: 7b36c2c7-0b7f-4ccf-9d59-cve-2025-15467
estado: experimental
logsource:
  producto: linux
  categoría: process_creation
detección:
  selection_proc:
    Image|endswith:
      - '/systemd-coredump'
      - /coredumpctl
  selection_related:
    CommandLine|contiene:
      - openssl
      - libcrypto
      - smime
      - pkcs7
      - cms
      - correo
      - pasarela
  condición: selection_proc y selection_related
nivel: medio
falsos positivos:
  - triaje rutinario de fallos
  - investigación coredump no relacionada

Esta regla es intencionadamente amplia. Lo mejor es enriquecer las señales de fallo con el contexto de los activos. Si un servicio que falla es una pasarela de seguridad de correo, un componente de importación de certificados o un flujo de trabajo orientado a PKI que analiza contenido criptográfico no fiable, merece una investigación inmediata.

Prioridades de corrección

La principal solución es simple: actualice a la versión parcheada de OpenSSL para su rama. Esto significa 3.0.19, 3.3.6, 3.4.4, 3.5.5, o 3.6.1. (NVD)

Si no es posible aplicar parches inmediatamente, reduzca la exposición del analizador mientras esté abierta la ventana de parches. Esto puede significar restringir temporalmente la importación de certificados externos, limitar los flujos de trabajo de procesamiento de mensajes, añadir un control más estricto a la ingestión de S/MIME o CMS y aislar los servicios que consumen contenedores criptográficos de usuarios o redes asociadas que no sean de confianza. Estas medidas no sustituyen a la aplicación de parches, pero son controles provisionales significativos. (securitylabs.datadoghq.com)

Igual de importante es verificar dónde está empaquetado OpenSSL. Algunos productos enlazan con la biblioteca del sistema. Otros incluyen su propia copia. Algunos tiempos de ejecución incluyen OpenSSL pero no utilizan las API vulnerables. Un plan de parches que asuma que los tres casos se comportan igual dejará puntos ciegos. (securitylabs.datadoghq.com)

Dónde puede ser útil Penligent

Una vulnerabilidad como CVE-2025-15467 expone una debilidad recurrente en la respuesta de las empresas: los equipos normalmente pueden encontrar la versión más rápido de lo que pueden demostrar la accesibilidad.

Ahí es donde resulta útil la validación asistida por IA. Para esta clase de problemas, el valor no está en reclamar una cobertura mágica de exploits. El valor está en identificar los activos expuestos, descubrir las superficies de carga y análisis, mapear los flujos de trabajo de gestión de certificados, validar si las rutas de análisis de mensajes son accesibles desde los límites de confianza reales, y convertirlo en evidencia sobre la que un equipo de seguridad pueda actuar.

Para las organizaciones que gestionan grandes patrimonios mixtos, esa distinción es importante. "OpenSSL presente" es un resultado de inventario. "La ruta de análisis CMS no fiable es accesible externamente en este servicio y este flujo de trabajo" es un resultado de corrección.

Lo realmente importante

CVE-2025-15467 es uno de los ejemplos recientes más claros de por qué los defensores deben pensar en términos de exposición del analizador, no sólo en la presencia del paquete.

Sí, es una vulnerabilidad de OpenSSL de alta gravedad. Sí, puede causar denegación de servicio y potencialmente ejecución remota de código. Sí, el problema es pre-auth en la ruta de análisis relevante, y sí, afecta a múltiples ramas actuales de OpenSSL 3.x. (NVD)

Pero el riesgo real no está distribuido uniformemente en cada despliegue de OpenSSL. El trabajo de respuesta de mayor valor consiste en identificar dónde llegan datos CMS, PKCS#7 o S/MIME no fiables a una lógica de análisis vulnerable. En esos entornos, la aplicación de parches debería ser urgente. En el resto, la aplicación de parches sigue siendo necesaria, pero el pánico no sustituye al análisis.

La conclusión correcta es simple: CVE-2025-15467 debe tratarse como un problema grave de exposición al análisis de mensajes de OpenSSL, no como un pánico genérico de TLS. Ese encuadre es más preciso, más procesable y más útil para los ingenieros que realmente tienen que reducir el riesgo. (NVD)

Para saber más

• Aviso de seguridad de OpenSSL, 27 de enero de 2026. (NVD)
• Entrada NVD para CVE-2025-15467. (NVD)
• Análisis de Datadog Security Labs de la actualización de OpenSSL de enero de 2026. (securitylabs.datadoghq.com)
• Evaluación de seguridad de Node.js para las correcciones de OpenSSL de enero de 2026. (Node.js)
• JFrog análisis técnico de CVE-2025-15467. (Investigación sobre seguridad de JFrog)
• Resumen del aviso de Red Hat para CVE-2025-15467. (Portal del cliente de Red Hat)
• Penligente, CVE-2025-15467, el fallo de OpenSSL que sólo importa cuando la ruta de análisis del mensaje es real. (Penligente)