Heartbleed Checker

Test for the Heartbleed vulnerability (CVE-2014-0160)

About

The Heartbleed Vulnerability Checker tests whether your server is vulnerable to the critical Heartbleed bug (CVE-2014-0160), a severe OpenSSL vulnerability that allowed attackers to read private memory from vulnerable servers. It sends a specially crafted heartbeat request to detect the vulnerability.

Heartbleed was one of the most significant security vulnerabilities in internet history, affecting approximately 17% of all SSL servers at the time of disclosure. While most servers have been patched, this tool verifies that your server is not still vulnerable.

How to Use

1Enter the domain name and port to test for Heartbleed vulnerability
2Click "Test for Heartbleed" to send the detection probe
3Review the results showing whether the server is vulnerable or patched
4If vulnerable, immediately update OpenSSL and restart all SSL services

Use Cases

•Vulnerability Assessment: Verify that servers are patched against the critical Heartbleed vulnerability
•Legacy System Check:** Test older systems that may not have received security updates

•Security Audit:** Provide evidence of Heartbleed remediation for compliance audits

•Incident Response:** Quickly assess exposure if Heartbleed indicators are detected

•Third-Party Assessment:** Check if services you depend on are vulnerable

How the Probe Works

Heartbleed was a flaw in how OpenSSL handled heartbeat requests, letting a client read up to 64KB of process memory per request. This page sends a heartbeat and inspects what comes back.

1Complete a handshake and send a heartbeat request, then read the response. The detection signal is simple: a server that leaked memory returns more data than the request asked for, while a correct one echoes exactly what was sent.

2Distinguish a TLS alert from a leaked response. A response beginning with a TLS alert record means the server rejected the heartbeat cleanly, which is the correct and safe behaviour. Anything longer than expected is treated as the leak signature.

3Report the negotiated protocol and a clear verdict, and say so plainly when the test could not be completed rather than defaulting to safe. TLS 1.3 removed heartbeats entirely, so a modern server is unaffected by construction.

The vulnerability was in the library, not the configuration: any server whose OpenSSL contained the bug was exposed with no setting to change. That is why remediation was patching rather than configuration, and why detection mattered so much at the time.

Tips & Best Practices

•If your server is vulnerable, treat it as a critical emergency — private keys may have been compromised

•After patching, revoke and reissue all certificates as private keys should be considered compromised

•Check all OpenSSL installations, not just the primary web server

•Monitor for any signs of past exploitation after patching

Technical Details

●CVE: CVE-2014-0160 (Heartbleed) detection

●Method:** Sends crafted TLS heartbeat request to detect memory leak vulnerability

●Affected:** OpenSSL 1.0.1 through 1.0.1f

●Patch:** Fixed in OpenSSL 1.0.1g and later versions

Frequently Asked Questions

Use this tool to test your server. If vulnerable, your private keys should be considered compromised. Check your OpenSSL version — versions 1.0.1 through 1.0.1f are affected. Even if patched now, review logs for signs of past exploitation.

Immediately update OpenSSL to a patched version, restart all SSL services, revoke and reissue all certificates (since private keys may be compromised), change all passwords and secrets, and review logs for signs of past exploitation.

While most servers have been patched, some legacy systems remain vulnerable. Additionally, private keys compromised during the Heartbleed period may still be in attacker hands. Always verify patch status and consider certificate reissuance.

Only as a check that legacy systems were never left exposed. The bug was fixed in April 2014 and no new affected versions have appeared, so a current server is unaffected. It still matters for equipment nobody patched — old routers, printers, embedded devices and long-lived appliances frequently froze their firmware and remain vulnerable years later, and those are exactly the systems nobody remembers to check.

Because the flaw was in how OpenSSL validated the heartbeat length before copying memory, which happens on every request the library handled. There was no setting to disable, no cipher to remove and no way to avoid the code path — the only remedy was patching the library. That is unusual, and it is why the response was an emergency rather than a planned change.

Whatever was in the server process's memory: private keys, session keys, and anything the application held in memory such as credentials or request data. Because the read was of live process memory rather than a stored artefact, the contents varied per request, which made a single observation insufficient for reliable extraction but a great many sufficient.

Because the protocol itself was functioning as specified, and detecting the leak requires noticing that more data arrives than was sent. There was no error, no log entry and no visible symptom on the server. It surfaced only when researchers noticed unexplained memory disclosure and started asking why — which is a reminder that protocol-correct-looking behaviour is not the same as correct behaviour.

You cannot patch it if it is vendor-controlled, so you reduce exposure instead: place it behind a firewall, prevent direct access from untrusted networks, and disable the service if it is not needed. A second option is terminating TLS at something you do control so the vulnerable service is never exposed. Where patching is possible, apply the vendor update and then verify rather than assuming.

Related Tools

Vulnerability Checkers Heartbleed Checker SSL Test SSL Scanner Certificate Detail SSL Report