WebBuilding

Events and eras

Heartbleed (2014)

Summary

Heartbleed (CVE-2014-0160) was a flaw in the OpenSSL encryption library, made public on April 7, 2014, that let anyone connected to a vulnerable server or client read up to 64 KB of its memory at a time, exposing private keys, passwords and other data. It affected OpenSSL 1.0.1 to 1.0.1f, released from March 2012, and was fixed in OpenSSL 1.0.1g. Found independently by Google's Neel Mehta and engineers at Codenomicon, it led to mass certificate replacement and password resets and to the Core Infrastructure Initiative, an industry fund for critical open-source projects.

What Heartbleed was

Heartbleed is the popular name of CVE-2014-0160, a security flaw in OpenSSL that was made public on April 7, 2014.12 A CVE number is the standard identifier given to a publicly known security flaw. OpenSSL is free, open-source software that many servers and programs use to provide the encryption behind HTTPS and TLS.32

The flaw was in OpenSSL’s handling of the TLS heartbeat extension, a small feature for checking that the other side of a connection is still there.14 A missing check let a connected client or server read up to 64 KB of the other machine’s memory at a time.1 The US National Vulnerability Database describes it as a buffer over-read, “as demonstrated by reading private keys.”5

That memory could hold almost anything the software was handling. Codenomicon’s researchers warned that it could expose the secret keys a site uses to prove its identity and encrypt traffic, user names and passwords, and the content of messages and documents.2 US-CERT, the US government’s computer emergency team, listed user names and passwords among the data at risk.6

Only some OpenSSL versions were affected: 1.0.1 through 1.0.1f, and the 1.0.2 beta releases.17 Older branches, 1.0.0 and 0.9.8, never had the bug.2 OpenSSL 1.0.1g, released on April 7, 2014, fixed it.8

As of October 22, 2026, the National Vulnerability Database rates the flaw 7.5 out of 10 (high) under CVSS 3.1, the common scoring system for security flaws, and 5.0 (medium) under the older CVSS 2.0.5 The US Cybersecurity and Infrastructure Security Agency added it to its catalog of known exploited vulnerabilities on May 4, 2022.5

The heartbeat extension and the missing check

The heartbeat extension is defined in RFC 6520, published by the IETF in February 2012. Its authors were Robin Seggelmann and Michael Tuexen of Muenster University of Applied Sciences and Michael Glenn Williams of GWhiz Arts and Sciences.4 An RFC (Request for Comments) is a numbered internet standards document.

The extension had two jobs. It let either side of a TLS connection check that the other was still alive without starting the expensive handshake again, and it gave DTLS, the version of TLS used over connection-less networks, a way to probe how large a packet the network path could carry.4

A heartbeat works like an echo. One side sends a request containing some arbitrary data, called the payload, along with a field stating the payload’s length. The RFC says the receiver must answer with a response “carrying an exact copy of the payload.”4 It also says that if the stated length is too large, the message must be discarded silently.4

OpenSSL’s code did not make that check. It trusted the length field instead of comparing it with the amount of data that had really arrived, so it could copy whatever sat next to the payload in memory into its reply.15 The OpenSSL advisory called the cause a missing bounds check, meaning the code never tested whether the requested amount stayed within the data it had.1

Several things made the flaw serious:

  • It was repeatable. The 64 KB limit applied to a single heartbeat, and a connection could ask again and again or reconnect for more.2
  • It left no trace. Codenomicon’s researchers wrote that using the bug did not leave anything abnormal in the logs.2
  • It worked both ways. Servers were the main concern, but client software that used a vulnerable OpenSSL could leak its own memory to a malicious server.21

The heartbeat code was submitted to OpenSSL by Seggelmann and reviewed by an OpenSSL developer before it was committed.9 According to Codenomicon, the bug entered OpenSSL in December 2011 and reached users with OpenSSL 1.0.1 on March 14, 2012.28 Seggelmann, whom the Sydney Morning Herald identified as the developer, later denied adding the error on purpose and called it a simple programming error in a new feature.10

Discovery and disclosure

