Volver al glosario

Heartbleed

3 min de lectura Amenazas y adversarios

Heartbleed es una vulnerabilidad crítica de OpenSSL, divulgada en abril de 2014, que permitía a un atacante leer trozos de la memoria de un servidor directamente desde la red.

30 de julio de 2026
Compartir:

Heartbleed es una vulnerabilidad crítica de OpenSSL, divulgada en abril de 2014, que permitía a un atacante leer trozos de la memoria de un servidor directamente desde la red.

OpenSSL es la biblioteca que una parte muy grande de internet usa para implementar TLS, el protocolo que hay detrás de HTTPS y detrás de la entrega segura del correo. El fallo no estaba en el protocolo: estaba en una implementación concreta de la extensión heartbeat, que existe para que los dos extremos de una conexión puedan comprobar que el otro sigue ahí.

Una petición decía cuántos bytes quería que le devolvieran. El código se fiaba de ese número en lugar de contrastarlo con los datos realmente enviados, así que a una petición corta que decía ser larga se le respondía con lo que hubiera al lado en la memoria.

Por qué era tan grave

Filtraba memoria, y la memoria guarda secretos. Lo que volvía no era un fichero que el atacante hubiera pedido: era lo que el proceso hubiese manejado hacía poco. En la práctica, eso significaba datos de sesión, credenciales en tránsito y, en el peor caso, la propia clave privada del servidor.

Era silencioso. Una petición de Heartbleed parece una petición heartbeat, porque lo es. No tumbaba nada, no dejaba rastro evidente en los registros de la aplicación y se podía repetir todo el tiempo que el atacante quisiera.

Estaba en todas partes. Como OpenSSL está por debajo de tantísimo software, el parque afectado no era un producto, sino servidores web, servidores de correo, dispositivos VPN, sistemas embebidos y cualquier otra cosa que se hubiera enlazado contra una versión vulnerable.

Parchear no era el final. Si la clave privada de un certificado pudo filtrarse, actualizar la biblioteca es solo la mitad del trabajo: hay que reemitir el certificado y revocar el antiguo, y todo lo que estuviera en memoria durante la ventana de exposición hay que asumir que alguien más lo conoce.

Un ejemplo

Un sitio termina el HTTPS con una versión vulnerable de la biblioteca.

Un atacante envía el heartbeat malformado y recibe de vuelta un bloque de la memoria del servidor. Lo repite miles de veces, recogiendo todo lo que va pasando por ahí.

Entre esos bloques está la clave privada del certificado del servidor. A partir de ese momento el atacante puede suplantar al sitio ante cualquiera delante de quien consiga colocarse, y puede descifrar el tráfico capturado que estuviera protegido por esa clave.

Nada en el servidor parece ir mal. El servicio no se cayó en ningún momento y las peticiones eran válidas.

Dónde aparece esto en una auditoría

Heartbleed es antiguo, y la razón por la que sigue mereciendo una entrada de glosario no es la nostalgia. Es el ejemplo más limpio de una clase de problema que no deja de repetirse: el riesgo que heredas de una biblioteca que nunca elegiste, y la diferencia entre «aplicamos el parche» y «dimos los secretos por comprometidos». La segunda pregunta es la que se salta, y es la que decide si una exposición terminó de verdad.

¿Quieres ver cómo trabajamos en Asperis Security?

Agenda 30 minutos con uno de nuestros especialistas. Revisamos tu stack y te decimos qué conviene probar primero.