What happened
On 7 April 2014, the OpenSSL project published a security advisory for a flaw, tracked as CVE-2014-0160, in the library's handling of a TLS extension used to keep connections alive. The bug allowed a connected client or server to read up to 64 kilobytes of a system's memory per request, with no limit on how many times the request could be repeated. A companion site set up for the disclosure, Heartbleed.com, explained that the exposed memory could contain private encryption keys, session cookies and passwords, or the content of protected communications, and that the flaw had existed in OpenSSL 1.0.1 through 1.0.1f since the code was introduced in December 2011, meaning it had been present in released software for more than two years.
Confidence and limits
Both documents are the primary technical disclosure and its accompanying public explanation, written by the researchers and OpenSSL team involved in the coordinated fix, and they are specific about the affected version range and the fix, OpenSSL 1.0.1g. Neither document can establish, and neither claims, how widely the bug was exploited before public disclosure, since reading memory through the flaw does not necessarily leave evidence in standard server logs; any claim about pre-disclosure exploitation should be treated as separate from what these two documents themselves establish.
Why it mattered
OpenSSL was, and remains, one of the most widely used implementations of the encryption protocol that secures ordinary web traffic, and the advisory's fix applied to any of the very large number of servers, network devices and embedded systems that had shipped with the affected versions. Because the flaw could expose a server's private key, the safe assumption for an affected system was not simply to apply the patch but to treat the key as compromised and reissue it, since a leaked key found before or after disclosure could be used to decrypt previously captured traffic or impersonate the server.
Defensive takeaway
Where you cannot verify with certainty that key rotation happened at the time, treat any system that ran an affected OpenSSL version as still carrying residual risk, and confirm your current inventory can identify every instance of a cryptographic library's version across your environment.
- Do you maintain an inventory that can tell you, quickly, every system running a specific version of a cryptographic library?
- Were private keys and certificates rotated, not just reissued from the same key, on systems affected by Heartbleed at the time?
- Does your organization have a plan for coordinated disclosure and patching when a widely used open-source dependency has a critical flaw?
Heartbleed's lasting significance was less about any single breach it caused, which the advisory and disclosure site do not attempt to quantify, than about what it revealed regarding dependence on a small number of open-source maintainers for the software underlying most encrypted web traffic, a concern that shaped funding and support efforts for critical open-source infrastructure in the years that followed.