Heartbleed (CVE-2014-0160) was a memory read flaw in OpenSSL's heartbeat feature that left no trace in logs. An organization would have caught it by knowing where OpenSSL runs, patching fast, and being able to rotate keys and sessions. This checklist tests those abilities, with no blame on anyone who was hit.
What was Heartbleed?
According to the project page at heartbleed.com, it was a programming mistake in OpenSSL's implementation of the TLS and DTLS heartbeat extension, not a flaw in the protocol design. Exploitation leaks memory contents, which could include private keys for certificates, usernames and passwords, session keys and cookies, and the content services handled.
Affected versions were OpenSSL 1.0.1 through 1.0.1f. The 1.0.0 and 0.9.8 branches were not affected. The fix, 1.0.1g, was released on 7 April 2014. The bug was introduced in December 2011, appeared in releases from 14 March 2012, was discovered on 3 April 2014 and made public on 7 April 2014.
Two details shape the checklist. Exploitation leaves no trace in logs, and the page notes that client certificate authentication, FIPS mode and disabling heartbeat during the handshake did not mitigate the bug.
Why is it a good test today?
Because the questions it raises are timeless. Find every place a library runs. Patch quickly. Assume secrets may have leaked and replace them. Those are the same questions a new library emergency asks.
Nobody should read this as criticism of the volunteers or the organizations affected. The flaw sat in code that millions of systems used, and many teams had no practical way to find it.
Can you answer these in a day?
Inventory. Can you list every system, container image and appliance that bundles a TLS library, with versions? Libraries hide inside vendor appliances and container layers, not only on servers you manage.
Matching. Given a new CVE and a version range, can you search that inventory and get an answer within hours? An SBOM per build makes this a query instead of a campaign.
Patching. What is your fastest path from advisory to production for an internet facing component? Is it tested, or only written in a policy?
Third parties. Which suppliers run affected software on your behalf, and how would you learn their status?
What would the cleanup have required?
The heartbleed.com guidance lists the steps: upgrade, or recompile without heartbeat support; revoke compromised keys and reissue certificates with new keys; invalidate session keys and cookies; have users change passwords; and notify users if protected content may have been exposed.
So test those too. Can you reissue certificates in bulk? Do you know who holds the account at your certificate authority? Can you force all sessions to end? Do you have a notification path for users?
Because exploitation leaves no logs, you cannot rely on proving that nobody read memory. The safer assumption, and the one the guidance reflects, is to treat secrets as exposed on affected systems.
What about forward secrecy?
The page says perfect forward secrecy can protect past communications from later decryption, while otherwise previously intercepted traffic may remain decryptable after patching. It is a design choice worth checking in your TLS configuration today, long before an incident.
What to do
- Build an inventory of components per system, container image and appliance.
- Keep a build time SBOM for every release so searches are quick.
- Time a drill: pick a library and version range, and find every instance.
- Rehearse certificate reissue and session invalidation.
- Check your TLS configuration for forward secrecy.
- Ask critical suppliers how they notify you of urgent library flaws.
Quick check
Could logs have shown a Heartbleed attack?
According to heartbleed.com, exploitation leaves no trace in logs, so you cannot rely on them to prove you were not affected.
Which OpenSSL versions were affected?
OpenSSL 1.0.1 through 1.0.1f. The 1.0.0 and 0.9.8 branches were not affected, and 1.0.1g fixed the flaw.
Sources
- Heartbleed.com, fetched 18 October 2026.
Last reviewed: 18 October 2026.
