Heartbleed (CVE-2014-0160): timeline and what defenders learned

Heartbleed (CVE-2014-0160) was a bug in OpenSSL's heartbeat code that let remote attackers read chunks of server memory, including private keys and passwords, without leaving a trace in logs. It was disclosed on 7 April 2014 and fixed in OpenSSL 1.0.1g. Patching was not enough, because keys exposed earlier had to be replaced.

What is the timeline?

The dates come from the Heartbleed information site run by the discoverers.

• December 2011: the faulty code was introduced.
• 14 March 2012: it shipped in OpenSSL 1.0.1, the release that made the bug reachable in the wild.
• 3 April 2014: Codenomicon and Neel Mehta of Google Security each discovered the issue.
• 7 April 2014: public disclosure with the OpenSSL security advisory, and the fixed release 1.0.1g.

So the flaw sat in shipped code for about two years before anyone reported it. The affected versions were OpenSSL 1.0.1 through 1.0.1f. The 1.0.0 and 0.9.8 branches were not affected.

CISA later added CVE-2014-0160 to its Known Exploited Vulnerabilities catalog on 4 May 2022, long after the incident, which shows how long old flaws stay relevant in unmaintained systems.

What actually went wrong?

The site describes a programming mistake in the implementation of the TLS heartbeat extension (RFC 6520), not a flaw in the TLS protocol itself. A client could ask the server to echo back a string and claim it was longer than it was. The server copied that much memory into the reply.

Two properties made it nasty. First, the memory could hold anything the process had touched: private keys, session cookies, user credentials. Second, the discoverers state that exploitation leaves no trace in logs. Intrusion detection signatures could alert on it but could not undo past exposure.

What did the advisory tell people to do?

1. Upgrade to OpenSSL 1.0.1g or later, and install vendor fixes for operating systems and appliances that bundle OpenSSL.
2. If upgrading was impossible, rebuild OpenSSL without heartbeat support using the documented compile flag.
3. Revoke and reissue keys and certificates, since patching does not undo what was already read.
4. Ask users to change passwords once services were fixed, and invalidate sessions.

The site also notes that perfect forward secrecy limits the damage to past recorded traffic, while client certificates and FIPS mode do not mitigate the bug.

What should defenders take from it?

You cannot patch what you cannot find. OpenSSL was inside web servers, load balancers, VPNs and embedded gear. The teams that moved fastest knew where it was linked. A software inventory, or an SBOM, turns "are we affected?" from a week of emails into a query.

Patching has a second half. Exposure windows need key and credential rotation, and rotation needs a practiced process. If rotating a certificate is a quarterly project for your team, you are slow when it counts.

Silence is not safety. A bug that does not log leaves you reasoning from exposure, not evidence. Decide on that basis.

Old versions linger. Years later the flaw is still in an exploited-vulnerability list. Retiring unsupported components is part of the fix.

What to do

1. Keep a current inventory of libraries, including the ones compiled into appliances and containers.
2. Scan images and repositories for known vulnerable library versions, and record the result.
3. Write and rehearse a key and certificate rotation runbook.
4. Prefer configurations with forward secrecy.
5. Decide in advance which flaws trigger rotation, not only patching.
6. Set an end date for components that no longer receive fixes.

Safeguard's SCA dependency inventory and reachability analysis support the first two items for code and container dependencies.

Quick check

Sources

• Heartbleed.com
• CISA Known Exploited Vulnerabilities catalog and JSON feed (version 2026.10.16, fetched 18 October 2026)

Last reviewed: 18 October 2026.