OpenSSL corrige CVE-2026-45447: un fallo en PKCS#7 que puede acabar en crash, corrupción de memoria y algo peor

Hay vulnerabilidades que suenan rutinarias hasta que uno lee la letra pequeña. Esta es una de ellas. CVE-2026-45447, publicada el 9 de junio de 2026 y todavía “awaiting enrichment” en la NVD, describe un use-after-free en OpenSSL durante la verificación de firmas PKCS#7. Traducido al castellano útil: un mensaje S/MIME o PKCS#7 especialmente manipulado puede provocar que la aplicación libere indebidamente un BIO que no debía tocar, y el siguiente acceso a ese objeto ya liberado abre la puerta a caída del proceso, corrupción de memoria y, en determinados contextos, ejecución remota de código.

No, no es “otro CVE más” en una librería ubicua. OpenSSL sigue enterrado en una cantidad indecente de productos, pasarelas de correo, appliances, herramientas de firma, middleware empresarial y desarrollos internos que nadie recuerda haber tocado desde hace años. Y este fallo tiene una característica incómoda: no afecta al cifrado TLS que todo el mundo vigila, sino a una ruta menos visible, la de procesamiento de mensajes firmados PKCS#7 o S/MIME. Justo el tipo de superficie que muchas organizaciones usan, pocas monitorizan y demasiadas asumen que “siempre ha funcionado”. Mala combinación.

La propia descripción del registro es bastante explícita. Si el campo SignedData.digestAlgorithms está presente como un conjunto ASN.1 vacío, OpenSSL puede liberar incorrectamente un BIO propiedad de la aplicación que llama a PKCS7_verify(). Cuando esa aplicación vuelve a usar el BIO, o simplemente hace el BIO_free() que habría hecho de todos modos, aparece la condición de use-after-free. La NVD no ha publicado todavía puntuación propia, pero CISA-ADP ya le asigna un CVSS v3.1 de 8.8, alto, con vector AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H. Y ahí hay una pequeña historia interesante: el 9 de junio apareció primero con PR:N, y el 10 de junio CISA-ADP corrigió el vector a PR:L. No es un detalle cosmético. Cambia la lectura de riesgo y evita que medio mercado corra a gritar “RCE trivial sin privilegios” cuando el escenario es más matizado.

Conviene separar lo serio de lo melodramático. La explotación no significa automáticamente internet en llamas. Pero tampoco es un fallo para archivar bajo “ya lo meteremos en el siguiente ciclo de parcheo”. Si tu software procesa mensajes S/MIME o PKCS#7 usando las APIs PKCS#7 de OpenSSL, estás en el grupo que tiene trabajo esta semana. Si usas las APIs CMS para ese mismo procesamiento, la propia nota dice que no estás afectado. Y si alguien en tu organización responde “creo que usamos eso, pero tendría que preguntarlo”, ya tienes un indicador bastante fiable de que el inventario de dependencias no es tan bueno como decía el último comité.

Qué se sabe exactamente y por qué esta vulnerabilidad no es una simple nota técnica

El núcleo del problema está bien delimitado por OpenSSL. La condición vulnerable aparece al procesar un mensaje firmado PKCS#7 o S/MIME en el que el campo digestAlgorithms dentro de SignedData llega como un ASN.1 SET vacío. En ese escenario, durante la llamada a PKCS7_verify(), OpenSSL puede liberar incorrectamente un BIO que pertenece al llamador. No estamos ante un desbordamiento nebuloso descrito en términos vagos; hay una secuencia funcional concreta, una API concreta y un tipo de entrada maliciosa claramente identificada.

La pieza técnica relevante aquí no es solo el use-after-free, clasificado como CWE-416, sino dónde ocurre. PKCS#7 y S/MIME no son un subsistema marginal en muchos entornos corporativos. Se utilizan para firma de correo, intercambio documental, flujos de validación criptográfica en backends, componentes de firma en banca y seguros, y pasarelas que inspeccionan o verifican mensajes firmados antes de entregarlos a otros sistemas. En otras palabras: no necesitas que el atacante tenga shell previa ni acceso físico. Necesitas que consiga que una aplicación vulnerable procese un mensaje especialmente construido.

