CVE-2026-10536: libcurl HTTP/2 stream-dependency tree use-after-free

CVE-2026-10536 is a heap use-after-free (UAF) in libcurl's HTTP/2 stream-dependency bookkeeping. When an application sets CURLOPT_STREAM_DEPENDS (or CURLOPT_STREAM_DEPENDS_E) on an easy handle, then calls curl_easy_reset() on that handle and later curl_easy_cleanup() on both handles, libcurl can dereference a dependency-tree node that was already freed. The vulnerability requires HTTP/2 support (nghttp2) and use of the now-deprecated dependency options. It is reachable through the public libcurl API (curl_easy_setopt, curl_easy_reset, curl_easy_cleanup) without any network traffic.

• Package/component affected: curl / libcurl, HTTP/2 stream priority/dependency code (lib/url.c, priority_remove_child, data_priority_cleanup).
• Affected versions: curl 7.88.0 through 8.20.0 inclusive (per upstream advisory); introduced by commit 71b7e0161032927cdfb and fixed by commit bfbff7852f050232edd3e5ca5c6bf2021c340f5a.
• Risk level and consequences: High / memory corruption. The UAF occurs during easy-handle cleanup, so a controlled memory layout could potentially lead to further memory corruption. The upstream advisory classifies the issue as a use-after-free with CVSS severity Low, but the demonstrated impact is a real memory-safety violation in a widely used library. It does not affect the curl command-line tool directly; only applications that programmatically use the deprecated dependency options are exposed.

Impact Parity

• Disclosed/claimed maximum impact: memory corruption (use-after-free).
• Reproduced impact from this run: A deterministic AddressSanitizer heap-use-after-free report in priority_remove_child at lib/url.c:3516 when the parent handle is cleaned up after the child handle has been reset and freed.
• Parity: full for the memory-safety claim. The reproduction proves the exact vulnerability class (UAF) and the exact API surface described in the advisory.
• Not demonstrated: No remote code execution or full exploit chain was demonstrated; only the UAF crash/reachability is proven, which is sufficient for the claimed memory-corruption impact.

Root Cause

The bug is in the priority-child doubly-linked bookkeeping in lib/url.c:

1. curl_easy_setopt(child, CURLOPT_STREAM_DEPENDS, parent) adds a Curl_data_prio_node to parent->set.priority.children; that node stores a raw pointer to child. It also sets child->set.priority.parent = parent.

2. curl_easy_reset(child) executes memset(&data->set, 0, sizeof(struct UserDefined)), which zeros child->set.priority and therefore clears child->set.priority.parent. The child handle now "forgets" that it is a dependent of parent, but parent->set.priority.children still contains the node pointing at child.

3. curl_easy_cleanup(child) calls data_priority_cleanup(child). Because child->set.priority.parent is now zero, the code does not remove the child node from its parent list. The Curl_easy struct for child is then freed.

4. curl_easy_cleanup(parent) calls data_priority_cleanup(parent), which loops over parent->set.priority.children. The first node still points to the freed child struct, so priority_remove_child(parent, child) reads child->set.priority.parent (offset 2120 inside the freed Curl_easy) and crashes under AddressSanitizer.

• Fix commit: https://github.com/curl/curl/commit/bfbff7852f050232edd3e5ca5c6bf2021c340f5a ("http2: remove stream dependency tracking"). The upstream fix removes the entire HTTP/2 stream-dependency feature, making CURLOPT_STREAM_DEPENDS and CURLOPT_STREAM_DEPENDS_E no-ops, which eliminates the faulty bookkeeping.

Reproduction Steps

1. Run bundle/repro/reproduction_steps.sh. It is self-contained: it installs build dependencies, clones or reuses the curl repository, builds two static ASan-enabled libcurl installations (vulnerable curl-8_20_0 and fixed bfbff7852f), compiles a small C reproducer, and runs it against both.
2. The reproducer creates two easy handles, sets CURLOPT_STREAM_DEPENDS on the child so it depends on the parent, calls curl_easy_reset(child) and curl_easy_cleanup(child), then calls curl_easy_cleanup(parent).
3. Expected evidence:
   • Vulnerable build: AddressSanitizer reports heap-use-after-free in priority_remove_child (lib/url.c:3516).
   • Fixed build: reproducer exits cleanly with no sanitizer report.

Evidence

• bundle/logs/reproduction_steps.log — full script output.
• bundle/logs/reproducer_vuln.log — ASan heap-use-after-free report for the vulnerable build.
• bundle/logs/reproducer_fixed.log — clean run for the fixed build.
• bundle/repro/reproducer.c — source of the minimal C harness.
• bundle/repro/runtime_manifest.json — structured runtime evidence manifest.

Key excerpt from the vulnerable run:

==ERROR: AddressSanitizer: heap-use-after-free on address ... at pc ... in priority_remove_child lib/url.c:3516
READ of size 8 at ... thread T0
    #0 priority_remove_child /.../lib/url.c:3516
    #1 data_priority_cleanup /.../lib/url.c:3588
    #2 Curl_close /.../lib/url.c:280
    #3 curl_easy_cleanup /.../lib/easy.c:844

The freed region was the Curl_easy struct allocated in Curl_open during curl_easy_init, and it was freed by curl_easy_cleanup(child) before curl_easy_cleanup(parent) accessed it through the stale dependency node.

Recommendations / Next Steps

• Upgrade: Upgrade libcurl to 8.21.0 or later, where the dependency feature has been removed and the option is a no-op.
• Workaround: Applications that currently use CURLOPT_STREAM_DEPENDS or CURLOPT_STREAM_DEPENDS_E should stop using these deprecated options; they are no longer functional in 8.21.0+.
• Testing: For any cherry-picked patch, verify that curl_easy_setopt(..., CURLOPT_STREAM_DEPENDS, ...) followed by curl_easy_reset and curl_easy_cleanup no longer produces a use-after-free under ASan/Valgrind.

Additional Notes

• Idempotency: The reproduction script was run twice consecutively and produced the same confirmed result both times. Cached builds in the project cache are reused when the recorded commit matches, making subsequent runs fast.
• Limitations: The proof is a library/API harness that directly calls the affected libcurl functions. It does not exercise a remote network path because the advisory describes an application-level API misuse, not a network-triggered vulnerability.