El riesgo de la confianza ciega en los encabezados TLS
Recientemente se ha dado a conocer una vulnerabilidad crítica denominada HollowByte que afecta a la biblioteca de cifrado OpenSSL, un componente fundamental en la infraestructura de seguridad de millones de servidores en todo el mundo. Este fallo permite que un atacante remoto agote la memoria de un servidor mediante el envío de peticiones TLS extremadamente pequeñas, de apenas 11 bytes.
El equipo de Red Team de Okta, responsable del hallazgo, ha revelado que esta vulnerabilidad de denegación de servicio (DoS) es especialmente insidiosa porque no requiere autenticación ni el establecimiento de una sesión completa para ser explotada.
¿Cómo funciona HollowByte?
Desde una perspectiva técnica, el fallo reside en la forma en que las versiones antiguas de OpenSSL gestionan el handshake (saludo inicial) de TLS. Cada mensaje de este proceso incluye un encabezado de 4 bytes, de los cuales tres declaran la longitud del cuerpo del mensaje que seguirá.
- Asignación prematura: OpenSSL aceptaba la declaración del atacante y reservaba inmediatamente un búfer de memoria de hasta 131 KB antes de recibir un solo byte del cuerpo del mensaje.
- Bloqueo de hilos: El hilo de trabajo del servidor quedaba bloqueado esperando un contenido que nunca llegaba.
- Fragmentación de memoria: En sistemas que utilizan la biblioteca
glibc(común en la mayoría de las distribuciones Linux), la memoria liberada tras una conexión fallida no siempre regresa al núcleo del sistema, sino que se mantiene para reutilización, provocando una fragmentación del heap que acaba por agotar los recursos del sistema (OOM – Out of Memory).
Un desafío para la gestión de vulnerabilidades
Lo más preocupante para los responsables de ciberseguridad empresarial es que OpenSSL decidió gestionar este parche como una «mejora de endurecimiento» (hardening) y no como una vulnerabilidad formal. Como resultado, no se asignó un código CVE, no hubo avisos de seguridad oficiales ni menciones en los registros de cambios (changelogs) habituales.
Esta falta de transparencia significa que los escáneres de vulnerabilidades estándar podrían no detectar sistemas expuestos, y los procesos automáticos de parcheado basados en identificadores CVE no habrán priorizado esta actualización.
Impacto en el entorno empresarial
A diferencia de otros ataques de denegación de servicio, HollowByte es difícil de mitigar con defensas perimetrales tradicionales. Según las pruebas de Okta, un servidor con 16 GB de RAM podría ver comprometido el 25% de su memoria sin siquiera alcanzar los límites de conexiones simultáneas habituales, lo que lo convierte en un ataque sigiloso y altamente efectivo.
Recomendaciones de Intedya
Para proteger su infraestructura, desde Intedya recomendamos encarecidamente a los departamentos de TI y seguridad realizar las siguientes acciones:
- Verificar versiones: Asegúrese de que sus servidores ejecutan versiones de OpenSSL iguales o superiores a 4.0.1, 3.6.3, 3.5.7, 3.4.6 o 3.0.21.
- Actualización manual: Dado que no existe un CVE asociado, es necesario verificar manualmente que los paquetes de su distribución Linux han incorporado el parche lanzado el 9 de junio de 2026.
- Reiniciar servicios: Una vez actualizado el paquete, es fundamental reiniciar los servicios que utilizan OpenSSL (como NGINX, Apache o bases de datos) para que la nueva versión cargue correctamente en la memoria.
En un entorno donde las amenazas evolucionan hacia la sutileza técnica, la vigilancia proactiva y la actualización constante de los componentes críticos siguen siendo la mejor defensa para la continuidad del negocio.
Fuentes
- The Hacker News — OpenSSL HollowByte Flaw Could Freeze Server Memory with 11-Byte TLS Requests
https://thehackernews.com/2026/07/openssl-hollowbyte-flaw-could-freeze.html