La descripción de impacto de OpenSSL evita vender humo, y hace bien. Habla de process crashes, corrupción de heap y “potencialmente” ejecución remota de código. Esa cautela importa. En vulnerabilidades de memoria, la diferencia entre caída reproducible y RCE útil depende de demasiados factores como para prometer fuegos artificiales desde el minuto uno: comportamiento del asignador de memoria, patrón de uso del BIO por la aplicación, endurecimientos del binario, arquitectura, protecciones del sistema operativo y, sobre todo, cómo integra cada producto las APIs afectadas.

La consecuencia operativa es bastante más incómoda que el titular simple de “OpenSSL vulnerable”. Dos productos con la misma versión de OpenSSL pueden tener exposiciones muy distintas si uno usa las APIs CMS y el otro las viejas APIs PKCS#7. Dos aplicaciones que llaman a PKCS7_verify() también pueden divergir si una encapsula el BIO de una forma que convierte el bug en crash inmediato y otra lo reutiliza en una secuencia que permite corrupción más interesante para un atacante. Dicho sin solemnidad: el nombre del paquete no basta. Hay que mirar el código o, como mínimo, la documentación del proveedor.

Otro dato que merece atención: los módulos FIPS de OpenSSL 4.0, 3.6, 3.5, 3.4 y 3.0 no están afectados porque el código vulnerable queda fuera del perímetro del módulo FIPS. Eso no significa que “si tengo FIPS estoy a salvo”. Significa algo mucho menos reconfortante: la parte certificada no es la parte vulnerable, pero la aplicación puede seguir usando fuera de ese límite exactamente la ruta donde vive el problema. Es un buen recordatorio de un malentendido recurrente en entornos regulados: conformidad criptográfica no equivale a seguridad integral de implementación.

El matiz que cambia la historia: PKCS#7 sí, CMS no

La frase más importante de toda la publicación probablemente sea esta: “Applications using the CMS APIs for this processing are not affected.” Si trabajas en gestión de vulnerabilidades, ya sabes lo que viene después: el problema deja de ser “dónde tengo OpenSSL” y pasa a ser “dónde tengo OpenSSL usando exactamente esa familia de APIs”. Esa diferencia reduce falsos positivos, pero complica enormemente la respuesta porque obliga a inventariar uso real, no solo presencia del componente.

PKCS#7 y CMS están emparentados, pero no son lo mismo. CMS, definido por RFC 5652 como evolución de PKCS#7, lleva años siendo la vía preferible en muchas implementaciones modernas. Aun así, en productos heredados, librerías encapsuladas y aplicaciones internas hechas hace una década, las APIs PKCS#7 siguen apareciendo con más frecuencia de la que muchos equipos querrían admitir. Y aquí asoma el clásico pecado corporativo: migraciones técnicas que se posponen porque “funciona”, hasta que un CVE recuerda que el coste de no tocar nada también existe.

Para los equipos de desarrollo, este matiz sugiere una prioridad doble. La primera es parchear. La segunda, bastante menos vistosa pero más inteligente, es revisar si todavía hay dependencia funcional de APIs PKCS#7 donde ya sería razonable migrar a CMS. No porque CMS sea mágicamente inmune a todo, sino porque el incidente confirma algo muy terrenal: las rutas heredadas suelen concentrar deuda técnica, menos pruebas y menos ojos encima.

Para equipos de seguridad ofensiva y defensiva, el detalle del ASN.1 SET vacío tampoco es trivial. Los fallos de parsing ASN.1 llevan décadas siendo terreno fértil porque combinan estructuras complejas, compatibilidad histórica y cantidades generosas de código legado en C. Si tu cadena de correo seguro, archivado o validación documental acepta S/MIME firmado y delega parsing y verificación a componentes basados en OpenSSL, la prueba útil no es “¿tengo OpenSSL instalado?”, sino “¿puedo forzar este flujo con un mensaje firmado especialmente construido y observar crash o corrupción?”. Son dos preguntas muy distintas, y la segunda es la única que acerca a una evaluación de riesgo real.

La puntuación CVSS dice 8.8, pero lo verdaderamente útil está en el cambio de PR:N a PR:L

La NVD aún no había publicado su propia evaluación cuando se difundió el registro, así que la referencia práctica inicial viene de CISA-ADP: CVSS 8.8 alto. Hasta aquí, lo esperable. Lo menos trivial está en el historial de cambios. El 9 de junio de 2026 se añadió un vector AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H. El 10 de junio de 2026, CISA-ADP retiró ese vector y lo sustituyó por AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H.

