CVE-2026-3784

What it actually does

CVE-2026-3784 is an authorization boundary flaw in curl’s HTTP proxy connection reuse logic. When curl establishes an HTTP proxy tunnel with CONNECT, it may incorrectly reuse an existing proxy connection for a later request even when that later request specifies different proxy credentials. The expected behavior is to keep proxy-authenticated connections separated by credential context. Because the connection can be reused across credential boundaries, requests may be sent through a proxy session authenticated as a different user or identity than intended. This can cause limited confidentiality and integrity impact: traffic, proxy authorization context, access-control decisions, accounting, or audit attribution may be associated with the wrong proxy credentials.

Why it matters to the business

Organizations that use curl or software built on libcurl with authenticated HTTP proxies may see requests routed under the wrong proxy identity. In practical terms, this can undermine proxy-based access controls, audit trails, billing or usage attribution, and separation between users, jobs, services, or tenants that rely on distinct proxy credentials. The CVSS score is medium and EPSS is very low with no known KEV listing or public exploit maturity reported, so broad opportunistic exploitation is less likely at this time; however, the issue is still important where curl is used in automation, CI/CD systems, API integrations, package managers, or applications that make outbound requests through shared authenticated proxy pools.

How an attack unfolds

An attacker needs a scenario where curl or a libcurl-based application performs multiple outbound requests through the same HTTP proxy using CONNECT and changes proxy credentials between requests while connection reuse is enabled. The attacker’s objective is not typically remote code execution, but to benefit from authorization confusion. For example, a lower-privileged request may be placed after a higher-privileged request in the same client process, and curl may incorrectly reuse the proxy connection that was authenticated with the higher-privileged credentials. The subsequent request can then traverse the proxy under the previous credential context, potentially reaching destinations, audit identities, or proxy policy paths the new credentials should not allow. Exploitation is most plausible in multi-user tooling, service brokers, automation workers, or applications that multiplex requests for different identities through one curl/libcurl process and one authenticated HTTP proxy.

How to fix it

Upgrade curl/libcurl to a vendor-provided version that contains the fix for CVE-2026-3784. No exact fixed version was provided in the input, so use the latest security release available from the operating system, package manager, container base image, appliance vendor, language ecosystem, or haxx curl upstream distribution. Prioritize systems where curl/libcurl is used with authenticated HTTP proxies and CONNECT. If immediate upgrade is not possible, reduce risk by disabling connection reuse for affected workflows where feasible, avoiding credential changes within the same curl/libcurl handle or process, using separate curl handles/processes for different proxy credentials, segregating proxy credentials by worker or runtime, and ensuring proxy-side policy does not rely solely on long-lived client connection identity for sensitive authorization decisions.

How to confirm the fix worked

Confirm the installed curl and libcurl versions come from a package or build that includes the vendor fix. Inventory both command-line curl binaries and embedded libcurl copies in applications, containers, appliances, and statically linked software. Test representative workflows that use HTTP proxy CONNECT with different proxy credentials: after remediation, curl should create or select a separate proxy connection when proxy credentials differ rather than reusing a prior authenticated connection. Review package manager advisories, SBOMs, container image scans, and application dependency manifests for affected curl/libcurl versions. Where possible, enable verbose curl diagnostics or proxy logs in a non-production test to verify that different proxy credentials result in distinct authentication events or separated proxy sessions.

Typical attack path

1. Identify an application, script, service, or automation worker that uses curl or libcurl with an authenticated HTTP proxy and CONNECT tunneling.
2. Find or influence a workflow where the same client process sends multiple proxy requests using different HTTP proxy credentials.
3. Cause or wait for a request using more privileged proxy credentials to establish a reusable CONNECT proxy connection.
4. Trigger a subsequent request that should use different, lower-privileged, or attacker-controlled proxy credentials.
5. Rely on curl incorrectly reusing the existing authenticated proxy connection instead of opening a credential-separated connection.
6. Use the resulting proxy authorization confusion to access destinations, policies, or attribution paths associated with the previously authenticated proxy user.

How to detect it

This vulnerability does not produce a universal malware artifact or fixed network signature. Detection should focus on proxy and application telemetry showing inconsistent proxy authentication context. Review HTTP proxy logs for CONNECT requests where a persistent client connection, source address, connection ID, or session identifier authenticates as one proxy user and is later associated with requests expected to use another proxy user. Correlate application logs from curl/libcurl-based services with proxy logs to identify workflows that changed proxy credentials within the same process or job while reusing connections. Useful log sources include HTTP proxy authentication logs, CONNECT tunnel logs, egress gateway logs, application debug logs, curl verbose output, CI/CD runner logs, job scheduler logs, container logs, and endpoint process command-line telemetry showing curl invocations with proxy credentials. Look for access to destinations that should be denied for the later credential but allowed for a previously used credential. Because no public exploit maturity, KEV listing, ransomware use, or named threat actor exploitation is reported, treat findings as suspicious authorization anomalies rather than definitive compromise unless paired with unauthorized destination access or data movement.

• curl -x http://
• curl --proxy http://
• curl --proxy-user
• CURLOPT_PROXYUSERPWD
• CURLOPT_PROXYUSERNAME
• CURLOPT_PROXYPASSWORD
• CONNECT
• Proxy-Authorization: Basic
• Proxy-Authorization: Digest
• Re-using existing connection
• Connection #0 to host
• Uses proxy env variable http_proxy
• Uses proxy env variable https_proxy

What your security team should do

• Inventory systems, containers, applications, and third-party products that include haxx curl or libcurl, especially those using authenticated HTTP proxies.
• Prioritize patching internet-facing automation, CI/CD runners, service brokers, API gateways, scraping infrastructure, package downloaders, and multi-user applications that reuse curl/libcurl handles across identities.
• Upgrade to the latest vendor-fixed curl/libcurl release once available through the applicable package channel; rebuild containers and statically linked applications that bundle libcurl.
• Until upgraded, isolate workflows using different proxy credentials into separate processes, handles, workers, or runtime pools and disable connection reuse where feasible.
• Review proxy configuration to ensure authorization decisions are evaluated per request/session appropriately and that audit logs capture both authentication events and destination requests.
• Search proxy logs for signs of credential-context confusion, such as one authenticated proxy connection being used for destinations normally associated with another identity.
• Monitor vendor advisories because exploit maturity is currently reported as none and EPSS remains very low, but exploitation likelihood can change after patch details become public.