What happened
In April 2014 researchers found a flaw in OpenSSL, the library that secures most of the web. The bug lived in a small, friendly feature called the TLS heartbeat. A heartbeat lets one side say "are you still there?" and get the same message echoed back.
The attacker sends a heartbeat that claims to carry 64 kilobytes of data but actually carries one byte. OpenSSL trusted that number. It copied 64 kilobytes out of memory and sent it back, including whatever happened to be sitting next to the request.
That memory held real things. Other users' passwords. Session cookies. And in the worst cases the server's private TLS key, the one secret that protects every connection. Anyone on the internet could ask for it, over and over, and the server saw nothing wrong.
The bug, in one line
The code read a length that the attacker controlled and used it to copy memory, without ever checking that the request actually contained that many bytes. A single bounds check was missing.
That is the whole bug. Not a clever exploit chain. One number, trusted when it should have been verified.
// payload length comes straight from the attacker
unsigned int payload = get_length(request);
// no check that the request really holds `payload` bytes
memcpy(response, request_data, payload); // <- over-read
send(response, payload); // <- leaks server memoryWhy it was so bad
Three things made Heartbleed a nightmare. It needed no authentication, so anyone could run it. It left no trace, so you could not tell from your logs whether you had been hit. And it leaked the private key, which meant attackers could decrypt past traffic and impersonate the site even after a patch.
Patching the library was step one. The real work was rotating every key and certificate and forcing every user to log in again, because you had to assume the secrets were already gone.
Why scanners walked right past it
Heartbleed did not show up as a broken header or an obvious error page. It lived deep inside a trusted dependency, behind the TLS handshake, and it only revealed itself in what the server sent back on the wire.
You could not spot it by reading the homepage. You had to look at the actual bytes a live connection returned, and notice that some of them should never have left the building.
How it unfolded
- Dec 2011The heartbeat code ships in OpenSSL. The flaw is live and unnoticed.
- Apr 1, 2014Google and Codenomicon independently find the bug days apart.
- Apr 7, 2014Public disclosure. A patched OpenSSL lands the same day.
- Apr 2014A global scramble to patch, revoke certificates, and rotate keys.
Where buggy.run fitsHeartbleed was a leak you could only see in the traffic, not in the page. That is exactly the gap buggy.run is built to close.
A buggy.run audit drives a real browser through your app, captures every request and response, and reads what actually comes back on the wire. Secrets that should never be in a response get flagged, and the TLS and dependency surface gets checked instead of assumed.
The lesson holds even if you never touched OpenSSL. The flaws that hurt most are the quiet ones in your responses and your dependencies, the ones a front-door scan never sees.
What to take away
- Treat any memory-disclosure bug as a full key compromise. Rotate keys and certificates, do not just patch.
- Keep an inventory of your dependencies so a library CVE does not become a week of guesswork.
- Watch what your responses actually return, not just what your pages render.
- Force re-authentication after any exposure that could have leaked sessions.