Two teams found the bug independently. Neel Mehta of Google Security reported it to the OpenSSL team first, and three engineers at the security testing company Codenomicon found it while improving the SafeGuard feature of the company’s Defensics testing tools.21

A 2014 study by researchers at the University of Michigan, the University of Illinois at Urbana-Champaign, the University of California, Berkeley, the International Computer Science Institute and Purdue University pieced together the timeline:11

Date (2014)Event
March 21Mehta finds the bug and Google patches its own servers
March 31CloudFlare is privately told and patches
April 1Google notifies the OpenSSL core team
April 2Codenomicon finds the bug independently
April 3Codenomicon informs the National Cyber Security Centre Finland (NCSC-FI)
April 4Akamai is privately told and patches
April 7OpenSSL releases 1.0.1g and its advisory

Sources differ by one day on Codenomicon’s find. The study gives April 2, while Codenomicon’s own Heartbleed site refers to “our discovery of the bug on 3rd of April 2014.”112

The fix itself was short: a bounds check added to the heartbeat code, with the same wording as the advisory.12 OpenSSL’s change log credits the fix to Adam Langley and Bodo Moeller.81 For anyone who could not upgrade at once, the advisory gave a workaround: rebuild OpenSSL with heartbeats switched off.1 The 1.0.2 branch was fixed in 1.0.2-beta2.1

Codenomicon published its findings on a dedicated website, heartbleed.com, with a question-and-answer guide and a bleeding-heart logo whose rights it waived under CC0, a public-domain dedication.2

How far it reached

OpenSSL sat underneath a large share of the web. Codenomicon pointed out that the Apache HTTP Server and Nginx, two web servers that commonly use OpenSSL, together ran on over 66% of active sites in Netcraft’s April 2014 survey.2 Vulnerable OpenSSL versions shipped in widely used operating systems, including Debian Wheezy, Ubuntu 12.04.4 LTS, CentOS 6.5, Fedora 18, OpenBSD 5.3 and 5.4, and FreeBSD 10.0.2

Early estimates of the damage varied because they measured different things:

  • Netcraft, April 7, 2014. The heartbeat extension was switched on at 17.5% of SSL sites, about half a million certificates from trusted certificate authorities. This counted sites with the feature switched on across Netcraft’s whole SSL survey.13
  • The 2014 measurement study. An estimated 24% to 55% of HTTPS sites in the Alexa Top 1 Million, a list of the most visited sites, were vulnerable at disclosure. The low end came from survey data on the TLS versions and server software sites used, and the high end assumed that every site with heartbeats switched on and vulnerable server software was exposed.11

Google said on April 9, 2014 that it had patched services such as Search, Gmail and YouTube, and that all versions of Android were immune except Android 4.1.1.14

The study found no sign of attack attempts before disclosure on the four networks it monitored, which included a honeypot, a decoy server set up to attract attackers. The first attack attempt it saw came about 21.5 hours after disclosure, and it recorded 5,948 attempts from 692 hosts.11

The best-known confirmed theft came from Canada. The Canada Revenue Agency took its online services offline on April 8, 2014 and restored them on April 14. It then reported that the Social Insurance Numbers of about 900 taxpayers had been removed from its systems during a six-hour period.15

The response: patches, certificates and passwords

Large sites patched within hours. All but 5 of the Alexa Top 100 sites were patched within 24 hours, and every vulnerable host in the top 500 within 48 hours.11 The long tail was slower: two days after disclosure, about 11% of HTTPS sites in the top million were still vulnerable, and patching leveled off after about two weeks with about 3% still exposed almost two months later.11

The researchers also sent warnings to network operators in two rounds, on April 28 and May 7, 2014. Eight days after the first round, 39.5% of the notified operators had patched, against 26.8% of those not yet told, a 47% increase.11

Replacing certificates

Patching stopped new leaks, but it could not take back a private key that had already been copied. US-CERT advised that any keys generated with a vulnerable OpenSSL should be considered compromised and regenerated.6 Codenomicon advised site owners to revoke their old certificates, get new ones and treat all session keys and session cookies as compromised.2 A certificate is revoked when its issuer publishes that it should no longer be trusted.