¿Por qué importa? Porque pasar de PR:N a PR:L cambia de forma sustancial cómo una organización prioriza el parche. PR:N sugiere un ataque explotable sin privilegios previos en la aplicación objetivo. PR:L introduce la idea de que el atacante necesita una condición de acceso o capacidad previa que no está al alcance de cualquiera. En este caso concreto, esa corrección parece alinearse mejor con la descripción: no hablamos de un demonio genérico expuesto a internet sin contexto, sino de aplicaciones que procesan mensajes firmados mediante APIs específicas.

Esto no reduce la urgencia para quienes sí tienen ese flujo. Lo que reduce es el ruido. Y se agradece, porque cada vez que aparece un “OpenSSL + potencial RCE”, la industria entra en un pequeño reflejo condicionado entre pánico y teatro. El ajuste de CISA-ADP ayuda a centrar el debate donde toca: exposición funcional, alcance real de integración y capacidad del atacante para introducir mensajes maliciosos en el flujo de verificación.

Si gestionas riesgo tecnológico en una entidad grande, esta corrección también sirve como advertencia metodológica. Automatizar priorización de parches solo con CVSS y nombre del producto ya era una mala costumbre antes; con un caso así, roza la negligencia operacional. Una librería ubicua, una API concreta, una condición de parsing específica y un vector corregido al día siguiente: eso exige triage humano. No una hoja Excel que colorea celdas.

Qué productos y entornos deberían preocuparse de verdad

La respuesta corta: cualquier aplicación, servicio o producto que procese mensajes PKCS#7 o S/MIME firmados usando OpenSSL y, en concreto, sus APIs PKCS#7. La respuesta útil es más incómoda porque obliga a mirar debajo del capó.

Primero, clientes y pasarelas de correo que validen S/MIME. Si el software verifica firmas al recibir o inspeccionar mensajes, entra automáticamente en la lista de revisión. No basta con revisar el cliente final; también hay que mirar gateways de seguridad de correo, archivadores, DLP, soluciones de e-discovery y motores de sandboxing documental si extraen y validan firmas.

Segundo, plataformas de firma y validación documental. Muchos flujos empresariales, incluidos procesos de contratación, certificación, mensajería segura B2B o intercambio con administraciones y terceros regulados, manejan contenedores PKCS#7 o estructuras relacionadas. A veces el componente vulnerable no está en la capa visible del negocio, sino en un microservicio de validación o en una librería compartida que nadie ha inventariado correctamente.

Tercero, appliances y productos OEM. Este suele ser el ángulo más ingrato. OpenSSL aparece embebido en firmware, productos de terceros y soluciones empaquetadas donde el cliente no compila nada ni ve el código. Ahí la prioridad no es tanto “parchear OpenSSL” como obtener declaración de impacto del proveedor, versión corregida y, mientras tanto, mitigaciones funcionales. Si tu cadena de dependencia pasa por un fabricante que tarda semanas en reconocer el problema, el reloj no se detiene por cortesía.

Cuarto, desarrollos internos viejos. Los proyectos que usan bibliotecas criptográficas desde C o C++ directo, o a través de wrappers antiguos, tienden a esconder este tipo de exposición. Si el equipo original ya no existe, el repositorio no tiene pruebas decentes y la documentación es arqueología, estás justo en el terreno donde un fallo de memoria se convierte en incidente operativo antes de convertirse en ticket cerrado.

En cambio, si tu uso de OpenSSL se limita a TLS, certificados X.509 básicos o funciones ajenas a la verificación PKCS#7 mediante esas APIs, no conviene inflar el problema. Hay superficie afectada real, pero no universal. La disciplina aquí consiste en discriminar, no dramatizar.

Qué deben hacer ahora los equipos de seguridad, desarrollo y terceros

La reacción sensata no empieza por lanzar un parche ciego en toda la organización. Empieza por una pregunta muy concreta: ¿dónde llamamos a PKCS7_verify() o consumimos un producto que pueda hacerlo por nosotros? Si tienes acceso al código, la búsqueda es directa. Si no lo tienes, toca preguntar a proveedores con una redacción menos vaga de lo habitual. No “¿están afectados por la vulnerabilidad de OpenSSL?”. Mejor: “¿Su producto procesa mensajes S/MIME o PKCS#7 mediante APIs PKCS#7 de OpenSSL, incluida la ruta de verificación equivalente a PKCS7_verify()? ¿Qué versiones están afectadas y qué versión corrige el problema?”

