Advisory · CVE-2026-124040
CivetWeb HTTP/2 use-after-free lets remote attackers steer requests or crash the server
CivetWeb through 1.16, built with HTTP/2 enabled, retains freed :method and :path pointers in handle_http2(), so an unauthenticated remote attacker can send a later HEADERS frame omitting those pseudo-headers to influence the method or path access rules see, or crash the server.
- Vendor
- CivetWeb
- Product
- CivetWeb
- Identifier / CWE
- CVE-2026-124040
CWE-416 - Action timing
- Immediate
Explain it like I’m five
The server throws away the note saying which page was requested, but keeps pointing at where the note was. A later message can reuse that stale pointer, so the server acts on a request the attacker shaped, or crashes.
- 01HTTP/2 connection opened
An unauthenticated remote attacker connects to a CivetWeb server built with HTTP/2 enabled.
- 02First request processed
An initial request is handled and its :method and :path pseudo-header values are freed.
- 03Stale pointers retained
handle_http2() keeps pointers to the freed values instead of clearing them.
- 04HEADERS frame omits pseudo-headers
A later HEADERS frame omits :method and :path, so the server reuses the stale values.
- 05Access rules misled or crash
The request method or path seen by access rules is attacker-influenced, or the server crashes on the freed memory.
What happened
CivetWeb through 1.16, when built with USE_HTTP2 and HTTP/2 enabled, contains a use-after-free vulnerability in handle_http2() that retains freed :method and :path pointers. An unauthenticated remote attacker can send a later HEADERS frame omitting these pseudo-headers to influence the request method or path seen by access rules, or crash the server. The underlying report covers several HTTP/2 and WebSocket memory-safety findings in the server-side code; this advisory covers only the HTTP/2 pseudo-header use-after-free. The record rates it critical at CVSS 9.2 under version 4.0 and high at 8.1 under version 3.1.
The NVD record lists CivetWeb through 1.16 as affected. No fixed release was stated in the sources checked for this run, so no fixed version is claimed here; the fix reference to watch is the upstream issue. The flaw needs an HTTP/2-enabled build, so deployments built without HTTP/2 are not exposed through this path.
What to do
- Inventory CivetWeb deployments, including CivetWeb embedded in other products, and record whether each build has HTTP/2 enabled.
- Where HTTP/2 is not needed, disable it until a fixed release is available.
- Restrict network access to CivetWeb servers and treat unexpected crashes as a possible trigger of this issue.
- Watch the upstream issue for a fixed release and upgrade as soon as one is available.
- Review server logs for crashes and for unusual HTTP/2 HEADERS frames omitting pseudo-headers.
- Verify the deployed version and build configuration after updating.
Management note
A memory-safety flaw that can also bend access rules deserves a fix track, not just a restart. If HTTP/2 is not load-bearing, switching it off is the fastest mitigation while the upstream fix lands.