OpenSSL HollowByte: 11 bytes bastan para congelar la memoria de un servidor TLS

Una consulta TLS de 11 bytes es suficiente para hacer que la memoria de un servidor OpenSSL se inflé hasta causar denegación de servicio. Un DoS asimétrico temible.

Hechos

Dos fuentes independientes (The Hacker News, BleepingComputer) reportan el 17 de julio de 2026 una vulnerabilidad llamada HollowByte en OpenSSL. El principio: una solicitud TLS de solo 11 bytes provoca una asignación de memoria desproporcionada en el servidor, hasta saturar la RAM. Es una clase de ataque conocida como DoS de amplificación de memoria.

• Vector: solicitud TLS malformada de 11 bytes.
• Efecto: inflado de memoria en el servidor (RAM saturada → caída o denegación de servicio).
• Componente: OpenSSL, biblioteca criptográfica utilizada por la mayoría de servidores web, VPN, MTAs y herramientas de red del mundo.

¿Quién está afectado?

Casi todo lo que usa TLS en Internet y que no haya migrado a una versión corregida: servidores Apache/Nginx, backends de API, proxies inversos, VPN OpenVPN/strongSwan, servidores de correo. La distinción crítica se hará entre las versiones de OpenSSL afectadas (LTS 3.x y ramas anteriores aún soportadas) — confirmar en el advisory oficial de openssl.org/news/vulnerabilities.html.

Análisis

Una relación de 11 bytes ➜ varios megabytes de RAM es una pesadilla operativa: el costo para el atacante es ridículo (una conexión, un paquete), el costo para la víctima es masivo (memoria, CPU para liberarla, posible caída). Es un clásico de los DoS asimétricos, pariente lejano de los ataques de amplificación DNS o NTP de los años 2010.

Cabe destacar: no es una RCE, ni una fuga de memoria como Heartbleed (que exponía datos). Es una denegación de servicio. La consecuencia empresarial: indisponibilidad, no exfiltración. Pero un backend de API que cae durante una hora en horario de máxima afluencia puede costar muy caro.

El hecho de que dos fuentes (The Hacker News, BleepingComputer) reporten el incidente con horas de diferencia el mismo día indica que el advisory de OpenSSL probablemente ya esté publicado o sea inminente. Los PoC públicos suelen seguir en 24-48 horas para este tipo de vulnerabilidades bien documentadas.

Qué hacer ahora

• Actualizar OpenSSL al publicar el parche oficial (apt update && apt upgrade openssl libssl3 en Debian/Ubuntu, yum update openssl en RHEL).
• Reiniciar los servicios dependientes tras la actualización (nginx, apache, postfix, openvpn — la librería se carga en memoria).
• Verificar la versión en producción: openssl version -a.
• Limitar el caudal de nuevas conexiones TLS a nivel de proxy inverso (Nginx: limit_conn, Cloudflare: rate limiting).
• Supervisar la RAM de los servidores expuestos: un aumento repentino del uso de memoria de OpenSSL puede ser señal de explotación.

Qué queda por confirmar

El número CVE oficial, el rango exacto de versiones vulnerables y los nombres de las variantes afectadas (BoringSSL, LibreSSL, WolfSSL — los forks a veces comparten los mismos bugs) siguen por confirmar en el advisory de OpenSSL. Seguiremos actualizando.