El segundo paso es identificar si existe exposición remota real. Una aplicación vulnerable en una estación aislada no merece la misma prioridad que un gateway de correo, una API pública de validación documental o una plataforma multiusuario donde terceros puedan entregar mensajes firmados. Aquí el vector de ataque manda más que la librería.

El tercero es probar, no asumir. Donde el flujo sea crítico, tiene sentido validar en un entorno controlado si un artefacto malformado provoca crash, doble liberación o comportamiento anómalo. No para “hacer exploit”, sino para confirmar impacto operativo y ajustar urgencia. Cuando el fallo depende de patrones de uso del llamador, la prueba local vale más que diez diapositivas de clasificación genérica.

El cuarto es revisar medidas de contención mientras llega o se despliega el parche. Si un producto permite deshabilitar temporalmente verificación S/MIME en una ruta no esencial, o segregar el servicio vulnerable detrás de controles de entrada más estrictos, puede ser una decisión razonable. No siempre será viable. Y no, “apagar funcionalidades de firma” no es precisamente elegante. Pero a veces la elegancia llega después del incidente.

El quinto es mirar el ecosistema de terceros con seriedad. DORA ha repetido hasta la saciedad la necesidad de gobernanza sobre proveedores TIC; esta es la parte donde deja de sonar a seminario y se vuelve operacional. Si dependes de software de terceros para correo, firma o middleware criptográfico, necesitas trazabilidad de componentes, ventanas de remediación y cláusulas de notificación que sirvan para algo más que decorar el contrato.

Lo que este CVE enseña sobre gestión de dependencias: el problema no es OpenSSL, es no saber cómo lo usas

La industria sigue atrapada en una mala costumbre: confundir presencia de un componente con exposición a una vulnerabilidad. CVE-2026-45447 es un ejemplo perfecto de por qué esa simplificación sale cara. OpenSSL está en todas partes, sí. Pero este fallo no afecta a “todo OpenSSL”. Afecta a un uso concreto, mediante APIs concretas, con un tipo de entrada concreta. Si tu inventario no distingue entre biblioteca instalada y función realmente invocada, vas a tener dos fallos a la vez: sobrepriorizar sistemas irrelevantes y pasar por alto los que sí importan.

Esto conecta de lleno con el debate sobre SBOM y VEX. Una SBOM te puede decir que un producto incluye OpenSSL. Útil, pero insuficiente. Lo que realmente necesitas ante una CVE así es una declaración de explotabilidad o no afectación basada en contexto de uso: ¿el producto usa PKCS#7 APIs? ¿expone verificación de S/MIME? ¿está alcanzable por datos de terceros? Sin esa capa, muchas organizaciones convierten la gestión de vulnerabilidades en un ejercicio de volumetría. Mucho inventario, poca certeza.

También hay una lección para desarrollo seguro. Las APIs de memoria manual en C siguen generando problemas de propiedad de objetos y ciclo de vida, especialmente cuando el contrato entre biblioteca y llamador no está blindado contra casos borde. Un BIO “caller-owned” que la biblioteca acaba liberando indebidamente es precisamente ese tipo de error donde documentación, convenciones y pruebas negativas importan tanto como el parche final. Si tu organización mantiene código nativo, este CVE debería servir como recordatorio incómodo para revisar tests alrededor de ownership y liberación de recursos en rutas de error o formatos malformados.

Implicaciones regulatorias para Europa: DORA, NIS2 y el viejo problema de enterarse tarde

Aunque la vulnerabilidad no nazca en Bruselas, sus consecuencias sí pueden acabar en el despacho de compliance. Para entidades financieras europeas, DORA no obliga a parchear este CVE por nombre propio, claro. Obliga a algo más molesto: demostrar que existe un marco de gestión del riesgo TIC capaz de identificar componentes afectados, clasificar el impacto, aplicar remediación y escalar incidentes cuando proceda.

