When a bug leaks process memory, patching stops new leaks but does not undo old ones. Heartbleed guidance asks you to upgrade the library, then revoke and reissue certificates, invalidate sessions, and have users change passwords. The order matters, because a new key protects nothing if the old one is still trusted.
Step 1: patch first, or you rotate into the same hole
Upgrade to OpenSSL 1.0.1g or later, or rebuild with heartbeats disabled if you cannot upgrade. The Heartbleed site names the OPENSSL_NO_HEARTBEATS build option for that case. If you rotate secrets while the server is still vulnerable, the new secrets can leak the same way.
Step 2: assume the private key is gone
The site lists server private keys as primary key material. If a private key leaked, an attacker can decrypt captured traffic and impersonate the service. The remedy is to revoke the certificate through your certificate authority and get a new one issued, ideally with a freshly generated key pair. Reusing the old key in a new certificate defeats the point.
Steps 3 and 4: sessions, cookies and passwords
Session keys and cookies are secondary key material. Anyone holding a stolen session identifier can act as that user until it expires. Invalidate active sessions after the patch and the new certificate are live. Users will be signed out, which is the intended effect.
Usernames and passwords passing through a vulnerable server could sit in memory when it was probed. The guidance tells service owners to assess what may have leaked and to have users change passwords. Decide this by exposure: which servers were reachable and vulnerable, and which credentials passed through them.
Steps 5 and 6: forward secrecy and telling people
The Heartbleed site recommends perfect forward secrecy. With it, each session uses its own ephemeral keys, so a leaked long term key does not unlock earlier recorded sessions. Turning it on will not fix an old leak, but it limits the damage of the next one.
Service owners are asked to assess the exposure and notify users. Say which systems were affected, what you rotated and what you recommend users do. Do not claim that nothing was taken. The site notes that exploitation leaves no trace in logs, so you cannot prove a negative.
Turning this into a reusable runbook
- Keep a list of every certificate, where its key lives and who can reissue it.
- Know how to invalidate sessions in each application without a deploy.
- Have a tested path for forcing password resets.
- Track which services link which cryptographic libraries, so the first question has a fast answer.
If your inventory is a spreadsheet nobody updates, a dependency scan is a faster start. Safeguard offers SBOM and dependency scanning, and a free scan at gold.safeguard.sh/scan. For the bug itself, read how a missing length check leaked server memory.
Quick check
Do I need a new key or just a new certificate?
A new key. If the old private key leaked, a certificate that reuses it is still exposed.
Can I confirm from logs that nothing was stolen?
No. The Heartbleed site says exploitation leaves no trace in normal logs.
Sources
Last reviewed: 19 October 2026.
