Heartbleed (CVE-2014-0160) was a programming error in how OpenSSL handled the TLS heartbeat extension. The code trusted a length value sent by the other side and copied that many bytes from memory into its reply. Because nothing checked the claim, a server could hand back data it never meant to share.
What the heartbeat feature does
A heartbeat is a tiny keep-alive message. One side sends a short payload and says how long it is. The other side echoes the same payload back, proving the connection is still alive. The feature is defined in RFC 6520 and is simple on purpose.
The bug sat in the gap between "here is my payload" and "here is how long it is." If a sender claimed a payload much longer than the one it really sent, vulnerable OpenSSL still built a reply of the claimed size. The extra bytes came from whatever sat next to the payload in the process memory.
Why this was an implementation bug, not a protocol flaw
The Heartbleed site is clear on this point: the flaw was in OpenSSL's implementation of the extension, not in the SSL or TLS protocols. That distinction matters for how you respond. You cannot fix it by changing protocol settings. You fix it by running a patched library.
The affected range was OpenSSL 1.0.1 through 1.0.1f. The bug was introduced in December 2011 and reached released versions starting in March 2012. Version 1.0.1g, released on 7 April 2014, fixed it. The 1.0.0 and 0.9.8 branches were not affected.
What could leak, and why that was serious
The attacker needed no special access and no position between client and server. A single crafted request could pull a slice of memory from the other side. Repeating the request pulled more slices.
The Heartbleed write-up groups the exposure into three kinds. Primary key material, such as a server's private key. Secondary material, such as usernames, passwords, session keys and cookies. And protected content, such as messages and documents that happened to be in memory at the time.
Private key exposure was the worst case, because it allows decryption of captured traffic and impersonation of the service. That is why cleanup went well beyond installing a patch.
Why it was hard to spot
According to the site, exploitation leaves no trace in normal logs. Some intrusion detection rules could flag requests where the reply was far larger than the request, but blocking them would mean blocking heartbeats altogether. So defenders could not look back and be sure nothing had been taken.
What developers can take from it
- Treat every length field that arrives over the wire as untrusted input. Check it against the data you actually received before you copy anything.
- Prefer memory safe languages for new network facing parsers where you can, and use fuzzing and bounds checking tools on the C code you keep.
- Know which services in your estate link a given library, so a disclosure turns into a list rather than a scramble. A dependency inventory answers that question in minutes.
Safeguard's SBOM and dependency scanning can show which projects pull in a vulnerable library version, and you can try a free scan at gold.safeguard.sh/scan. For the cleanup side of this story, see what to rotate after a memory disclosure bug.
Quick check
Was Heartbleed a flaw in TLS itself?
No. It was an error in OpenSSL's implementation of the heartbeat extension. The protocol design was not the problem.
Which OpenSSL release fixed it?
OpenSSL 1.0.1g, released on 7 April 2014, according to the Heartbleed site.
Sources
Last reviewed: 19 October 2026.
