On April 7, 2014, the OpenSSL project released a security advisory for CVE-2014-0160 - a vulnerability in the TLS heartbeat extension that allowed remote attackers to read up to 64 kilobytes of memory from any server or client using the affected OpenSSL versions. The vulnerability, named Heartbleed by Neel Mehta of Google Security (who discovered it independently alongside researchers at Codenomicon), did not require authentication, left no log traces in default configurations, and had been present in OpenSSL since December 2011 - approximately two years.

Heartbleed affected approximately two-thirds of the websites using HTTPS at the time of disclosure. OpenSSL was the dominant TLS implementation in open-source software and the default in virtually every Linux distribution. The affected versions were used in Apache and nginx web servers, email servers, VPN endpoints, network appliances, and embedded devices. Attackers could use Heartbleed to steal private keys, session cookies, passwords, and any other data present in server memory - silently, without triggering any server-side alarms.

The Heartbeat Extension and the Bug

TLS 1.2 includes a heartbeat extension that allows either side of a TLS connection to send a "heartbeat request" - a small message that the other side is expected to echo back. The purpose is to keep connections alive and verify that the remote peer is still responsive without needing to do a full handshake.

The heartbeat request contains a payload and a length field. The responding party is supposed to copy the payload back in its response. The Heartbleed vulnerability was in how OpenSSL handled the length field: it trusted the length value in the request without verifying that the actual payload was that long. If a client sent a heartbeat request claiming a 64KB payload but actually sending only 1 byte, OpenSSL would respond by copying 64KB of memory - starting from the location of the 1-byte payload and continuing through whatever adjacent memory happened to exist.

What that adjacent memory contained was unpredictable but potentially devastating: TLS session keys, private keys used to decrypt TLS traffic, session cookies, user passwords submitted over HTTPS, or any other data that the server process had in memory. A single Heartbleed request would return up to 64KB of memory. An attacker who sent thousands of requests would eventually sample a large portion of the server's memory space.

[TECHNICAL NOTE]
The Heartbleed request structure: HeartbeatMessage type (1 byte, value 1 for request), payload length (2 bytes, claimed by attacker), payload (actual attacker data), padding. OpenSSL's vulnerable memcpy call: memcpy(bp, pl, payload); where payload was taken from the message's length field without bounds checking against the actual received data length. The fix was a single bounds check: if (1 + 2 + payload + 16 > s->s3->rrec.length) return 0; - verifying that the claimed payload length doesn't exceed the received record length before copying. One missing bounds check, present in production for 27 months.

Two Years in Production

The vulnerable code was introduced by German developer Robin Seggelmann in a commit on December 31, 2011. The OpenSSL commit review process did not catch the missing bounds check. The vulnerability was present in OpenSSL versions 1.0.1 through 1.0.1f - a significant range that covered two years of production deployments.

By April 2014, OpenSSL 1.0.1 was widely deployed. Ubuntu 12.04 LTS, Ubuntu 12.10, and Ubuntu 13.10 all shipped with affected versions. Debian Wheezy shipped with an affected version. CentOS 6.5 with OpenSSL updates. Red Hat Enterprise Linux 6.5. The affected versions were in the default packages of most major Linux distributions.

The NSA was later reported (by Bloomberg) to have known about Heartbleed and used it for intelligence collection during the two years before public disclosure. The NSA denied this. The denial was consistent with the NSA's formal position, but the "Vulnerabilities Equities Process" - which is supposed to determine when the NSA discloses vulnerabilities to vendors versus retaining them for offensive use - was subsequently revealed by Snowden documents to favor retention. Whether the NSA knew about Heartbleed specifically was never definitively established.

The Disclosure and Response

Neel Mehta at Google Security reported Heartbleed to OpenSSL on April 1, 2014. Codenomicon (a Finnish security firm) had independently found it around the same time. OpenSSL prepared the patch and coordinated disclosure with major Linux distribution maintainers, Akamai, and several cloud providers who needed to deploy the fix before the vulnerability became public.

