Heartbleed (CVE-2014-0160)
Imagine paying for a coffee at a café. You give the cashier a £5 note. They give you £3.50 in change, plus - because they're not paying attention - a small handful of receipts, business cards, and what looks like part of the daily takings of the till. You weren't supposed to see any of that. They weren't supposed to give it to you. But you asked for change, and the till opened, and the contents came out.
That, more or less, is Heartbleed.
Quick summary
- What: A vulnerability in OpenSSL's TLS heartbeat extension that allowed an attacker to read up to 64KB of server memory per request - including private keys, passwords, and session tokens. CVE: CVE-2014-0160 Disclosed: April 7, 2014 Affected: OpenSSL versions 1.0.1 through 1.0.1f Patched in: OpenSSL 1.0.1g (released same day as disclosure) Severity at the time: Catastrophic. Estimated 17% of "secure" web servers vulnerable on disclosure day. Status in 2026: Largely patched, but occasionally found in unpatched legacy systems and IoT devices.
What it is in plain English
Heartbleed lived in a piece of TLS called the "heartbeat extension" - a feature designed to keep connections alive by sending small pings back and forth. The ping was supposed to work like this: "send me back the word 'hello,' which is 5 characters long."
The bug was in how OpenSSL handled the length number. If you sent a ping that said "send me back the word 'hello,' which is 65,000 characters long," OpenSSL would obediently send back 'hello' followed by 64,995 characters of whatever happened to be next in its memory.
What was next in memory? Often: private keys, passwords being processed, session tokens, encrypted data being decrypted, the contents of other users' requests. The attacker didn't pick what they got - they got whatever the server happened to have at that moment. But if you ran the attack thousands of times, you collected a lot of interesting data.
How the attack worked
The attack required no authentication. Any client that could connect to the server could send a malformed heartbeat request. There were no logs of it on the server side, because the heartbeat extension didn't log routine pings.
A typical attack:
- Connect to the target server over TLS. Send a heartbeat request claiming a payload of 64KB. Receive 64KB of server memory in response. Repeat. Each request returned different memory contents. Parse the responses looking for valuable data - keys, tokens, credentials.
Within hours of disclosure, attack tools were public. The attack was easy to run, hard to detect, and worked against any server running a vulnerable OpenSSL version. The mass scans started immediately.
What the impact was
Heartbleed was unusual in several ways.
Scale. Roughly 17% of HTTPS sites globally were running vulnerable OpenSSL versions on disclosure day. That's hundreds of thousands of high-value services.
Stealth. Because the bug was in the heartbeat handler and didn't leave logs, victims had no way of knowing whether they'd been exploited before April 7. Any data stolen between when the bug was introduced (December 2011) and when it was patched might have been quietly collected.
Key compromise. The fact that private keys could leak meant every affected service had to do more than patch - they had to rotate certificates, revoke the old ones, and re-issue. Not all of them did. CT logs from the months after Heartbleed show certificate issuance spikes followed by very slow revocation rates, meaning many compromised certificates stayed valid for months.
The branded-vulnerability era. Heartbleed had a name, a logo, and a website. It worked. Security communications were never quite the same afterward. Vulnerabilities started arriving with PR campaigns. Some of them - POODLE, ROBOT, FREAK - were genuinely serious. Others were less serious than the branding suggested.
How to know if you're vulnerable today
In 2026, finding Heartbleed in production is rare but possible. Look for it in:
- Legacy systems running OpenSSL 1.0.1 through 1.0.1f. These are very old. IoT devices and embedded systems with infrequent firmware updates. Some shipped with vulnerable OpenSSL and never received the patch. Internal-facing tools that haven't been audited since 2014. Network appliances with old underlying libraries. Vendor patches lag.
Detection tools:
- Online: Qualys SSL Labs flags Heartbleed in its checks. Free. Command-line:
nmap --script ssl-heartbleed -p 443 [host]runs a safe test. Continuous: any modern external TLS scanner, including TLS Radar, includes Heartbleed detection.
If you find it, you have an urgent patching job and a much harder cleanup job - keys may have leaked, and you don't know.
How to fix and mitigate
- Patch OpenSSL to a version at or above 1.0.1g (released April 7, 2014). Modern distributions ship versions far beyond this. If you have anything older, that's the start. Rotate certificates on any system that ran vulnerable OpenSSL for any meaningful time. You don't know what leaked. Revoke the old certificates so they can't be misused if they did leak. Audit for similar bugs. Heartbleed was a missing-bounds-check. Modern OpenSSL has substantially better testing, but the lesson - check inputs in protocol handlers - is broadly applicable.
Why it still matters in 2026
Heartbleed is twelve years old. The patch has been available the whole time. So why include it in a 2026 reference page?
Three reasons.
It hides in the long tail. IoT, embedded systems, and old internal tools sometimes still have it.
It set the template for branded TLS vulnerabilities. Understanding Heartbleed helps with understanding the dozen named TLS bugs that followed.
It's a permanent example of why monitoring matters. If you can't quickly answer "are any of our systems vulnerable to a known TLS bug?", you have an inventory problem first and a vulnerability problem second.
One small ask
Heartbleed is in every TLS scanner's check list, including ours. If you're not running a continuous external scan against your endpoints, Heartbleed is one of the things you might not know about. TLS Radar's free tier covers three domains and runs the full vulnerability check set every day. Worth an afternoon to see what's there.
Related reading
Get the next post in your inbox
TLS monitoring tips and product updates. No spam, unsubscribe anytime.