curl 8.23.0: patch the HTTP/2 upload use-after-free

curl 8.23.0 fixes CVE-2026-92392, a High-severity use-after-free in HTTP/2 uploads that can be triggered by a malicious server returning specific RST_STREAM reasons. The curl project says the flaw has been proven convertible to remote code execution under a demanding set of environment, heap-layout and concurrency conditions. Teams that ship curl or libcurl 8.12.0 through 8.22.0 should inventory every runtime and embedded copy, upgrade to 8.23.0 or apply an approved backport, rebuild dependent artifacts, replace running workloads and verify the version and library that actually handle traffic.

The advisory was published with curl 8.23.0 on October 14, 2026 and rechecked on October 27, 2026. A demonstrated exploit path is evidence of impact, not evidence that a particular deployment was compromised or that attacks are occurring in the wild. The curl advisory does not claim active exploitation. Version ranges, mechanics and fixes below are vendor facts; the rollout and detection plan is engineering guidance.

The decision first

Prioritize services that upload attacker-influenced or sensitive data to external origins, run concurrent transfers, use libcurl inside long-lived workers, or bundle curl in appliances, agents and containers. Do not limit the inventory to engineers typing the curl command: libcurl is embedded in applications that may not advertise it.

Where the bug lives

During an HTTP/2 upload, a server can reject or redirect stream handling by sending RST_STREAM. For the HTTP_1_1_REQUIRED and REFUSED_STREAM reasons, affected curl versions can mishandle the retry state and continue using a freed struct Curl_easy object.

A use-after-free means program logic retains a pointer after the pointed-to memory has been released. Later allocations may reuse that region. A crash is one possible outcome; controlled reuse can turn stale reads or writes into code execution. The curl project classifies the issue as CWE-416 and a C memory-safety mistake.

The remote peer must be the server to which the client connects, or be able to control that server's HTTP/2 behavior. Ordinary inbound traffic to a web server does not automatically reach this client-side path. The relevant question is: which processes use curl or libcurl to upload over HTTP/2 to an origin whose responses might be malicious?

Why “RCE is possible” needs context

The project's proof requires a tightly matched environment. The advisory lists knowledge of the exact curl object layout and CPU architecture, a compatible libc allocator and heap layout, nghttp2 plus OpenSSL/TLS 1.3 allocation behavior, a pinned CA bundle, two parallel transfers with stable timing, calibrated libc offsets and a short-command constraint of roughly 23 bytes.

Those constraints do not make the flaw harmless. They explain why exposure and exploitability are not identical:

• vulnerable: an affected curl/libcurl is present;
• reachable: an affected process performs HTTP/2 uploads to a server an attacker can influence;
• attempted exploitation: telemetry records crafted stream resets and correlated abnormal behavior;
• confirmed compromise: host, process or business evidence demonstrates unauthorized execution or impact.

Do not label every affected binary “compromised.” Conversely, do not wait for public attack telemetry before patching a memory-corruption flaw with a vendor-confirmed RCE construction.

Map the actual curl estate

Start from execution, not package manifests. curl may appear as a command-line tool, a shared libcurl package, a statically linked library, a language binding, a base-image layer, a CI runner dependency, an agent or a vendor appliance.

# CLI identity and compiled capabilities
curl --version

# Common package inventories
dpkg-query -W 'curl' 'libcurl*' 2>/dev/null
rpm -qa | grep -Ei '(^|-)curl|libcurl'

# Common dynamically linked consumers
ldconfig -p 2>/dev/null | grep libcurl
find /opt /usr/local -type f -perm -111 -exec sh -c '
  for f do ldd "$f" 2>/dev/null | grep -q libcurl && printf "%s\n" "$f"; done
' sh {} +

These commands are discovery aids, not proof of completeness. Static linkage will not appear in ldd. Minimal containers may omit package tools. Software may load libcurl dynamically or keep a private copy. Add software-composition analysis, SBOM queries and vendor attestations, then verify running processes and container digests.

Record at least service owner, executable or image digest, curl/libcurl version, build source, HTTP/2 support, upload destinations, concurrency model, TLS backend and deployment replicas. One host's curl version does not prove what a container or embedded application executes.

Decide whether a version is fixed

The upstream range is straightforward: 8.12.0 through 8.22.0 is affected; versions below 8.12.0 and 8.23.0 or newer are not affected by this CVE. The curl project also lists fixed maintained-branch releases 8.20.2, 8.16.2 and 8.14.3.

Distribution versions can retain an older-looking upstream number while applying a backported patch. Do not declare a vendor package vulnerable from the first number alone. Require the operating-system or appliance vendor's advisory or package changelog to map the installed revision to CVE-2026-92392. “Latest available in the repository” is not evidence unless the repository publishes that mapping.

For source builds, compare against the fixed commit only as supporting evidence. A local patch may depend on surrounding branch changes and test coverage. Prefer an official release or vendor-supported backport over manually cherry-picking into an unmaintained tree.

