Security Incidents
Heartbleed (CVE-2014-0160)
A missing bounds check in OpenSSL that let a remote client read process memory, and the two years of unmonitored exploitation it enabled.
The bug
TLS supports a heartbeat extension that lets a client ask the server “send me this payload later”, so that a connection can be kept alive through NAT timeouts. The server copies the requested length from the request into the response without checking it against the length of the data it actually holds. A client can therefore ask for a large payload, receive a small one, and receive whatever was in memory between the two.
The consequences were unusually severe for a class of bug:
- Private keys in memory. A server keeping its private key in memory, as most did, could have it read.
- Session keys. Decrypted traffic for the sessions in the same process.
- Credentials. Passwords and tokens held by an application in the same process.
- Repeatable. There was no log entry. Exploitation left no trace in the request log that operators normally had.
The timeline
| Date | Event |
|---|---|
| 2014-04-07 | OpenSSL advisory and fixed release 1.0.1g; Codenomicon and Google Security disclosed simultaneously |
| 2014-04-08 | Widespread public reporting; mass certificate revocation begins |
| 2015-07-24 | The last publicly trusted certificate issued by a certificate authority affected by the bug is revoked, according to the industry reporting on the incident |
The two-year gap between the fix and the discovery of the last affected certificate is the part of the story that matters for risk assessment: patching a server does not retroactively fix the keys it handled.
What it changed afterwards
- Certificate revocation and the “heartbleed.com” checking service pushed mass revocation into public view, and the sheer volume caused visible failures across the ecosystem.
- The events materially strengthened the case for short-lived certificates, which is one of the reasons automated certificate renewal is now normal.
- The bug became the standard example of why a memory safety defect in a widely deployed library is a national-scale event rather than a vulnerability rating.
Claims this entry does not make
- It does not state a number of affected organisations. No such count exists; the measurements that were published are estimates from research groups, labelled as research findings.
- It does not state who was responsible. The state-actor attribution came from an intelligence assessment reported in the press and has no published primary record.
- It does not claim the two-year exploitation gap was “the worst in history”. That is a frequent assertion in commentary and is not a documented finding.
Sources
- OpenSSL security advisory, 7 April 2014 — the primary technical record, including affected versions and the fix.
- NVD: CVE-2014-0160 — the record used for the severity assessment and references.
Claim labels
FACT
The flaw is tracked as CVE-2014-0160 in the National Vulnerability Database.
FACT
It affected OpenSSL versions 1.0.1 through 1.0.1f, as stated in the OpenSSL security advisory of 7 April 2014.
FACT
The bug was introduced by a change to the heartbeat handling code, as described in the OpenSSL commit history reviewed after disclosure.
SOURCE CLAIM
An earlier version of this entry cited a Cloudflare post reporting detection of the Heartbleed exploit against the Cloudflare.com reverse proxy on 14 January 2014. Cloudflare has since removed that post, no other first-party record of that date is cited here, and the date is therefore not presented as established.
FACT
The fix was released as OpenSSL 1.0.1g on 7 April 2014, the same day as the advisory.
RESEARCHER ANALYSIS
Researchers at the University of Toronto, Netlab, and elsewhere published analyses of the class of bug and of mass exploitation. Their estimates of the scale of exploitation differ, and none of them produced a count of victims.
SOURCE CLAIM
Canadian authorities attributed the Heartbleed exploitation to a state actor, citing the certificate. That attribution was an intelligence assessment, not a technical finding, and was never publicly documented in a primary record.
Sources
Last link check: 2026-09-27. A link check confirms reachability, not that every claim has been independently reviewed.