At first it was unclear whether private keys could really be pulled out. CloudFlare set up a public challenge server, and on April 11, 2014, software engineer Fedor Indutny, and about 50 minutes later Ilkka Mattila of NCSC-FI, both proved they had extracted its private key.16 CloudFlare then revoked and reissued every certificate it managed.17

Revocation lists grew quickly. CloudFlare said GlobalSign’s certificate revocation list grew from about 22 KB to about 4.7 MB after CloudFlare’s reissue, and estimated the extra download traffic at about 40 Gbps.18 The study counted 56,353 revocations by GlobalSign in two days and 243,823 by GoDaddy over about three months.11

Many sites still did not finish the job. Of the Alexa Top 1 Million sites still vulnerable two days after disclosure, only 10.1% replaced their certificates within a month. Of those, 19% also revoked the old certificate, and 14% reused the same private key, which left the risk in place.11 Revocation was also imperfect on the browser side: Netcraft reported that Chrome did not check revocation for ordinary (non-EV) certificates by default and relied on Google’s own aggregated lists, called CRLSets, which did not yet include GlobalSign’s Heartbleed revocations.19

Changing passwords

Because user names and passwords could leak, the response reached ordinary users too.62 A Pew Research Center survey of 1,501 US adults, taken April 23 to 27, 2014, found that 64% of internet users had heard about Heartbleed, 39% had changed passwords or canceled accounts, and 6% believed their personal information had been stolen.2021

Forward secrecy

Heartbleed also drew attention to forward secrecy, a property of a connection’s key exchange that stops a stolen key from decrypting traffic recorded earlier. The study found that only 44% of the connections it observed in May 2014 used it.11 TLS 1.3, published in 2018, removed the key exchange methods that lacked it, so “all public-key based key exchange mechanisms now provide forward secrecy.”22

Funding open-source security

Heartbleed showed how little money supported software that much of the internet relied on. In April 2014, Steve Marquess, president of the OpenSSL Software Foundation, wrote on his blog that the foundation typically received about US$2,000 a year in outright donations, and that only one team member, Stephen Henson, worked on OpenSSL without conventional full-time outside employment.2324 The post added that about 200 donations in the week after the news came to about US$9,000, and argued there should be at least six full-time team members.23

On April 24, 2014, the Linux Foundation launched the Core Infrastructure Initiative (CII), a multimillion-dollar fund for open-source projects that core internet services depend on. Its founding backers were Amazon Web Services, Cisco, Dell, Facebook, Fujitsu, Google, IBM, Intel, Microsoft, NetApp, Rackspace and VMware, and OpenSSL was its first project.25

On May 29, 2014, the initiative added Adobe, Bloomberg, HP, Huawei and salesforce.com as backers. It named the Network Time Protocol, OpenSSH and OpenSSL for its first round of funding, including two full-time core developers for OpenSSL and a security audit of the OpenSSL code by the Open Crypto Audit Project.26

Others chose to fork the code, meaning they copied it to develop separately. In April 2014, developers of the OpenBSD operating system started LibreSSL, a fork of OpenSSL that eWeek described as a direct response to Heartbleed.27 As of October 2026, the LibreSSL project describes its aims as modernizing the codebase, improving security and applying best-practice development processes.28

The funding effort continued under new names. On August 3, 2020, the Linux Foundation announced the Open Source Security Foundation (OpenSSF), which brought together the CII, which it described as “founded in response to the 2014 Heartbleed bug,” GitHub’s Open Source Security Coalition and other work.29 On February 1, 2022, the OpenSSF announced Alpha-Omega, backed by an initial $5 million from Microsoft and Google, to work directly with the most critical projects and to scan at least 10,000 widely used ones.30 As of October 2026, Alpha-Omega reports an annual budget of over $7 million.31

What changed in OpenSSL

OpenSSL later removed the feature that caused the bug. OpenSSL 1.1.0, released on August 25, 2016, dropped heartbeat support for TLS and turned it off by default for DTLS. OpenSSL 1.1.1, released on September 11, 2018, removed heartbeat support entirely.32

