OpenSSL corrige una fuga de memoria del heap en DTLS y deja 3.0 sin parche público
El fallo CVE-2026-84782 entrega bytes del heap sin cifrar al otro extremo de una conexión DTLS o tumba el proceso. Lo corrigen 4.0.3, 3.6.5, 3.5.9 y 3.4.8; las ramas antiguas, solo con soporte de pago.
OpenSSL publicó el aviso de seguridad el 29 de septiembre con los parches de CVE-2026-84782, un fallo de severidad alta en DTLS que puede entregar memoria del heap sin cifrar al otro extremo de la conexión o tumbar el proceso. La corrección está en OpenSSL 4.0.3, 3.6.5, 3.5.9 y 3.4.8. Para las ramas 3.0, 1.1.1 y 1.0.2 solo hay versión parcheada para clientes de soporte premium: ninguna de las tres recibe ya arreglos públicos.
Qué se rompe por dentro
DTLS es la variante de TLS que va sobre UDP, y es la que llevan los canales de datos de WebRTC y el intercambio de claves de las llamadas por internet. Para caber en un datagrama, trocea los mensajes de handshake grandes en fragmentos. Si la conexión no puede aceptar más datos en ese momento, el envío se pausa a mitad de mensaje y se reanuda después. El temporizador de reenvío sigue corriendo mientras tanto: si vence, reenvía un mensaje anterior, pero antes del parche ese reenvío usaba la posición del mensaje pausado en el búfer en lugar de volver al principio del mensaje que estaba reenviando. El mensaje salía con la etiqueta equivocada y su cuerpo eran bytes sobrantes del mensaje mayor, cuya lectura podía desbordar el búfer. Resultado: memoria del heap viajando al otro lado como datos de handshake sin cifrar, o un cierre del proceso si la lectura llega a memoria no mapeada. El fallo afecta a clientes y servidores por igual, y el arreglo se probó en ambos roles.
Lo reportó Laurent Gaffie, de Secorizon, el 17 de agosto, y el parche lo desarrolló Ryan Hooper. OpenSSL lo clasifica como High, un nivel por debajo de Critical en su escala. CISA le dio un CVSS de 8,2 sobre 10 el 29 de septiembre, con impacto bajo en confidencialidad y alto en disponibilidad, y sin explotación conocida. El proyecto no ha dicho si un atacante puede provocar el reenvío con un mensaje a medias, y no ha reportado ataques. El aviso de Ubuntu habla de "comportamiento incorrecto del handshake o denegación de servicio", sin mencionar la fuga de memoria. No hay workaround publicado: actualizar es la única vía.
La rama 3.0, el quebradero de cabeza
La última entrega pública de 3.0 fue la 3.0.22, el 25 de agosto. La 3.0.23 es la primera versión de seguridad de esa rama que OpenSSL no hace pública, y corrige 6 de los 14 fallos anunciados el 29 de septiembre, este incluido. Ubuntu 22.04 y 24.04 usan 3.0, así que ahí el arreglo llega por paquete: libssl3 3.0.2-0ubuntu1.30 en 22.04 y libssl3t64 3.0.13-0ubuntu3.16 en 24.04, con reinicio posterior. En 26.04 LTS es libssl3t64 3.5.5-1ubuntu3.6. Debian lo corrigió en Debian 13 con openssl 3.5.7-1~deb13u3, publicado como DSA-6531-1, y su tracker seguía marcando Debian 12 como vulnerable. Quien compile OpenSSL 3.0 por su cuenta o lo distribuya embebido en su propio producto no tiene arreglo público: le queda saltar a 4.0 o a la LTS 3.5, o firmar un contrato de soporte.
Los mismos lanzamientos arreglan otros 13 fallos. El más serio es CVE-2026-84783, Moderate y exclusivo de 4.0: un par remoto no autenticado puede tumbar un cliente TLS multihilo, o un servidor TLS multihilo que pida certificados de cliente, si varias conexiones construyen a la vez su primera cadena contra la misma CA de confianza. CVE-2026-75806 es Low: en conexiones DTLS 1.2 con cifrado AEAD, un solo datagrama demasiado corto cierra la conexión sin conocer ninguna clave.
Solo hay riesgo si el software usa OpenSSL para DTLS, algo habitual en stacks de tiempo real y VoIP. El problema de fondo es la rama 3.0, porque hay productos enteros que la llevan embebida y ya no tienen parche público. La recomendación del proyecto es moverse a 4.0 o a 3.5 LTS.
