CivetWeb through 1.16 HTTP/2 Use-After-Free via Stale Pseudo-Header State
- Exploited
- No known exploitation
- Fix
- No fix listed
- Who is exposed
- Not reported
Do first: Workaround: No fix is listed in the checked facts. While waiting for one, the most direct option is to turn off HTTP/2 by disabling enable_http2, which removes the affected code path in builds where it is enabled.
- Last modified
- A 0-100 score for how much a CVE matters across the industry: exploitation, exposure, how widely the software is used, severity and whether a fix exists.What do these mean? →
- 31/100 · provisional
- How many real-world setups can hit the bug, from the vendor's advisory and CISA data. It does not know your setup.What do these mean? →
- Unclear
- Whether working attack code is public (Exploit-DB, Metasploit, Nuclei or GitHub). Public code makes attacks easier.What do these mean? →
- None on Exploit-DB, Metasploit or GitHub
Summary
CivetWeb through 1.16, when built with HTTP/2 support and enable_http2 turned on, has a use-after-free flaw in its HTTP/2 request handling that lets an unauthenticated attacker reach the server remotely over the network. The attacker can influence the request method or path that access rules check, or crash the server.
Written by anthropic/claude-haiku-5.5 from the sources below. Verify against them.
Read the original description
CivetWeb through 1.16, when built with USE_HTTP2 and enable_http2 on, contains a use-after-free vulnerability in handle_http2() that retains freed :method and :path pointers. Unauthenticated remote attackers can send a later HEADERS frame omitting these pseudo-headers to influence request method or path seen by access rules, or crash the server.
cve.now Index
- Exploitation?/40Unknown. No CISA SSVC exploitation rating yet
- Exposure17/25No login or user action needed, reachable over the network without a login · Unknown: Advisories don't say whether default setups are affected
- Reach?/20Unknown. No tracked technology or package matched
- Severity9.2/10CVSS 9.2
- No patch5/5No patch listed yet
What would change the score
- Would score about 76 if added to CISA KEV
- Would score about 71 if CISA's SSVC rates exploitation active
- Would score about 36 if advisories confirm default setups are exposed
What to do
Workaround: No fix is listed in the checked facts. While waiting for one, the most direct option is to turn off HTTP/2 by disabling enable_http2, which removes the affected code path in builds where it is enabled.
Timeline
- CVE published
- First seen by cve.now
- Posted on X by cve.now
Affected versions
- civetweb civetweb
through 1.16
Evidence 4
- Report
- Repository
- Repository
- Link
Corrections
None so far.
Something wrong on this page? Report an error. Every fix is listed here.
Questions about CVE-2026-124040
Is CVE-2026-124040 being exploited?
It is not in CISA's Known Exploited Vulnerabilities catalog, and CISA's SSVC assessment does not mark exploitation as active. That does not mean it has not been attacked: vendors and researchers can report attacks before CISA lists them. No public exploit code is tracked.Source: cve.now feed data
What does this mean?
The bug is a use-after-free in CivetWeb's HTTP/2 handling. A later HEADERS frame that leaves out the usual pseudo-headers can make the server reuse stale state, which may change the request method or path that access rules see, or crash the server.Source: vulncheck.com
Which versions are affected by CVE-2026-124040?
civetweb: through 1.16.Source: cve.now feed data
Am I affected, and how do I check?
CivetWeb versions through 1.16 are listed as affected, but only when the server is built with USE_HTTP2 and enable_http2 is turned on. To check, look at the version you run and whether HTTP/2 support was compiled in and enabled in your configuration.Source: vulncheck.com
How do I fix CVE-2026-124040?
No fixed version is listed in the checked facts, so no specific upgrade target can be named. Check the CivetWeb project for a release that addresses this issue.Source: vulncheck.com
What if there's no patch?
No fix is listed in the checked facts. While waiting for one, the most direct option is to turn off HTTP/2 by disabling enable_http2, which removes the affected code path in builds where it is enabled.Source: vulncheck.com