Heartbleed
Heartbleed (CVE-2014-0160) is an information disclosure vulnerability in the TLS and DTLS heartbeat extension handling in OpenSSL 1.0.1 through 1.0.1f, fixed in 1.0.1g. The flaw is caused by a missing bounds check when processing crafted Heartbeat Extension packets, resulting in a buffer over-read/heap over-read in code associated with d1_both.c and t1_lib.c. A remote attacker can send a malformed heartbeat request with an invalid payload length and cause the vulnerable peer to return up to 64 KB of process memory per request. Both TLS servers and TLS clients using affected OpenSSL versions can be targeted, depending on which side processes the malicious heartbeat message.
Are you exposed to this one?
Mallory correlates every CVE against your assets, your vendors, and active adversary campaigns. Know which vulnerabilities matter for you, not just which ones are loud.
Impact, mitigation & remediation
What it means. What to do now. Patch path, mitigations, and the assume-compromise checklist.
Impact
What an attacker gets, and what they’ve been doing with it.
Mitigation
If you can’t patch tonight, do this now.
Remediation
Patch, then assume compromise.
Exploits
16 valid exploits after Mallory filtered fakes, detection scripts, and README-only repos (15 hidden).
This repository is a small educational Heartbleed lab that reproduces CVE-2014-0160 in Docker. The main exploit logic is in client/attacker.py, a Python 2 script that opens a raw TCP socket to vulnerable-server:4433, sends a handcrafted TLS ClientHello, parses TLS records until ServerHelloDone is observed, and then transmits a malformed heartbeat record. The malicious heartbeat declares a payload length of 0x4000 while only supplying a single byte, matching the classic Heartbleed condition where the server trusts the claimed length and returns extra memory. If exploitation succeeds, the script prints the leaked bytes in hex and raw form. Repository structure is straightforward: client/ contains the exploit script and a Dockerfile for an Ubuntu 14.04-based attacker container; vulnerable/ contains a Dockerfile that downloads and compiles OpenSSL 1.0.1f from source, generates a self-signed certificate, and launches openssl s_server on port 4433; docker-compose.yml wires both containers together on an internal Docker network. fixed/Dockerfile exists but is empty, so there is no implemented patched comparison target yet. README.md documents the lab goals, architecture, and usage. This is a real exploit PoC rather than a detector. It does not deliver code execution; its capability is memory disclosure from a vulnerable TLS server. The exploit is operational but basic: target host and port are hardcoded, the handshake is minimally parsed, and the payload is fixed rather than user-configurable.
This repository is a real Heartbleed proof-of-concept and lab environment centered on CVE-2014-0160. It contains two main components: (1) a vulnerable service build under service/heartbleed and src, and (2) a Python exploit under solution/exploit.py. The exploit is a standalone Python 2 script derived from the classic SensePost/Jared Stafford Heartbleed PoC. It opens a TCP connection to a target, sends a crafted TLS ClientHello, parses the ServerHello/handshake completion, then sends malformed heartbeat requests for TLS 1.0/1.1/1.2 and writes any over-read memory to a local dump file. It can also negotiate SMTP STARTTLS before sending the TLS heartbeat, so it is not limited strictly to HTTPS. The repository is more than a generic PoC: it provides a custom CTF/lab target. Both Dockerfiles build Ubuntu 14.04 images with OpenSSL 1.0.1f and Apache 2.4.10. The included t1_lib.c replaces the OpenSSL heartbeat implementation with a modified version intended to make exploitation reliable in a challenge setting. Per the README, the original memcpy-based nondeterministic memory disclosure was altered so that 10% of heartbeat responses intentionally embed the server private key read from /usr/local/apache2/conf/ssl/server.key. This means the exploit’s practical capability in this repo is memory disclosure leading to private-key recovery, not code execution. Repository structure: README.md explains lab setup and the custom patch; solution/exploit.py is the main exploit entry point; service/heartbleed contains a prebuilt-style lab with bundled certificate and private key; src contains an alternate build path that generates its own self-signed certificate and includes flag.html. The HTML files are challenge content only. The included server.key is an actual private key used by the lab. Overall purpose: provide a reproducible vulnerable Heartbleed environment and a working exploit script that demonstrates remote TLS memory disclosure and, in this custom lab, recovery of sensitive key material.
Repository purpose: a Dockerized lab environment to demonstrate CVE-2014-0160 (Heartbleed) memory disclosure against an nginx HTTPS endpoint compiled with OpenSSL 1.0.1. Key components: - Dockerfile: Builds OpenSSL 1.0.1 from source, then builds nginx 1.16.1 with --with-http_ssl_module and links it against the vulnerable OpenSSL tree. Generates a self-signed cert and exposes port 8443. - vuln/nginx.conf: SSL virtual host on 8443, reverse-proxies to a local Flask app at http://127.0.0.1:5000. Adds a distinctive header (X-CTF-FLAG) and enables buffering settings that can help keep request data in memory. - vuln/app.py (+ vuln/.env): Flask app that on POST sets an HttpOnly+Secure cookie 'session_secret' containing user input plus a server-side FLAG from environment. This creates sensitive material in process memory that can be leaked. - vuln/start.sh: Installs Python deps, starts nginx, then runs Flask. - examples/memory.py: Helper script that sends an HTTPS POST to https://localhost:8443/ with a recognizable cookie value to ‘seed’ memory for easier identification in leaked dumps. - examples/example_dump.txt and examples/result.txt: Sample hexdumps of heartbeat responses showing the classic ‘server returned more data than it should’ indicator; result.txt demonstrates leaking a FLAG-like string. - snort rules/alert.rules: Simple IDS signature matching TLS heartbeat record header bytes (|18 03 02 00|) on tcp/443 (note: lab listens on 8443, so rule would need port adjustment for this environment). Exploit capability: remote, unauthenticated memory disclosure via crafted TLS heartbeat requests to the nginx/OpenSSL service on 8443. The repo itself does not include heartbleed.py; it references an external gist for the actual heartbeat exploit script, while providing the vulnerable target and supporting artifacts to demonstrate leakage.
Repository contains a single Python exploit script plus README and MIT license. The main file, `CTT-HEARTBLEED v2.py`, implements a network-based Heartbleed (CVE-2014-0160) memory disclosure against TLS services (default TCP/443) by crafting and sending malformed TLS Heartbeat records after establishing an SSL/TLS connection with certificate verification disabled. The script repeatedly sends heartbeat requests and reads up to ~128KB per response (`recv(65536*2)`), extracting the post-header bytes as leaked memory chunks. The code adds extensive “CTT/temporal resonance” theming: it varies requested heartbeat lengths per “layer” using a sine modulation, introduces timing delays and prime-aligned waits, and applies a byte-level transformation to parts of the payload. It maintains a `memory_map` keyed by layer and computes a “resonance score” for each chunk (intended to prioritize structured/secret-like data). The README claims additional capabilities (entropy scoring, secret detection, JSON reports, and saving `heartbleed_secret_*.bin`), and the script’s main routine runs a multi-layer extraction (example shows `num_layers=7`) and prints statistics and vulnerability confirmation. Overall purpose: an operational PoC/utility to exploit Heartbleed for remote memory extraction with repeated requests and basic post-processing/scoring to help identify high-value leaked data. No hardcoded C2 infrastructure is present; the only network target is the user-specified host/port.
This repository is an educational project demonstrating the Heartbleed vulnerability (CVE-2014-0160) in OpenSSL. It contains five files: a Dockerfile that builds a vulnerable Debian Jessie server with OpenSSL 1.0.1e and Apache configured for SSL; a Python script (heartbleed.py) that implements a proof-of-concept exploit for Heartbleed; a shell script (run.sh) to automate building the environment, running the server, and executing the exploit; a README.md with project documentation; and a LaTeX essay explaining the vulnerability in detail. The exploit works by establishing a TLS connection to the target, sending a malicious Heartbeat request with an exaggerated payload length, and reading the server's response, which may contain sensitive memory contents. The main attack vector is network-based, targeting the server's TLS port (443, mapped to 8443 in Docker). The repository is structured for demonstration and educational purposes, not for operational exploitation.
This repository contains a Python proof-of-concept exploit for the Heartbleed vulnerability (CVE-2014-0160) in OpenSSL. The main exploit logic resides in 'python3 heartbleed_poc.py', which establishes a TLS connection to a specified host and port, performs a handshake, and sends a malicious heartbeat request to trigger the vulnerability. If the server is vulnerable, the script detects the leak and logs the leaked memory data. The script is configurable for target host, port, and TLS version. The repository also includes standard project files such as a README, MIT license, .gitignore, and a GitHub Actions workflow for linting. The exploit is a network-based PoC, does not include weaponized payloads, and is intended for educational and research purposes only.
This repository demonstrates a practical Heartbleed (CVE-2014-0160) attack against servers running vulnerable OpenSSL versions. The main exploit is implemented in Java (src/Heartbleed.java), which crafts and sends malformed TLS heartbeat requests to a target server (default: 192.168.1.132) on either port 443 (Apache) or 465 (Postfix). The exploit leverages the Heartbleed bug to extract up to 64KB of server memory per request, potentially exposing sensitive data such as credentials, password hashes, and SSL certificates. To maximize the impact and demonstrate the vulnerability, the repository includes Bash scripts (apache_memload.sh, postfix_memload.sh) and a PHP script (memload.php) that flood the server's memory with sensitive data. These scripts are intended to be run on the target server prior to executing the exploit, ensuring that leaked memory contains demonstrable secrets. The repository is well-documented, with a README.md detailing the attack methodology, prerequisites, usage instructions, and expected results. The exploit is operational and can be used to demonstrate the real-world impact of Heartbleed on unpatched systems. No framework is used; the exploit is standalone. The attack vector is network-based, requiring access to the target server's SSL/TLS ports. Several endpoints and file paths are fingerprintable, including the target IP, ports, and memory-flooding scripts.
This repository contains a Python script, HeartLeak.py, which is an exploit for the Heartbleed vulnerability (CVE-2014-0160) in OpenSSL. The script provides two main functionalities: 'scan', which generates random IP addresses, checks if they support SSL, tests them for the Heartbleed bug, and logs vulnerable hosts; and 'monitor', which repeatedly sends malicious heartbeat requests to a specified host, dumping any leaked memory data to both raw and printable text files. The exploit works by crafting a malformed TLS heartbeat request, causing vulnerable servers to return up to 64KB of memory, potentially exposing sensitive information. The script is operational and can be used to both identify and extract data from vulnerable OpenSSL servers. The repository is structured simply, with the main exploit logic in HeartLeak.py, a README describing usage, a .gitignore, and a license file.
This repository is a comprehensive toolkit for exploiting and detecting the Heartbleed vulnerability (CVE-2014-0160) in OpenSSL. It contains multiple scripts in Python, C, and Perl, each targeting different aspects of the vulnerability: - The majority of Python scripts (e.g., HeartLeak.py, fox_heartbleedtest.py, hb-test.py, heartbleed-altered.py, ssltest.py, ssltest-stls.py, sslreaper.py, heartdestroy.py, Heartbeat_scanner.py) are designed to test remote servers for Heartbleed by sending a malformed TLS heartbeat request and checking if the server leaks memory. Some scripts support mass scanning, multithreading, or outputting results to files. - heartbleed.c is a C implementation that can exploit the vulnerability and dump leaked memory to a file. It supports both client and server modes, allowing for exploitation of both vulnerable servers and clients. - pacemaker.py is a rogue server that targets vulnerable clients by waiting for them to connect and then sending malicious heartbeat requests to leak client memory. - hb_honeypot.pl is a Perl honeypot that listens on port 443 and simulates Heartbleed responses, logging scanning attempts. - maltego_heartbleedtest.py is a Maltego transform for integrating Heartbleed checks into the Maltego platform. The repository is well-structured, with each script focusing on a specific use case: server-side exploitation, client-side exploitation, mass scanning, honeypotting, or integration with other tools. The main attack vector is network-based, targeting TLS/SSL services (typically on port 443). The payload is a malformed heartbeat request that causes the target to leak memory, potentially exposing sensitive data. The toolkit is operational and can be used for both offensive security testing and defensive monitoring.
This repository provides multiple tools for detecting and exploiting the OpenSSL Heartbleed vulnerability (CVE-2014-0160). The main files are: - heartbleed-poc.py: A Python proof-of-concept exploit that sends malformed heartbeat requests to a target server, causing it to leak memory. It supports specifying the target port, number of requests, output file for dumped memory, and can test SMTP servers using STARTTLS. - openssl_heartbleed.rb: A Metasploit auxiliary module that automates the Heartbleed attack against a range of targets and protocols (including support for STARTTLS on SMTP, IMAP, POP3, FTP, and Jabber). It can be used for both detection and exploitation, and integrates with Metasploit's reporting features. - ssl-heartbleed.nse: An Nmap Scripting Engine (NSE) script for scanning servers for Heartbleed vulnerability. It is designed for mass scanning and reporting, not exploitation. The exploit works by sending a specially crafted TLS heartbeat request with an excessive payload length, causing vulnerable OpenSSL servers to respond with extra memory contents. This can expose sensitive data such as private keys, credentials, or session cookies. The tools support scanning and exploitation over various protocols and ports (notably 443 for HTTPS, 25 for SMTP, 21 for FTP, etc.). The repository is operational in maturity, providing both detection and exploitation capabilities, and is suitable for security testing of systems suspected to be vulnerable to Heartbleed.
This repository, 'openmagic', is a multi-script toolkit for automating the detection and exploitation of the OpenSSL Heartbleed vulnerability (CVE-2014-0160). The main exploit logic is implemented in 'ssltest.py', a Python script that sends a malformed TLS heartbeat request to a target server and checks if the server leaks memory in response, indicating vulnerability. The toolkit includes several Bash scripts: - 'ssltest.sh' automates testing of a single host and port, iterating multiple times and saving leaked data for analysis. - 'sslmail.sh' automates testing of all mail servers (MX records) for a given domain, targeting common SSL mail ports. - 'sslports.sh' scans a host for the top N most common SSL ports (as listed in 'internetcensus2012_ssl.txt') and tests each for Heartbleed. - 'common.sh' provides shared functions for DNS resolution, liveness checking (using nmap), and vulnerability testing. The toolkit is designed for batch and automated testing, supports outputting raw leaked data, and can route traffic through Tor for anonymity. It requires bash, python2.6, nmap, dig, torify, and tor. The exploit is operational and can be used to extract sensitive memory contents from vulnerable servers. No hardcoded IPs or domains are present; all targets are user-supplied. The repository is not part of a larger exploit framework.
This repository is a comprehensive demonstration environment for the Heartbleed vulnerability (CVE-2014-0160) in OpenSSL 1.0.1f. It is structured into three main Docker containers: 'heartbleed-server' (a vulnerable web server running a Flask app with Apache and OpenSSL 1.0.1f), 'heartbleed-hacker' (an attacker's desktop with a Python exploit script), and 'heartbleed-victim' (a victim's desktop). The main exploit is implemented in 'heartbleed-hacker/hacker.py', a Python script that sends malformed heartbeat requests to the server's SSL port and parses the leaked memory for session cookies. The server is configured with self-signed SSL certificates and exposes both HTTP and HTTPS endpoints, with HTTP redirecting to HTTPS. The exploit demonstrates how an attacker can extract session cookies from memory and use them to hijack authenticated sessions on the web application. The repository is intended for educational use, providing a hands-on lab for instructors and students to understand the impact of the Heartbleed bug. No fake or destructive code is present; the exploit is a faithful reproduction of the original Heartbleed attack.
This repository provides a working exploit for the Heartbleed vulnerability (CVE-2014-0160) in OpenSSL. The main exploit is implemented in 'heartbleed.py', a Python script that crafts and sends a malformed TLS heartbeat request to a target server, causing it to leak memory contents. The repository also includes a Dockerfile and instructions to set up a vulnerable server using an old version of OpenSSL (1.0.1e) on Debian Jessie, exposed via HTTPS on port 8443. The 'data_spoof/send_data.js' and 'misc/old_spoof.py' scripts generate large volumes of fake user data and send them to the server's login page, simulating user activity and populating server memory with credentials and payment data, which can then be extracted using the exploit. The repository structure includes web frontend files (HTML, CSS, JS) for the demo server, Docker setup for the vulnerable environment, and both Python and JavaScript code for exploitation and data spoofing. The exploit is operational and demonstrates real memory leakage from a vulnerable OpenSSL instance.
This repository is a comprehensive toolkit for exploiting the OpenSSL Heartbleed vulnerability (CVE-2014-0160). It consists of several Python scripts: - `hb.py`: The main exploit tool, which scans a target server for Heartbleed vulnerability, attempts to extract memory using the heartbeat exploit, and can operate in both unobtrusive (single-byte leak) and dump (bulk data extraction) modes. It supports multi-threading and can target both HTTPS and STARTTLS-enabled services. - `hblib.py`: A supporting library that implements the low-level TLS protocol logic, including crafting the ClientHello and Heartbeat messages, handling the handshake, and parsing responses. - `ciphers.py`: Contains a comprehensive list of TLS cipher suites and utilities for constructing the ClientHello message with all possible ciphers, maximizing compatibility and detection accuracy. - `keyscan.py`: Scans a memory dump (produced by `hb.py`) for RSA prime factors, using a provided certificate to extract the modulus and search for matching primes in the dump. - `keydump.py`: Given a memory dump and an offset (where a prime was found), reconstructs the full RSA private key and outputs it in PEM format. The toolkit is operational and can be used to: 1. Detect if a server is vulnerable to Heartbleed. 2. Extract memory from vulnerable servers, potentially leaking sensitive data. 3. Recover private keys from the memory dump if the necessary prime factors are found. The repository is well-structured, with clear separation between the exploit logic, protocol handling, and post-exploitation key recovery. It is written entirely in Python and is intended for educational and research purposes, as well as for responsible vulnerability assessment.
This repository provides a comprehensive set of tools for exploiting and testing the Heartbleed vulnerability (CVE-2014-0160) in OpenSSL. The main files are: - `heartbleed.py`: A Python script to test servers for the Heartbleed vulnerability. It supports multiple protocols (TLS, FTP, SMTP, IMAP, POP3) and allows customization of payload length, heartbeat count, and timeout. It connects to the target server, performs the necessary handshake, and sends a malicious heartbeat request to attempt to leak memory from the server. - `pacemaker.py`: A Python script that acts as a malicious server to test client implementations for Heartbleed. It listens for incoming client connections (e.g., from browsers, curl, wget, etc.), performs a partial TLS handshake, and sends crafted heartbeat requests to see if the client leaks memory. This is useful for testing client-side vulnerabilities. - `ssltest.py`: A standalone Python 2 script (by a different author) that demonstrates the Heartbleed exploit against servers. It is a more minimal implementation but achieves the same result: sending a malformed heartbeat request and checking if the server leaks memory. The repository is well-documented, with a detailed README explaining usage, tested clients and servers, and the technical background of the Heartbleed bug. The exploit is operational and can be used to confirm the presence of the vulnerability and demonstrate memory leakage from both clients and servers. The attack vector is network-based, targeting the TLS heartbeat extension over TCP. The scripts do not require authentication and can be used against any reachable vulnerable service. No hardcoded IPs or domains are present; the user specifies the target at runtime.
This repository is a proof-of-concept (PoC) exploit for the Heartbleed vulnerability (CVE-2014-0160) in OpenSSL. The main exploit file, 'heartbleed-exploit.py', is a standalone Python 2.7 script that establishes a TLS connection to a target server, sends a malformed heartbeat request, and attempts to extract up to 16KB of memory from the server. The exploit demonstrates the vulnerability by saving the leaked memory to 'out.txt'. The README provides background on Heartbleed, usage instructions, and references. The code is self-contained, with a small utility for colored terminal output. The exploit is operational against any server running a vulnerable version of OpenSSL and listening on a specified port (default 443). The only hardcoded endpoint is the demonstration server 'www.cloudflarechallenge.com', but the script accepts any hostname or IP as a target. No fake or destructive code is present; the exploit is a legitimate PoC for research and demonstration purposes.
Affected products & vendors
Products and vendors Mallory has correlated with this vulnerability. Open in Mallory to drill down to specific CPE configurations and version ranges.
Vendor-confirmed product mapping. Mallory continuously reconciles this list against your asset inventory.
Recent activity
48 sources tracked across advisories, community write-ups, and news. New activity surfaces here as Mallory finds it.
The OpenSSL Heartbleed vulnerability is referenced as an analogy/comparison point for CVE-2025-13834’s length-checking failure and resulting memory disclosure; it is not described as affecting the Redmi Buds directly in this content.
Heartbleed is a critical OpenSSL information disclosure vulnerability in TLS heartbeat handling that can leak up to 64 KB of process memory.
A critical information disclosure vulnerability in OpenSSL's implementation of the TLS/DTLS heartbeat extension, allowing attackers to read sensitive memory from affected servers.
A critical information disclosure vulnerability in OpenSSL, commonly known as Heartbleed, that can allow remote attackers to read sensitive memory contents such as secret keys, usernames, and passwords.
The version that knows your environment.
Query your assets running an affected version, and investigate the blast radius.
Every observed campaign linking this CVE to a named adversary.
Malware families riding this exploit, with evidence and IOCs.
YARA, Sigma, Snort, and vendor rules, auto-deployed to your SIEM.
Cross-references every affected SKU, including bundled OEM variants.
Community discussion across Reddit, Mastodon, and other social sources.