HTTP/2 Bomb DoS in Apache HTTP Server mod_http2

This repository is a small standalone Python proof-of-concept exploit consisting of a README and one executable script, h2bomb.py. The script implements a network-based HTTP/2 denial-of-service attack claimed to target CVE-2026-49975 in Apache HTTP Server mod_http2, though the README also states similar behavior was observed against other HTTP/2 servers. Structure and purpose: README.md documents the vulnerability, attack stages, usage examples, and expected errors. h2bomb.py is the sole exploit implementation and entry point. It uses Python threading plus the h2 library to create many concurrent TLS connections to a target and abuse HTTP/2/HPACK behavior. Main exploit flow in h2bomb.py: (1) create a TCP connection to the supplied host and port, wrap it in TLS, and negotiate ALPN 'h2'; (2) initialize an HTTP/2 connection and read server settings to determine MAX_CONCURRENT_STREAMS; (3) send a priming request to path '/' with a large custom header 'x-bomb' containing 4000 'A' characters to force HPACK-related allocation/state growth; (4) send a SETTINGS update setting INITIAL_WINDOW_SIZE to 0; (5) open as many additional streams as allowed by the server, each reusing the 'x-bomb' header name/value pattern to leverage HPACK compression-table references for amplification; (6) keep the connection alive indefinitely by periodically sending WINDOW_UPDATE frames every 5 seconds. Multiple AttackThread instances run in parallel, controlled by the -c/--connections argument. Capabilities: The exploit does not provide code execution, persistence, or data theft. Its sole capability is operational denial of service through resource exhaustion. It is more than a detector and includes an active payload, but the payload is hardcoded and purpose-built, so OPERATIONAL is the best fit. Notable observables: the target is user-supplied as host[:port], defaulting to TCP 443; the script always requests path '/'; it negotiates HTTP/2 via ALPN 'h2'; and it uses the custom header 'x-bomb' as the priming/amplification mechanism.

Repository contains a working Python proof-of-concept for CVE-2026-49975, a remote denial-of-service issue in Apache HTTP Server mod_http2. Structure is small and focused: a Dockerfile builds a vulnerable Apache 2.4.67 environment with HTTP/2 cleartext direct mode enabled; poc.py is the main exploit; check_server.py is a helper probe that measures impact on normal HTTP/1.1 requests; README.md explains setup and reproduction. The exploit capability is memory-amplification DoS over h2c. The PoC manually implements low-level HTTP/2 framing and HPACK encoding rather than using a library. It crafts a header block with standard pseudo-headers, inserts a cookie header into the dynamic table, then repeats indexed references (up to 4091 by default) so the server reconstructs many Cookie headers. This is intended to trigger repeated allocation during Apache cookie-header merging. The script also manipulates HTTP/2 flow control by setting a small or zero initial window and keeping many streams open for a configurable hold period, optionally dripping WINDOW_UPDATE bytes to prolong the condition. It supports multiple concurrent TCP connections and multiple streams per connection, increasing pressure on the target. check_server.py is not an exploit itself; it is an availability-impact measurement tool. It repeatedly sends benign HTTP/1.1 GET requests to the target and logs latency, timeouts, resets, and failures to demonstrate service degradation during the attack. No external C2, exfiltration, or post-exploitation behavior is present. This is a single-purpose network DoS PoC targeting Apache HTTP Server versions 2.4.17 through 2.4.67, with 2.4.68+ identified as patched.

Repository contains a small standalone Python proof-of-concept plus English and Chinese documentation for CVE-2026-49975, an HTTP/2 protocol-layer denial-of-service issue. The main exploit file, cve-2026-49975-http2bomb.py, is a direct network attack tool implemented only with Python standard libraries (socket, ssl, struct, threading, time, argparse). It is not part of a larger exploit framework. The exploit logic is straightforward and operational: it opens TCP connections to a user-specified host and port, optionally wraps them in TLS, negotiates ALPN 'h2', sends the HTTP/2 client preface, then transmits a SETTINGS frame with SETTINGS_INITIAL_WINDOW_SIZE set to 0. It acknowledges server settings, builds an HPACK seed header named 'x-bomb' with an empty value, and appends many one-byte indexed references (0xbe) to create a compressed header block intended to trigger repeated server-side memory allocations. It sends this block in HEADERS frames across multiple odd-numbered stream IDs, then periodically sends WINDOW_UPDATE frames with increment 1 to keep stalled streams alive and pin memory allocations. Capabilities include concurrent exploitation via configurable thread count, multiple streams per connection, configurable number of indexed references per stream, configurable hold time, and optional cleartext mode via --no-ssl for h2c. The script estimates expected memory pressure on the target and prints progress while maintaining the attack. Repository structure is simple: README.md provides an English overview, usage, mitigation notes, and lab setup guidance; CVE-2026-49975_复现方案.md provides a more detailed Chinese reproduction guide with affected products, Docker-based target setup, protocol explanation, and monitoring steps; cve-2026-49975-http2bomb.py is the actual exploit implementation. Overall purpose is to reproduce and demonstrate remote memory-exhaustion DoS against vulnerable HTTP/2 servers rather than achieve code execution or persistence.