The 1.0.1 branch received its last release, 1.0.1u, on September 22, 2016.8 As of October 22, 2026, OpenSSL lists versions 1.1.0, 1.0.1, 1.0.0 and 0.9.8 as no longer supported (and 3.0, 1.1.1 and 1.0.2 as unsupported apart from paid extended support), and names version 3.5 as a long-term support release supported until April 8, 2030.33 Since version 3.0, OpenSSL has been released under the Apache License.3

Timeline

  1. CISA adds CVE-2014-0160 to its catalog of known exploited vulnerabilities5
  2. OpenSSF announces Alpha-Omega with $5 million from Microsoft and Google30
  3. Open Source Security Foundation brings together the Core Infrastructure Initiative and other efforts29
  4. OpenSSL 1.1.1 removes heartbeat support entirely32
  5. OpenSSL 1.1.0 drops heartbeats for TLS32
  6. Core Infrastructure Initiative funds two full-time OpenSSL developers and an audit26
  7. Linux Foundation launches the Core Infrastructure Initiative, with OpenSSL first25
  8. Researchers extract the private key from CloudFlare's Heartbleed challenge server16
  9. Canada Revenue Agency takes its online services offline15
  10. OpenSSL releases 1.0.1g and discloses CVE-2014-01608
  11. Google notifies the OpenSSL core team11
  12. Neel Mehta of Google finds the bug11
  13. OpenSSL 1.0.1 ships with heartbeat support8
  14. RFC 6520 defines the TLS and DTLS heartbeat extension4

What it means for your website

Heartbleed was not a mistake by website owners. It was a flaw in shared server software, and the sites that came through best were the ones that could update fast. The same lessons apply to any server flaw today.

  • Know who patches your server. On a hosted builder or managed web hosting, the provider updates OpenSSL and the web server for you. In 2014, all but 5 of the 100 most visited sites patched within a day, while about 3% of popular HTTPS sites were still exposed two months later.11 On a virtual private server, that update is your job.
  • Use a supported version. As of October 22, 2026, OpenSSL 1.0.1, the branch Heartbleed hit, has been unsupported for years, and 3.5 is the long-term release supported until April 8, 2030.33 Ask your host which version runs under your site.
  • Replace keys after a leak, not only software. A patch stops new leaks but does not undo old ones. After Heartbleed, US-CERT said affected keys should be regenerated,6 and 14% of sites that did replace a certificate reused the same private key.11 If your host reports a key exposure, get a new certificate with a new key and revoke the old one.
  • Log users out and reset passwords. Codenomicon advised treating all session cookies as compromised.2 On WordPress or any site with logins, that means forcing users to sign in again and asking them to change passwords.
  • Keep TLS modern. TLS 1.3 provides forward secrecy for every public-key key exchange, which limits what a stolen key can reveal.22

Our SSL certificate glossary entry explains certificates in brief, and our guide to domains and hosting lists what to ask a host about updates and security before you sign up.

See also

