Heartbleed Vulnerability (OpenSSL)

SSL Certificate Analysis Open Port Detection Web Application Scanning DNS Security Audit HTTP Header Analysis Misconfiguration Detection Software Fingerprinting Subdomain Enumeration
SSL Certificate Analysis Open Port Detection Web Application Scanning DNS Security Audit HTTP Header Analysis Misconfiguration Detection Software Fingerprinting Subdomain Enumeration

All Entries

Scan Your Site

Check your website for this issue

Run an automated scan and see whether your site is affected — with plain-language findings and fixes.

Start Scanning
Category Memory Disclosure / Cryptographic Library Flaw
Typical Severity Critical
CVE CVE-2014-0160
CVSS v2 Score 5.0 (AV:N/AC:L/Au:N/C:P/I:N/A:N) — industry-regarded as Critical due to impact
OWASP A02:2021 – Cryptographic Failures; A06:2021 – Vulnerable and Outdated Components
CWE CWE-125 (Out-of-bounds Read), CWE-126 (Buffer Over-read)
Also known as Heartbleed Bug, TLS Heartbeat Buffer Over-read
Affected OpenSSL versions 1.0.1 through 1.0.1f, 1.0.2-beta through 1.0.2-beta1
Affected systems HTTPS web servers, mail servers, VPN endpoints, load balancers, and any TLS service using vulnerable OpenSSL builds
Disclosed 7 April 2014
Fixed in OpenSSL 1.0.1g (7 April 2014)

Overview

Heartbleed is a critical vulnerability in the implementation of the TLS/DTLS heartbeat extension (RFC 6520) in OpenSSL versions 1.0.1 through 1.0.1f. Introduced in OpenSSL commit d4f0b on 31 December 2011 and shipped in OpenSSL 1.0.1 (March 2012), it remained undetected for over two years before public disclosure on 7 April 2014 by researchers from Codenomicon and Google Security.

The flaw is a buffer over-read: the server does not validate that a client-supplied length field in a heartbeat request matches the actual payload length, causing it to echo back memory contents far beyond the legitimate payload. Because the vulnerability requires no authentication and leaves no trace in standard logs, it was exploitable at scale and in complete silence.

Sensagraph automatically detects servers still running vulnerable OpenSSL versions or exposing the heartbeat extension without proper bounds checking.

How it works

The TLS Heartbeat extension (RFC 6520) allows one peer to send a HeartbeatRequest message containing an arbitrary payload and a claimed payload length. The receiving implementation is expected to echo the exact payload back in a HeartbeatResponse. The vulnerable OpenSSL code in ssl/d1_both.c (DTLS) and ssl/t1_lib.c (TLS) performed the following flawed logic:

  1. Read the 2-byte payload_length field from the incoming heartbeat message (attacker-controlled, up to 65,535).
  2. Allocate a response buffer of size payload_length + header overhead.
  3. Copy payload_length bytes from the request buffer into the response — without verifying that the actual request payload is at least that long.
  4. Send the response back to the requester.

By sending a heartbeat request with a 1-byte payload but claiming a length of 65,535, an attacker receives up to 64 KB of raw server-process heap memory adjacent to the heartbeat buffer. This memory may contain:

  • RSA or EC private keys (enabling retrospective decryption of recorded TLS traffic and impersonation of the server).
  • Session cookies and OAuth tokens (enabling account takeover without credentials).
  • HTTP request/response bodies, including POST data with usernames and passwords.
  • Internal memory addresses useful for bypassing ASLR in follow-on exploits.
  • Other TLS session keying material.

The attack is unauthenticated, requires only a standard TCP connection to port 443 (or any TLS port), and produces no meaningful server-side log entries. Requests can be repeated continuously to harvest additional memory regions.

Business impact

Heartbleed is widely considered one of the most damaging web vulnerabilities ever discovered. A successful attack against an unpatched server can result in:

  • Private key compromise: If the server's TLS private key is recovered, an attacker can perform person-in-the-middle attacks against all future connections and decrypt all previously recorded encrypted traffic (past-session decryption is possible without perfect forward secrecy).
  • Session hijacking: Stolen session tokens allow full account takeover for authenticated users without knowledge of passwords.
  • Credential theft: Plaintext passwords present in heap memory (from in-flight HTTPS requests) may be directly extracted.
  • Regulatory and compliance exposure: Extraction of personal data triggers notification obligations under GDPR, HIPAA, PCI-DSS, and similar frameworks.
  • Reputational damage: High-profile breaches attributable to Heartbleed (e.g., Canada Revenue Agency, Mumsnet) demonstrated severe reputational consequences.
  • Certificate reissuance costs: After patching, all TLS certificates whose keys may have been exposed must be revoked and reissued.

How to fix it

  1. Upgrade OpenSSL immediately: Update to OpenSSL 1.0.1g or later (or a distribution-patched equivalent). Verify with openssl version -a. Modern deployments should target OpenSSL 3.x.
  2. Restart all services: OpenSSL is loaded into process memory at startup; a library upgrade without service restart does not remove the vulnerable code from memory.
  3. Revoke and reissue TLS certificates: Assume all private keys for certificates in use during the vulnerable period are compromised. Revoke affected certificates with the issuing CA and generate new key pairs before requesting replacement certificates.
  4. Invalidate all active sessions: Force logout of all authenticated users and rotate session secrets, CSRF tokens, and any symmetric keys that may have been present in heap memory.
  5. Rotate secrets and credentials: Rotate API keys, OAuth secrets, database passwords, and any other secrets that may have been processed by the vulnerable server.
  6. Enable Perfect Forward Secrecy (PFS): Configure cipher suites preferring ECDHE or DHE key exchange (e.g., TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) so that future key compromises cannot decrypt past sessions.
  7. Disable the heartbeat extension if not needed: Compile OpenSSL with -DOPENSSL_NO_HEARTBEATS if the heartbeat feature is not operationally required.
  8. Audit dependencies: Identify all software components (load balancers, mail servers, VPN appliances, embedded devices) that bundle OpenSSL and apply vendor patches.
  9. Notify affected users: If session or credential data may have been exposed, comply with applicable breach notification laws and inform affected individuals promptly.

References

Frequently asked questions

Yes. While the majority of major internet services patched OpenSSL within weeks of the April 2014 disclosure, embedded systems, legacy appliances, IoT devices, and neglected internal infrastructure still run vulnerable OpenSSL versions. Automated scans regularly discover unpatched endpoints years after the fix was available.

Standard web server logs do not record heartbeat exchanges, making Heartbleed attacks effectively invisible in access logs. Detection requires a dedicated heartbeat probe that sends a malformed heartbeat request and inspects whether the server returns more data than was sent.

No. Patching stops future exploitation but does not address data that may already have been exfiltrated. Full remediation requires revoking and reissuing TLS certificates, rotating all secrets, and invalidating all active sessions in addition to the library upgrade.

OpenSSL 1.0.1 through 1.0.1f and the pre-release 1.0.2-beta1 are affected. OpenSSL 1.0.0 and earlier, and 0.9.x branches, did not implement the heartbeat extension and are therefore not vulnerable to Heartbleed specifically.

TLS 1.3 (RFC 8446) removes the heartbeat extension entirely from the protocol, so implementations that exclusively support TLS 1.3 are not exposed to Heartbleed. However, the underlying lesson — validating length fields before memory operations — is a general secure coding requirement independent of protocol version.