Repository contains a Python proof-of-concept exploit for an HTTP/2 denial-of-service issue described as CVE-2026-49975, plus a companion defense-probing script and a local HTTP/2 test server. The main exploit file is http2_bomb.py, which manually builds HTTP/2 traffic using hyperframe and hpack rather than a higher-level HTTP client. It opens a TCP/TLS connection to a user-supplied host and port, negotiates ALPN 'h2' when TLS is enabled, sends the HTTP/2 connection preface and SETTINGS, and then performs the attack by abusing HPACK compression and HTTP/2 flow control. The exploit’s core capability is to insert small headers into the HPACK dynamic table and then send many indexed references across multiple streams, creating asymmetric server-side memory/bookkeeping cost. It also sets INITIAL_WINDOW_SIZE to 0 to inhibit response delivery and can periodically send WINDOW_UPDATE frames to keep the connection alive, effectively pinning allocations. Optional cookie fragmentation is included to try to bypass header-count limits. probe_defense.py is not the exploit itself; it is a detection/probing utility that connects to a target HTTP/2 service and evaluates whether mitigations appear present based on protocol behavior. test_server.py is a local vulnerable-style HTTP/2 server used for validation and demonstration; it listens with TLS, accepts HTTP/2 connections, decodes headers, and logs large header counts to simulate the vulnerable processing path. Repository structure is small and focused: 3 Python code files, 1 README, 1 requirements file, and .gitignore. Dependencies are h2/hpack/hyperframe. This is a real exploit repository, not just documentation, and its practical outcome is application-layer remote DoS rather than code execution. No hardcoded victim infrastructure is embedded; the operator supplies the target host and port at runtime.

This repository is a functional Python-based denial-of-service exploit with a FastAPI web console for CVE-2026-49975, described as an HTTP/2 stream amplification / memory exhaustion issue. It is not tied to a major exploit framework. The repo contains 9 files: backend code in app/main.py and app/bomber.py, a static single-page web UI in app/static/index.html, packaging/deployment files (Dockerfile, docker-compose.yml, requirements.txt), and CI for publishing a container image. Core exploit logic lives in app/bomber.py. The check_http2() routine probes a user-supplied host and port for HTTP/2 support using TLS ALPN ("h2", fallback "http/1.1") and, on SSL failure, attempts an h2c upgrade probe. The AttackTask class performs the actual attack: it opens one or more TLS sockets to the target, negotiates ALPN h2, sends the HTTP/2 client preface and SETTINGS, then creates 128 odd-numbered streams per connection. Each stream carries a crafted header block payload (BOMB_PAYLOAD) split across HEADERS and CONTINUATION frames. After sending, the code periodically transmits WINDOW_UPDATE frames to keep the connection alive for hold_seconds. The intended effect is asymmetric memory consumption on the server, potentially leading to OOM. The web application in app/main.py exposes REST endpoints for checking targets, starting/stopping attacks, retrieving stats, and streaming logs via SSE. It validates host input only loosely and passes the supplied host/port directly into outbound socket connections. The frontend in app/static/index.html interacts with /api/attack, /api/check, /api/stats, and /api/logs/stream to provide one-click detection, attack launch, and live monitoring. Operationally, this is more than a detector: it includes a working attack payload and orchestration UI, so it qualifies as an exploit. It is best categorized as OPERATIONAL rather than WEAPONIZED because the payload is fixed and purpose-built, though parameters like host, port, connection count, and hold time are configurable. The main fingerprintable local service endpoint is the operator-facing console on port 8080; the remote target is any operator-supplied HTTP/2 server, typically on TCP 443.

This repository is a small standalone Python proof-of-concept for CVE-2026-49975, an HTTP/2 remote denial-of-service issue. It contains one executable code file (exploit-test.py), a README describing the vulnerability and usage, and a license. The exploit is not part of a larger framework. The main script manually implements enough of the HTTP/2 protocol to open a connection, send the HTTP/2 client preface, exchange SETTINGS, and transmit crafted HEADERS/CONTINUATION frames. Its core technique is to seed the HPACK dynamic table with a header entry and then reference that entry thousands of times using indexed references. According to the code and README, this causes vulnerable servers to allocate disproportionate memory per reference. The script also sets INITIAL_WINDOW_SIZE to zero and periodically sends tiny WINDOW_UPDATE frames so the server cannot fully send responses or release memory, extending the lifetime of the allocations. Capabilities include: targeting arbitrary host/port pairs; optional TLS or cleartext h2c; parallel attack threads; multiple streams per connection; configurable number of HPACK references; and two attack modes. The nginx mode uses an empty x-bomb header to trigger bookkeeping-heavy allocation with lower per-reference amplification, while the classic mode uses a large cookie value intended for Apache/Envoy-style amplification. The script estimates expected server RAM pressure and continuously reconnects to sustain the attack. Fingerprintable targets are mostly user-supplied rather than hardcoded. The exploit operates against a remote TCP service speaking HTTP/2, typically on ports 443 or 80. No hardcoded malicious callback infrastructure, C2, or exfiltration endpoints are present. Overall, this is an operational network DoS PoC designed to exhaust memory on vulnerable HTTP/2 server implementations rather than achieve code execution or persistence.

Repository contains a functional Python proof-of-concept for CVE-2026-49975 ('HTTP/2 Bomb'), plus two small Bash helper scripts and a Docker Compose lab definition for local testing against nginx and Apache. The main exploit file ('POC HTTP-2-Bomb') manually constructs HTTP/2 frames over raw sockets, optionally wrapped in TLS, and sends the HTTP/2 client preface followed by a SETTINGS frame that sets INITIAL_WINDOW_SIZE to 0. It then builds an HPACK-based header bomb using one literal header ('x-bomb') and thousands of indexed references, splits the payload across HEADERS and CONTINUATION frames, and keeps the connection alive indefinitely with minimal WINDOW_UPDATE and periodic PING frames. This structure indicates a remote DoS exploit intended to maximize server memory consumption while preventing the target from draining state. The Bash scripts are passive/quick checks for HTTP/2 support and server banner collection rather than exploitation. The Docker lab exposes nginx on localhost:8080 and Apache on localhost:8081 for reproducible testing. Overall, the repository’s purpose is to demonstrate and test a network-based HTTP/2 resource exhaustion attack against vulnerable web servers.