Patch hosts, containers and embedded applications

1. Freeze the inventory at a timestamp and assign owners.
2. Select curl 8.23.0 or a documented vendor backport.
3. Rebuild every application and container that embeds or statically links libcurl.
4. Rebuild multi-stage images from clean, pinned inputs; do not copy an old libcurl from a builder stage.
5. Canary real upload workflows over HTTP/1.1 and HTTP/2 using controlled servers and safe fixtures.
6. Replace all running workers, jobs and agents rather than changing files beneath a process.
7. Verify process, package, image digest and protocol capability across every replica.
8. Remove vulnerable images and autoscaling templates so rollback cannot silently reintroduce them.

For Kubernetes, update the immutable image reference, roll the workload, then query Pod image IDs—not mutable tags. Include CronJobs and suspended jobs because they may start later from an old template. For serverless and managed agents, require the provider's fixed runtime or deployment statement and redeploy when the artifact includes its own libcurl.

Verify the binary that performs the upload

Verification should answer four different questions:

For an application, expose a protected operations diagnostic that reports its own libcurl version and TLS/HTTP features, or collect this at startup into trusted telemetry. Avoid a public version endpoint. Sample every replica behind a load balancer and retain the deployment digest alongside the result.

Then run functional canaries: a normal HTTP/2 upload, a server-requested fallback path, cancellation, timeout, retry and concurrent transfer. The objective is to prove the fixed build still satisfies product behavior. Do not send exploit payloads to production.

Temporary containment when patching is blocked

The upstream advisory lists disabling HTTP/2 as an alternative recommendation. Use that only as a short-lived control, because it does not remove the vulnerable code and may be bypassed by an unreviewed caller.

For the CLI, explicitly force HTTP/1.1 on affected upload workflows. For libcurl, enforce the protocol policy in application code and test that redirects or connection reuse do not re-enable HTTP/2. Restrict outbound destinations, pin expected origins through an egress policy and prevent untrusted users from supplying arbitrary upload URLs.

Do not treat a WAF in front of your inbound application as mitigation: this flaw is reached by a curl client processing a remote server's HTTP/2 control frame. An outbound proxy can reduce reachable destinations, but it is not proof that affected clients cannot negotiate HTTP/2 or reach a malicious allowed origin.

Detection and incident review

Patch even if logs are quiet. For retrospective review, preserve:

• process crashes, core dumps and allocator diagnostics around HTTP/2 uploads;
• outbound destination, negotiated protocol and transfer correlation IDs;
• RST_STREAM reason codes when the library or proxy exposes them;
• retry bursts, REFUSED_STREAM or HTTP_1_1_REQUIRED anomalies;
• container restarts, kernel events and unexpected child processes;
• the executing image digest and library identity at the event time.

A matching reset plus a crash may justify escalation, but it is still not automatically proof of code execution. Correlate with process ancestry, file changes, credential use, outbound connections and workload identity. If memory corruption may have occurred, preserve evidence before restart where policy allows, rebuild from trusted artifacts and rotate credentials according to the process's reachable secrets.

Best practices

• Track curl and libcurl separately in SBOMs and runtime inventory.
• Record immutable artifact digests and library versions in deployment telemetry.
• Treat outbound upload destinations as a security boundary.
• Bound concurrency, retries, body size and transfer time.
• Consume upstream and distribution security advisories, not version strings alone.
• Make rollback point to a known fixed artifact.
• Keep a tested switch to restrict HTTP protocol versions during emergencies.

Anti-patterns

• Checking only the developer workstation's curl command.
• Assuming package update success replaced long-lived processes.
• Treating a reverse proxy or inbound WAF as a fix for client-side libcurl.
• Claiming compromise from an affected version scan.
• Claiming safety because no public exploitation was mentioned.
• Rebuilding from a floating base tag without recording the final digest.
• Cherry-picking one commit into an unsupported branch without regression tests.

Executive takeaway

CVE-2026-92392 sits in a common but often hidden dependency. The right response is not panic and not a CLI-only update. Find every executing curl and libcurl copy, determine whether HTTP/2 uploads reach attacker-influenced servers, move to 8.23.0 or a supported backport, rebuild dependent artifacts, replace the fleet and preserve enough telemetry to distinguish vulnerability, attempted exploitation and confirmed compromise.

Continue with the Cloud, DevOps & Kubernetes hub, Node.js October 2026 patch guide, Apache Tomcat October 2026 patch guide and Docker runtime hardening.

Primary references

• curl Project — CVE-2026-92392: HTTP/2 upload Use-After-Free
• curl Project — curl 8.23.0 security advisory announcement
• curl Project — published security vulnerabilities
• curl Project — fixed commit 8b0744af5b1b631da5b938ca31c
• curl Project — curl command-line manual
• Wikimedia Commons — Back of server
• Creative Commons Attribution-ShareAlike 4.0

Prepared by: Noor Yasser