El Reglamento (UE) 2022/2554, DORA, es especialmente claro en varios puntos. El artículo 8 exige marcos de gestión del riesgo TIC sólidos y documentados. El artículo 10 se centra en la identificación, clasificación y documentación de funciones, activos y dependencias TIC. El artículo 11 exige protección y prevención. El artículo 17 aborda la gestión, clasificación e informe de incidentes relacionados con las TIC. Y el artículo 28 pone el foco en el riesgo asociado a terceros proveedores de servicios TIC. Si una entidad no sabe si un proveedor de correo seguro o firma digital usa la ruta vulnerable de OpenSSL, no tiene un problema “técnico”. Tiene un problema de gobernanza de dependencias que DORA lleva meses advirtiendo.

NIS2 cuenta una historia similar para operadores y entidades esenciales o importantes fuera del perímetro estrictamente financiero. El artículo 21 de la Directiva (UE) 2022/2555 exige medidas técnicas, operativas y organizativas apropiadas para gestionar riesgos de seguridad de redes y sistemas de información. Entre ellas aparecen expresamente la gestión de incidentes, la continuidad, la seguridad en la cadena de suministro y la seguridad en adquisición, desarrollo y mantenimiento de redes y sistemas. Una librería criptográfica ubicua con una vulnerabilidad de memoria en una función de verificación de mensajes es casi un caso de manual para esas obligaciones.

¿Y el GDPR? Solo entra si el fallo desemboca en una brecha de datos personales. Si una explotación efectiva comprometiera confidencialidad, integridad o disponibilidad de datos personales, el artículo 33 del Reglamento (UE) 2016/679 activaría el plazo de notificación a la autoridad de control en 72 horas desde que el responsable tiene constancia, salvo que sea improbable que la brecha entrañe un riesgo para los derechos y libertades de las personas físicas. No conviene mezclar marcos porque sí, pero tampoco olvidar que una vulnerabilidad técnica en un gateway de correo firmado puede terminar en terreno de protección de datos muy deprisa.

La parte irónica, si se quiere, es que los marcos regulatorios llevan años insistiendo en inventario, dependencias y terceros, y aun así muchas organizaciones siguen sin poder responder una pregunta básica en menos de 24 horas: “¿Dónde usamos esta función vulnerable y qué proveedor nos expone a ella?”. Luego llega la auditoría, todos descubren el valor del mapa de activos y fingimos que la lección era nueva.

Para entidades financieras españolas, el riesgo no está en el titular sino en los flujos de mensajería y firma

En España, bancos, aseguradoras, gestoras, fintechs y proveedores críticos de servicios financieros usan desde hace años mensajería firmada, intercambio documental certificado y componentes de validación criptográfica en procesos internos y con terceros. No todos usan S/MIME de forma intensiva, pero bastan unos cuantos flujos bien escogidos para que un fallo como este tenga relevancia operativa.

Piensa en tres escenarios. El primero: plataformas de correo corporativo o pasarelas que verifican firmas S/MIME en comunicaciones con clientes institucionales, despachos, proveedores o administraciones. El segundo: motores de validación documental en onboarding, formalización contractual o intercambio B2B. El tercero: software de terceros incrustado en servicios de back-office donde la entidad no controla directamente la integración con OpenSSL. En los tres casos, el verdadero riesgo es la combinación de exposición de entrada, dependencia de proveedor y baja visibilidad técnica.

Si además la entidad está en pleno esfuerzo de alineación con DORA, este CVE es una prueba práctica bastante honesta de madurez. ¿Se puede identificar rápido el proceso de negocio afectado? ¿Está mapeado el activo tecnológico a un proveedor, una versión y una función? ¿Hay procedimiento para exigir respuesta técnica del tercero? ¿Se clasifica el incidente potencial aunque todavía no haya explotación confirmada? Esas preguntas valen más que cien políticas bonitas.

También conviene recordar que muchas entidades españolas operan con capas de software heredado y desarrollos integrados durante años mediante proveedores múltiples. Eso multiplica el tiempo entre publicación del CVE y certeza sobre el impacto real. No porque la vulnerabilidad sea especialmente esotérica, sino porque la organización no siempre tiene visibilidad fina sobre qué APIs usa cada componente. Y, otra vez, ahí está el quid.

Qué sabemos de la remediación y por qué hay que seguir la cadena completa de parches

