History
Heartbleed (CVE-2014-0160) — when memory leaked from the foundation of encrypted traffic
In 2014, OpenSSL (which underpins HTTPS) had Heartbleed — leaking server memory, even private keys and sessions. How the 'returns more than requested' bug worked, and the lessons: assume it all leaked, re-issue certs, rotate every secret.
Revisiting a landmark event for the lessons that still apply to your operations — defensively, not as a reproduction.
What happened — "returns more than requested"
TLS (the encryption behind HTTPS) has a keep-alive "heartbeat" exchange. The client sends a little data plus a length ("send this back"), and the server echoes it — simple by design.
OpenSSL's implementation didn't validate the claimed length. Send a few bytes but claim "send 64KB back", and the server reads past your data into adjacent memory and returns it. If a private key or session sat there, it leaked too.
Normal: sent length = returned length
"return 'bird' (4 chars), length 4" → server: "bird"
Heartbleed: tiny payload + huge claimed length
"return 'bird' (4 chars), length 64KB" → server: "bird + 64KB of neighboring memory (may include keys, sessions)"
No special privileges were needed; repeating it harvested fragments of memory bit by bit. A tiny bug in the most foundational of layers shook the trust of the world's traffic.
The dread of a 'traceless' leak
Heartbleed left little trace in normal access logs, so "did it leak" and "what leaked" were hard to assert. When in doubt, act on the worst case.
Timeline
2014-04-07
The flaw is disclosed and a fixed OpenSSL ships the same day.right after
Servers worldwide patch en masse; the breadth of impact causes alarm.afterward
Many services revoke and re-issue certificates "assuming the key leaked", and ask users to change passwords.
Why "patching alone" isn't the end
If the private key might have leaked, then even after patching, the old key is still valid. So the response is two-part — close the hole (patch) plus rotate assets as if they leaked (keys, certs, secrets).
Insufficient response
- Update OpenSSL and consider it "fixed"
- Rotate only the one secret you confirmed abused
- Keep using the same certificate
Correct response
- Update and revoke/re-issue certificates (regenerate the private key)
- Rotate every secret, key, and password the server holds
- Prompt users to change passwords
Lessons that still apply
Act as if everything leaked
Rotate every secret, key, and password — not just the one you confirmed. With a traceless leak, assume the worst.
Revoke and re-issue certificates
If the private key might have leaked, rebuild the certificate too. Until you rotate the key, the past leak stays alive.
Monitor foundational software too
Track CVEs in "foundations" like OpenSSL, not just your app. The deeper the layer, the wider the impact.
Value memory safety
"Read more than requested" bugs shrink structurally with memory-safe design and languages. Factor it into what you build on.
Read next
- Glossary: What is a CVE
- Incident: When .env exposed every secret
- Basics: Protecting secrets, for beginners
FAQ
QWhat could leak in Heartbleed?
Server memory — at worst the TLS private key, session contents, and login data. And it left little trace, so 'how much leaked' was hard to determine afterward.
QWhy did it 'return more than requested'?
In the keep-alive (heartbeat) exchange, the server trusted the length the peer claimed instead of checking it. Send a few bytes but claim '64KB back', and the server read past your data into adjacent memory and returned it. Trusting the input (the length) was the hole.
QWhat mattered most in the response?
After patching, acting as if everything leaked: revoking and re-issuing TLS certificates, and rotating every secret and password the server held. Patching the app alone wasn't enough.