Skip to main content
All fixes

SSL, TLS, security headers

Patch Heartbleed by upgrading OpenSSL and rotating keys

Heartbleed (CVE-2014-0160) leaks server memory including private keys. Upgrade OpenSSL to a patched version, then reissue certificates and rotate session secrets.

What's happening

Heartbleed (CVE-2014-0160) is a buffer over-read in OpenSSL's TLS heartbeat extension that lets an attacker read up to 64 KB of process memory per crafted heartbeat. The leaked memory can include private keys, session cookies, passwords, and any other secrets the OpenSSL process touches. Disclosed in April 2014, it is one of the most consequential TLS vulnerabilities ever shipped.

Heartbleed affects OpenSSL 1.0.1 through 1.0.1f. Upgrading to 1.0.1g or later — or to any 1.0.2/1.1/3.x release — closes the bug. But upgrading is not enough on its own: any private key, session secret, or password that lived in memory during the vulnerable window has to be assumed compromised and rotated.

In 2026 a public-facing server still vulnerable to Heartbleed indicates either a frozen-in-time legacy system or a packaging bug. Either way the fix is to upgrade and rotate. Compliance scanners catch the bug instantly.

Why it matters

Stolen private keys mean the attacker can passively decrypt past traffic (if no forward secrecy was used) and impersonate the server in MITM attacks. Reissuance of every certificate touched by the vulnerable OpenSSL is mandatory.

Session cookies and passwords exfiltrated via Heartbleed enable account takeover at scale. Any user who logged in during the vulnerable window must be invalidated.

PCI-DSS, HIPAA, and most other compliance frameworks treat Heartbleed exposure as an immediate reportable incident. Bug-bounty programs accept it as critical.

Common causes

  • Server is running a Linux distribution end-of-life version with OpenSSL 1.0.1a-f and no backported patch.
  • Application bundles its own OpenSSL build and never updated.
  • A statically linked binary embeds the vulnerable version.
  • Hardware load balancer firmware uses the vulnerable OpenSSL and was never patched.
  • Container image based on an unpatched parent never rebuilt.

Detect this on your site

Run a quick scan with the SSL Checker. The tool surfaces this exact issue with the records and context needed to apply the fix below.

Open SSL Checker

How to fix it

  1. 1

    Probe for Heartbleed

    Use a known scanner: nmap -p 443 --script ssl-heartbleed example.com or testssl.sh -B example.com. The CheckFast SSL Checker at /ssl also tests for the bug. If the report says 'VULNERABLE', the next steps must run immediately.

  2. 2

    Upgrade OpenSSL

    On Ubuntu/Debian: sudo apt-get update && sudo apt-get install --only-upgrade openssl libssl-dev. On CentOS/RHEL: sudo yum update openssl. On Alpine container: rebuild from a newer base image. Confirm with openssl version — anything 1.0.1g+ is patched, but ideally upgrade to 1.1 or 3.x.

  3. 3

    Restart every service that links OpenSSL

    Apply the upgrade and restart nginx, Apache, HAProxy, sshd, postfix, OpenVPN, and anything else linked against OpenSSL. sudo systemctl restart nginx apache2 haproxy postfix. Use lsof | grep libssl to find lingering processes still holding the old library.

  4. 4

    Reissue every TLS certificate

    Treat every private key that lived on the vulnerable host as compromised. Generate fresh keys and request new certificates from your CA. With certbot: sudo certbot certonly --force-renewal --reuse-key=false -d example.com. Revoke the old certificates with the CA after the new ones deploy.

  5. 5

    Invalidate every session and rotate secrets

    Force every logged-in user to re-authenticate. Rotate API keys, signing secrets, OAuth client secrets, database passwords, and any other secret material that touched the vulnerable host's memory. This is the boring step everyone skips and regrets.

  6. 6

    Re-scan and document

    Re-run the Heartbleed probe. The result must be 'NOT VULNERABLE'. Document the timeline (vulnerability window, patch deploy, key rotation) for the audit trail. Notify any users whose data was at risk per your incident-disclosure policy.

Example

# Probe for Heartbleed with nmap
nmap -p 443 --script ssl-heartbleed example.com

# After patching, upgrade and verify version
sudo apt-get update && sudo apt-get install --only-upgrade openssl libssl-dev
openssl version
# OpenSSL 3.0.13 30 Jan 2024  (or any 1.0.1g+)

Probe for and remediate Heartbleed

Frequently asked

Yes. Heartbleed leaves no log entries — there is no way to prove the key was not exfiltrated. Reissuance is the only safe assumption. Skipping this step is one of the most common post-Heartbleed mistakes.

TLS 1.3 itself is not vulnerable because it uses different protocol mechanics. But the OpenSSL library's heartbeat extension was the bug and a server running vulnerable OpenSSL 1.0.1a-f could still be exploited via TLS 1.0/1.1/1.2 connections regardless of whether 1.3 is also enabled.

Related fixes

SSL, TLS, security headers

Disable weak SSL ciphers and enforce modern TLS suites

SSL, TLS, security headers

Disable TLS 1.0 and TLS 1.1 to meet PCI-DSS and modern standards

SSL, TLS, security headers

Mitigate the CRIME TLS compression attack on web servers

SSL, TLS, security headers

Eliminate POODLE risk by disabling SSLv3 and CBC fallback