Once bytes y un hilo esperando
Alguien del Red Team de Okta envió 11 bytes a un servidor y observó cómo este apartaba 131 kilobytes. El truco está en cómo se abre una conversación TLS. Los cuatro primeros bytes de un mensaje de saludo declaran cuánto va a medir el mensaje, y las versiones antiguas de OpenSSL se creían esa declaración y reservaban el búfer antes de que llegara el resto o de que se ejecutara validación alguna. El resto del mensaje no llegó nunca. La memoria quedó reservada y un hilo de trabajo se quedó esperando datos que ya no iban a venir.
Repetido, el efecto deja de ser sutil. En un servidor de un gigabyte el equipo dejó 547 megabytes congelados en fragmentos inservibles. En una máquina de dieciséis gigabytes bloquearon una cuarta parte de la memoria total. En sistemas que usan el asignador glibc la memoria no vuelve limpiamente ni siquiera cuando el atacante se desconecta, porque los fragmentos liberados no se pueden reutilizar. No hicieron falta credenciales, no llegó a establecerse sesión alguna y nada del intercambio parecía un ataque.
La parte que debería inquietar más a un directivo que a un ingeniero
OpenSSL lo corrigió. Las versiones 4.0.1, 3.6.3, 3.5.7, 3.4.6 y 3.0.21 salieron todas el 9 de junio de 2026 con el comportamiento corregido, reservando memoria solo a medida que los datos llegan de verdad. Tres solicitudes de incorporación de cambios, numeradas 30792, 30793 y 30794, llevaron la modificación. Después no se dijo nada durante más de cinco semanas. La divulgación pública llegó a la lista de correo oss-security el 18 de julio, 39 días después de que la corrección ya estuviera circulando.
El equipo de seguridad tomó una decisión consciente. OpenSSL mantiene un sistema de gravedad de cuatro niveles, de Crítico a Bajo, y consideró que este caso no encajaba en ninguno. La solicitud de cambios afirma con claridad que el equipo optó por tratar el informe como una corrección de "error o endurecimiento". Por eso no hay identificador CVE, ni aviso de seguridad, ni entrada en los registros de cambios de las versiones afectadas. Cada una de esas ausencias es una decisión, y cada una eliminó una señal que el proceso de alguien estaba construido para detectar.
El proceso disciplinado perdió frente al indisciplinado
Piense en dos empresas. La primera parchea OpenSSL con una cadencia mensual fija, sin mirar qué contiene la versión. Es el enfoque del que una función de seguridad madura suele acabar desprendiéndose, porque consume ventanas de cambio en versiones que no importan. Esa empresa está protegida desde junio y no tiene ni idea de que estuvo en riesgo.
La segunda prioriza por gravedad. Lee los avisos, puntúa los CVE, adelanta lo Crítico y lo Alto y aplaza el resto con una justificación documentada. Es el enfoque que supera una auditoría, satisface a una aseguradora y aguanta una pregunta del consejo. Esa empresa miró la versión de OpenSSL de junio, no encontró contenido de seguridad y decidió con toda corrección no gastar una ventana de cambio en ella. Sigue expuesta, y su proceso funcionó exactamente como se diseñó.
La conclusión incómoda es que parchear según la gravedad externaliza sus decisiones de riesgo a quien asigna esa gravedad. No es un reproche a OpenSSL, un proyecto sostenido en buena medida por voluntarios que toma decisiones defendibles sobre una escala de cuatro niveles que no debe a nadie. Es una observación sobre dónde reside en realidad el criterio. Si su proceso solo escala lo que llega ya etiquetado como peligroso, entonces su modelo de amenazas es en realidad la política de etiquetado de sus proveedores.
Dos cosas siguen siendo ciertas hoy
La vía DTLS se quedó como estaba. Corregirla bien se juzgó demasiado invasivo por ahora, así que ese código sigue dimensionando su búfer según la longitud que declara el interlocutor. Si usted termina DTLS en algún punto, y lo hacen muchos concentradores de VPN, servidores de medios WebRTC y pasarelas industriales de IoT, esa exposición no queda resuelta por nada de lo aquí descrito. Tampoco es un secreto escondido. Está dicho abiertamente en la divulgación, lo cual es en sí mismo un aviso.
Lo segundo tiene que ver con los tiempos. Lo normal es que divulgación y parche lleguen juntos y que defensores y atacantes salgan de la misma línea. Aquí el código corregido estuvo en confirmaciones públicas durante 39 días antes de que alguien explicara qué corregía. Leer una comparación de confirmaciones no es una habilidad exótica. Durante más de un mes, quienes leen código llevaron ventaja sobre quienes leen boletines, y el segundo grupo no sabía que había empezado una carrera.
La pregunta que conviene añadir a su próxima revisión
No reconstruya su programa de vulnerabilidades por un fallo de agotamiento de memoria. Sí añada una pregunta recurrente a la revisión que ya celebra: ¿qué renunciamos a parchear este trimestre porque llegó sin calificación de gravedad? No lo que aplazamos como Bajo. Lo que nunca entró en la cola porque nada lo etiquetó. Esa lista existe en cualquier organización y casi nadie la mira.
Después compare sus versiones de OpenSSL con las publicadas el 9 de junio, cosa de minutos, y anote si está cubierto por política o por suerte. La diferencia entre esas dos respuestas es todo el asunto. Un control que le protege por casualidad no es un control, y la próxima vez que la casualidad no aparezca lo descubrirá por la vía cara.
Leer a continuación: La corrección era pública 81 días antes del aviso | Una petición podía secuestrar tu sitio WordPress