The April 7 disclosure was accompanied by the patch, a dedicated website (heartbleed.com) with a distinctive logo - the first major vulnerability to have its own brand identity - and clear guidance for server operators. The coordinated response meant that patches were available immediately, but deployment across the global internet took weeks. Sites had to patch OpenSSL, restart services, and then - critically - revoke and reissue their TLS certificates, since private keys may have been exposed.

Certificate revocation was a significant bottleneck. The major Certificate Authorities were not prepared for the volume of revocation requests from millions of affected sites. Certificate Revocation Lists and OCSP responses needed to be updated and distributed. Many sites patched OpenSSL but failed to reissue certificates, leaving them potentially vulnerable to attackers who had previously captured their private keys.

[WARNING]
The Heartbleed disclosure produced the first mainstream discussion of the open source maintenance problem. OpenSSL was the most critical cryptographic library in the internet, handling billions of HTTPS connections daily, and was maintained by a small team with extremely limited resources. At the time of Heartbleed, OpenSSL's core development team received approximately $2,000 per year in donations. The Core Infrastructure Initiative was formed in response - a Linux Foundation program to fund critical open source security infrastructure. The discussion of underfunded critical infrastructure that Heartbleed started remained unresolved through the Log4Shell era, when the same pattern of widely deployed, volunteer-maintained software with limited security review appeared again.

Was It Exploited Before Disclosure?

The question of whether Heartbleed was exploited in the wild before the April 7 disclosure was investigated by multiple parties. Errata Security's Robert Graham conducted internet-wide scans the day of the disclosure and found approximately 600,000 servers still vulnerable. Analysis of server access logs for Heartbleed-pattern requests found nothing definitively conclusive from before the disclosure date - but Heartbleed left no log traces in default configurations, so absence of evidence in logs was not evidence of absence.

The Canada Revenue Agency disclosed in April 2014 that approximately 900 social insurance numbers had been stolen from its website through Heartbleed exploitation after the public disclosure. This was the first publicly confirmed exploitation resulting in concrete data theft, and it came after the vulnerability was public - the attackers used published information.

A 2014 analysis by security firms examining network traffic from the months before disclosure did not find conclusive evidence of widespread pre-disclosure exploitation. The technical capability to exploit Heartbleed was not difficult, but the vulnerability's existence was not known publicly until April 7. The two-year window of potential exploitation before disclosure remained an open question.

Legacy: Certificate Transparency and Open Source Security

Heartbleed's legacy falls into two categories. First, it accelerated Certificate Transparency - a system requiring that all issued TLS certificates be logged to public append-only logs, making it possible for site owners to detect unauthorized certificate issuance. If an attacker used a stolen private key to get a new certificate issued, the unauthorized issuance would appear in the CT log.

Second, it catalyzed funding for critical open source security infrastructure. The Core Infrastructure Initiative, the Open Source Security Foundation, and various vendor-sponsored security audit programs all trace partially to the Heartbleed wake-up call. The narrative - that free software millions of organizations depended on was being maintained with almost no resources - was sufficiently alarming to motivate corporate and government investment in open source security that had previously been absent.

[IOC]
Heartbleed detection and response: Vulnerable versions: OpenSSL 1.0.1 through 1.0.1f and 1.0.2-beta. Detection: multiple tools were published for testing; the Heartbleed test (filippo.io/heartbleed) was the most widely used at disclosure time. Network detection: Heartbleed requests produce distinctive TLS heartbeat extension traffic with large claimed payload lengths - IDS signatures were released by Snort and Suricata within hours of disclosure. Response checklist: (1) Patch OpenSSL to 1.0.1g or later. (2) Restart all services using OpenSSL. (3) Revoke existing TLS certificates. (4) Generate new private keys (do not reuse the potentially compromised key). (5) Request new certificates from CA. (6) Invalidate active user sessions (session tokens in memory may have been exposed). (7) Advise users to change passwords. Historical note: as of 2024, Shodan and other scanners still find servers vulnerable to Heartbleed - primarily embedded devices and old systems that have never been updated.