References

  1. OpenSSL Security Advisory [07 Apr 2014]: TLS heartbeat read overrun (CVE-2014-0160). OpenSSL Project. 2014-04-07. accessed October 22, 2026.
  2. The Heartbleed Bug. Codenomicon, heartbleed.com (now maintained by Black Duck). accessed October 22, 2026.
  3. OpenSSL Library. OpenSSL Project. accessed October 22, 2026.
  4. RFC 6520: Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) Heartbeat Extension. Internet Engineering Task Force, RFC Editor. 2012-02. accessed October 22, 2026.
  5. CVE-2014-0160 Detail. National Vulnerability Database, NIST. accessed October 22, 2026.
  6. OpenSSL 'Heartbleed' vulnerability (CVE-2014-0160), alert TA14-098A. US-CERT, Cybersecurity and Infrastructure Security Agency. 2014-04-08. accessed October 22, 2026.
  7. Vulnerabilities fixed in OpenSSL 1.0.1. OpenSSL Project. accessed October 22, 2026.
  8. OpenSSL CHANGES file, OpenSSL_1_0_1-stable branch. OpenSSL Project, GitHub. accessed October 22, 2026.
  9. Support for TLS/DTLS heartbeats (commit 4817504). OpenSSL Project, GitHub. accessed October 22, 2026.
  10. 'Heartbleed' Bug Coder: 'It was a simple programming error'. NBC News. accessed October 22, 2026.
  11. The Matter of Heartbleed. Zakir Durumeric, Frank Li, James Kasten, Johanna Amann, Jethro Beekman, Mathias Payer, Nicolas Weaver, David Adrian, Vern Paxson, Michael Bailey and J. Alex Halderman, ACM Internet Measurement Conference (IMC 2014), Vancouver. 2014-11. accessed October 22, 2026.
  12. Add heartbeat extension bounds check (commit 96db902). OpenSSL Project, GitHub. accessed October 22, 2026.
  13. Half a million widely trusted websites vulnerable to Heartbleed bug. Paul Mutton, Netcraft. 2014-04-07. accessed October 22, 2026.
  14. Google Services Updated to Address OpenSSL CVE-2014-0160 (the Heartbleed bug). Matthew O'Connor, Google Online Security Blog. 2014-04-09. accessed October 22, 2026.
  15. Confirmed Heartbleed victim: Canada Revenue Agency. Help Net Security. 2014-04-14. accessed October 22, 2026.
  16. The Results of the CloudFlare Challenge. Nick Sullivan, Cloudflare Blog. 2014-04-11. accessed October 22, 2026.
  17. The Heartbleed Aftermath: all CloudFlare certificates revoked and reissued. Nick Sullivan, Cloudflare Blog. 2014-04-17. accessed October 22, 2026.
  18. The Hidden Costs of Heartbleed. Matthew Prince, Cloudflare Blog. 2014-04-17. accessed October 22, 2026.
  19. Chrome users oblivious to Heartbleed revocation tsunami. Netcraft. accessed October 22, 2026.
  20. Heartbleed's Impact. Lee Rainie and Maeve Duggan, Pew Research Center. 2014-04-30. accessed October 22, 2026.
  21. Heartbleed's Impact: Main findings. Lee Rainie and Maeve Duggan, Pew Research Center. 2014-04-30. accessed October 22, 2026.
  22. RFC 8446: The Transport Layer Security (TLS) Protocol Version 1.3. Internet Engineering Task Force, RFC Editor. 2018-08. accessed October 22, 2026.
  23. Of Money, Responsibility, and Pride. Steve Marquess, Veridical Systems blog. accessed October 22, 2026.
  24. Heartbleed: A Wakeup Call for Open Source Users (Updated). John K. Waters, WatersWorks blog, ADTmag. 2014-04-28. accessed October 22, 2026.
  25. Tech Titans Launch Core Infrastructure Initiative to Secure Key Open Source Components. Fahmida Y. Rashid, SecurityWeek. 2014-04-24. accessed October 22, 2026.
  26. The Linux Foundation's Core Infrastructure Initiative Announces New Backers, First Projects to Receive Support and Advisory Board Members. The Linux Foundation. 2014-05-29. accessed October 22, 2026.
  27. After Heartbleed, OpenSSL Is Forked Into LibreSSL. Sean Michael Kerner, eWeek. 2014-04-22. accessed October 22, 2026.
  28. LibreSSL. OpenBSD Project, libressl.org. accessed October 22, 2026.
  29. Technology and Enterprise Leaders Combine Efforts to Improve Open Source Security. The Linux Foundation. 2020-08-03. accessed October 22, 2026.
  30. OpenSSF Announces the Alpha-Omega Project to Improve Software Supply Chain Security for 10,000 OSS Projects. Open Source Security Foundation. 2022-02-01. accessed October 22, 2026.
  31. Alpha-Omega. Alpha-Omega, an associated project of the Open Source Security Foundation. accessed October 22, 2026.
  32. OpenSSL CHANGES file, OpenSSL_1_1_1-stable branch. OpenSSL Project, GitHub. accessed October 22, 2026.
  33. Release Strategy. OpenSSL Project. accessed October 22, 2026.

Web Building Encyclopedia. First published October 22, 2026. Last reviewed October 22, 2026. Every fact on this page is linked to a source we opened. Spotted an error? Write to [email protected].