✓ProveIt
Examples / Report #3231321 Saved analysis

HTTP Proxy Bypass via `CURLOPT_CUSTOMREQUEST` Verb Tunneling

curl · 2025-07-0113.8s analysis · $0.011 in model calls

What the report claims

A logic flaw in libcurl 8.14.1 allows bypassing restrictive HTTP proxy firewalls by tunneling an arbitrary HTTP verb within a CONNECT request using CURLOPT_CUSTOMREQUEST set to CONNECT for an http:// URL, enabling arbitrary data to be sent to internal services.

Compare with curl's recorded outcome

Labeled AI slop

curl's maintainer lists this report as AI slop

Shown for comparison after analysis. The pipeline did not see this label.

ProveIt's finding

Needs human review

The available evidence does not settle the report. A maintainer should investigate.

Why this finding?
  • The report describes a plausible and detailed attack scenario with concrete reproduction steps
  • All claims depend on curl's proxy handling and CURLOPT_CUSTOMREQUEST implementation logic in lib/http.c (and related files)
  • No curl source code was provided in the context (curl_source: 'no curl code could be retrieved'), making all claims not_verifiable against the code
  • The deterministic checks confirm the relevant files and symbols exist at the target revision (31a7905ce184), but the actual code logic is missing
  • A human reviewer needs to examine the proxy request construction code and CURLOPT_CUSTOMREQUEST handling to determine if the described bypass is possible
What still needs checking
  • lib/http.c source code from revision 31a7905ce184 (master on 2025-07-01)
  • Any files handling CURLOPT_CUSTOMREQUEST option parsing and application
  • Proxy request construction logic for HTTP URLs with proxies
  • Request body handling code paths for proxied requests
How this analysis ran 5 claims · 0 citations verified

Checked against curl master on 2025-07-01 (31a7905ce184). Dev evaluation split. Citation verification checks that a referenced line was in the evidence; it does not prove the model interpreted it correctly.

1 · Grounding
grounded
no model · 10 references checked out, 0 did not
2 · Claims
NVIDIA-Nemotron-3-Nano-30B-A3B
5 claims · 3173 tokens · $0.0003
3 · Evidence
0 code snippets
real curl source at 31a7905ce184
4 · Judgment
Nemotron-3-Ultra-550b-a55b
6823 tokens · 10.5s · $0.0103
5 · Receipts
0 of 0 citations verified
every citation must point at code the judge was shown
Review a draft reply to the reporter

Edit and verify before sending.

Thank you for the detailed report. To evaluate this claim, we need to examine the proxy handling and CURLOPT_CUSTOMREQUEST implementation in libcurl's source code. The provided context did not include the relevant source files (lib/http.c and related option handling code) from revision 31a7905ce184. Could you confirm the exact version tested, or would you be able to provide the relevant code sections? Specifically, we need to see how CURLOPT_CUSTOMREQUEST interacts with proxy request construction for http:// URLs.

Inspect all claims and source code 5 claims · 0 code excerpts

Report claims

C1flaw not verifiable

A logic flaw in libcurl 8.14.1 allows bypassing restrictive HTTP proxy firewalls by tunneling an arbitrary HTTP verb within a CONNECT request using CURLOPT_CUSTOMREQUEST set to CONNECT for an http:// URL

Read the reasoning

The report claims a logic flaw in lib/http.c allows bypassing proxy restrictions via CURLOPT_CUSTOMREQUEST=CONNECT for http:// URLs. However, no curl source code was provided in the context (curl_source section states 'no curl code could be retrieved'). Without the actual proxy handling and CURLOPT_CUSTOMREQUEST implementation code, I cannot verify whether this logic flaw exists.

C2location not verifiable

in libcurl's proxy handling code when a proxy is used with an http:// URL

Read the reasoning

The location claim points to 'libcurl's proxy handling code when a proxy is used with an http:// URL' in http.c. Since the relevant source code files were not provided, I cannot confirm the code structure or logic at this location.

C3trigger not verifiable

setting CURLOPT_CUSTOMREQUEST to "CONNECT" for a standard http:// URL

Read the reasoning

The trigger claims setting CURLOPT_CUSTOMREQUEST to "CONNECT" for an http:// URL causes the custom verb to override the standard GET. This depends on the CURLOPT_CUSTOMREQUEST handling logic and proxy request construction code, which was not provided.

C4impact not verifiable

sends request body through the newly established TCP pipe to internal services, bypassing proxy restrictions

Read the reasoning

The impact claim describes libcurl sending the request body through a TCP pipe established by the proxy. This requires verifying the request body handling code path for http:// URLs with proxies when a CONNECT request line is sent, which is not available in the provided context.

C5reproduction not verifiable

use curl with --proxy and --request "CONNECT internal.host:port HTTP/1.1" and --data-binary to send payload

Read the reasoning

The reproduction steps use curl command-line options (--proxy, --request, --data-binary). While the deterministic checks confirm these symbols exist in curl, the actual command-line parsing and option handling code was not provided to verify the described behavior.

Read the original report (excerpt)

Full report on HackerOne ↗

### **Summary** A logic flaw in `libcurl` version **8.14.1** allows an attacker to bypass restrictive HTTP proxy firewalls by "tunneling" an arbitrary HTTP verb within a `CONNECT` request. By setting `CURLOPT_CUSTOMREQUEST` to `CONNECT` for a standard `http://` URL, an attacker can trick `libcurl` into creating a hybrid request. This request is misinterpreted by `CONNECT`-only proxies as a legitimate tunnel setup request and is therefore allowed. Subsequently, `libcurl` sends its request body (e.g., from `CURLOPT_POSTFIELDS`) through this newly established, unfiltered TCP pipe. This vulnerability effectively defeats network segmentation rules enforced at the proxy layer, enabling an attacker who can control `curl` options (e.g., via SSRF) to send arbitrary data to protected internal services. | | | | - | - | | **Product Name** | libcurl | | **Affected Version** | **8.14.1** (and likely prior versions) | | **Vulnerability Class** | CWE-284 Improper access control | | **CVSS 3.1 Score** | **8.6 (High)** | | **CVSS Vector** | `CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:N/I:H/A:N` | ### **Description** The vulnerability stems from insufficient validation between the user-defined request method and the request type `libcurl` assumes it is making when a proxy is in use. 1. When a user provides an `http://` URL and a proxy, `libcurl` prepares a standard, non-tunneled proxy request (e.g., `GET http://destination/... HTTP/1.1`). 2. If the user also sets `CURLOPT_CUSTOMREQUEST` to `"CONNECT internal.host:port HTTP/1.1"`, this custom verb overrides the standard `GET`. 3. The request line sent to the proxy now begins with `CONNECT`, which satisfies the security rules of a proxy that only permits the `CONNECT` method for establishing tunnels. The proxy allows the request and opens a raw TCP connection to the specified internal host and port. 4. Because the original URL scheme was `http://`, `libcurl`'s state machine does not enter its formal "HTTPS tunneling" mode. It proceeds as if it were making a `POST`-style request (due to the presence of a request body) and sends the payload down the TCP pipe that the proxy just opened. This allows an attacker to send arbitrary data directly to an internal service that should have been unreachable. ### **Proof-of-Concept (PoC)** This PoC demonstrates the bypass using standard command-line tools. It requires three separate term …

Source code

No source code was retrieved for this analysis. The evidence may be incomplete.