La NVD enlaza cinco commits del proyecto OpenSSL añadidos el 10 de junio de 2026, además del aviso de seguridad de OpenSSL fechado el 9 de junio de 2026 en secadv/20260609.txt. Esa secuencia ya da una pista práctica: la corrección existe y está referenciada públicamente, pero cada organización necesita traducir esos commits a versiones consumibles en su entorno. Si compilas OpenSSL directamente, la tarea es identificar la versión corregida y desplegarla. Si dependes de paquetes de distribución, contenedores base o firmware de terceros, el calendario no depende solo de ti.

Ese desfase importa. Muchas organizaciones cierran un ticket cuando el upstream publica el parche. Error clásico. El riesgo real no desaparece hasta que el binario corregido está en tu producto, en tu imagen, en tu appliance o en el paquete del proveedor que realmente ejecutas. Entre una cosa y otra puede haber días o semanas. Y durante ese tiempo tu cuadro de mando puede decir “patched available” mientras tu exposición sigue intacta.

Otro punto a vigilar es la validación posterior al parche. En componentes de correo o firma, una actualización de OpenSSL puede interactuar con compatibilidad de certificados, validación de formatos antiguos o flujos documentales sensibles. Eso no es excusa para retrasar la corrección; es motivo para probar con cierta inteligencia. Especialmente si el servicio es crítico y el remedio improvisado puede romper procesos de negocio esenciales.

Qué no hacer: ni minimizarlo por no ser TLS, ni sobreactuar como si todo OpenSSL fuera explotable mañana

Hay dos reacciones malas y, como suele pasar, ambas conviven alegremente en muchas empresas.

La primera es la minimización por fatiga. Como no afecta a TLS, certificados de servidor o una superficie obvia de internet, alguien concluye que “eso no nos toca”. Esa frase debería prohibirse en cualquier comité técnico sin inventario funcional delante. S/MIME, PKCS#7 y verificación de firmas no son exotismos académicos. Están metidos en productos corporativos reales, a menudo con más privilegios y menos supervisión de la deseable.

La segunda es el dramatismo indiscriminado. “OpenSSL”, “use-after-free”, “potencial RCE”: combinación perfecta para que se ordene parchear a ciegas todo lo que huela a criptografía. Resultado: ruido, ventanas de cambio mal priorizadas y equipos quemados persiguiendo falsos positivos. La respuesta buena está en medio y requiere trabajo de verdad: identificar usos de APIs PKCS#7, priorizar sistemas con entrada no confiable, exigir claridad a proveedores y validar corrección.

El cambio de vector en CISA-ADP del 10 de junio ayuda precisamente a eso. El mercado tiende a leer CVSS como si fuese una orden ejecutiva. No lo es. Es una señal, útil pero incompleta. En este caso, la diferencia entre presencia de componente y explotabilidad concreta es demasiado grande como para delegar la priorización en un número.

La lectura de fondo: una vulnerabilidad pequeña en apariencia, muy reveladora en la práctica

CVE-2026-45447 no va a ocupar el mismo espacio mediático que un fallo masivo en TLS o una cadena de explotación sin autenticación en software de perímetro. Pero sería un error clasificarla como asunto menor. Revela tres debilidades persistentes del sector.

La primera, la fragilidad del software que procesa formatos complejos y heredados. ASN.1, PKCS#7 y S/MIME siguen generando riesgos porque el legado no desaparece por aburrimiento.

La segunda, la baja visibilidad sobre uso efectivo de dependencias. Muchas compañías saben que usan OpenSSL. Bastantes menos saben en qué rutas funcionales, con qué APIs y expuestas a qué entradas externas.

La tercera, la distancia entre regulación y realidad operacional. DORA y NIS2 insisten en inventario, terceros y cadena de suministro. Luego llega un CVE concreto y demasiadas organizaciones descubren que aún no pueden contestar rápido a las preguntas básicas.

La noticia, en el fondo, no es solo que OpenSSL haya corregido un use-after-free en PKCS7_verify(). La noticia es que este tipo de fallos sigue siendo una prueba brutalmente eficaz para separar a las organizaciones que gestionan dependencias con precisión de las que solo acumulan herramientas.

Si tu equipo procesa mensajes firmados mediante PKCS#7 o S/MIME, la prioridad es clara: confirmar uso de APIs afectadas, localizar proveedores implicados, desplegar la versión corregida y documentar la evaluación. Si no sabes todavía si eso aplica a tu entorno, ya has encontrado el verdadero problema. Y, por desgracia, no se arregla con un simple patch.