Examples / Report #2384833 Saved analysis

CVE-2024-2004: Usage of disabled protocol

curl · 2024-02-2115.9s analysis · $0.011 in model calls

What the report claims

The --proto option with a string starting with -all and only removing protocols (e.g., --proto -all,-http) incorrectly enables all protocols, allowing data to be sent over an unencrypted channel even when specific protocols like http are disabled.

Compare with curl's recorded outcome

Known vulnerability

A real vulnerability: CVE-2024-2004 Usage of disabled protocol

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 is detailed, provides a concrete reproduction case, and bisects to a specific commit (e6f8445) that introduced string-based protocol selection.
However, no curl source code was retrieved for the target revision (d5b0fee39a78), and deterministic checks returned 'nothing_to_check'.
All code-dependent claims (C1–C3, C5) are therefore not_verifiable; the impact claim (C4) rests on the unverified bug.
A human maintainer must examine the protocol parsing implementation (likely in lib/setopt.c or lib/urlapi.c around CURLOPT_PROTOCOLS_STR handling) to confirm or refute the missing-check hypothesis.

What still needs checking

The implementation of CURLOPT_PROTOCOLS_STR and CURLOPT_REDIR_PROTOCOLS_STR parsing (the code added/modified by commit e6f8445edef8e7996d1cfb141d6df184efef972c).
Specifically, the logic that processes a protocol string beginning with '-all' followed only by removal tokens (e.g., '-all,-http').

How this analysis ran 5 claims · 0 citations verified

Checked against curl master on 2024-02-21 (d5b0fee39a78). 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

nothing to check

no model · 0 references checked out, 0 did not

2 · Claims

NVIDIA-Nemotron-3-Nano-30B-A3B

5 claims · 2083 tokens · $0.0003

3 · Evidence

0 code snippets

real curl source at d5b0fee39a78 · 1 docs via Tavily

4 · Judgment

Nemotron-3-Ultra-550b-a55b

6324 tokens · 12.7s · $0.0107

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 and bisection. We need to examine the protocol-string parsing code (CURLOPT_PROTOCOLS_STR) introduced in commit e6f8445 to verify the missing check. Could you point to the specific file/function where the protocol string is parsed, or we will retrieve it from the repository at that revision?

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

Report claims

C1flaw not verifiable

When --proto is used with a string that starts with -all and only removes protocols (e.g., --proto -all,-http), curl fails to properly disable the specified protocols and may enable all protocols, leading to unintended protocol usage.

Read the reasoning

No curl source code was provided for the revision in question (d5b0fee39a78). The claim describes a flaw in the protocol selection logic for CURLOPT_PROTOCOLS_STR, but without the implementation code (likely in lib/setopt.c or lib/urlapi.c), the claim cannot be verified against the actual bounds checks or parsing logic.

C2location not verifiable

The issue occurs in the protocol selection logic implemented after commit e6f8445edef8e7996d1cfb141d6df184efef972c, which introduced string-based protocol selection via CURLOPT_PROTOCOLS_STR and CURLOPT_REDIR_PROTOCOLS_STR.

Read the reasoning

The commit e6f8445edef8e7996d1cfb141d6df184efef972c is referenced as the introduction point, but no source code from that commit or the current master was retrieved. The deterministic checks returned 'nothing_to_check', so the location cannot be confirmed in the provided materials.

C3trigger not verifiable

Providing a --proto argument that begins with -all and only lists protocols to remove (e.g., --proto -all,-http) triggers the bug, causing curl to treat the request as if all protocols are enabled.

Read the reasoning

The trigger condition (--proto argument starting with -all and only removing protocols) depends on the parser's handling of the protocol string. Without the parsing code, it is impossible to confirm whether the described input path reaches a missing check.

C4impact not verifiable

The bug can result in data being transmitted over an unencrypted channel when the user expects the connection to be blocked or use an encrypted protocol, potentially exposing sensitive information.

Read the reasoning

The impact claim is conditional on the bug existing. Since the bug's existence cannot be verified without the protocol selection code, the impact cannot be assessed as a real security consequence.

C5reproduction not verifiable

Running the command `curl -Ivs --proto -all,-http http://curl.se` should produce `curl: (1) Protocol "http" disabled` but instead succeeds, demonstrating that the http protocol is not properly disabled.

Read the reasoning

The reproduction command is specific and testable, but the expected behavior ('curl: (1) Protocol "http" disabled') versus actual behavior depends on the protocol disablement logic, which is not present in the provided materials.

Read the original report (excerpt)

Full report on HackerOne ↗

## Summary: ` --proto` in some circumstances ENABLES all protocols after being given `-all`, potentially leading to sending sensitive data over an unencrypted channel. ## Steps To Reproduce: `curl -Ivs --proto -all,-http http://curl.se` This command should result in `curl: (1) Protocol "http" disabled` but it actually succeeds. ## Supporting Material/References: The example command above performs a request to curl.se over http, despite being http support being disabled, both implicitly (-all) and explicitly (-http). It appears that a `--proto` string starting with `-all` and only ever removes protocols without adding them fails in this way. For example: Example failure scenarios (allowing ALL protocols to go through): ``` --proto -all --proto -all,-http --proto -all,-ftp,-smtp,-pop3 ``` Example correct scenarios (behaving as documented): ``` --proto -all,https --proto -all,https,-http --proto -all,-ftp,-smtp,-pop3,pop3s --proto -http ``` The only failure scenarios I could find were those that first removed all protocols with -all, then (optionally) removed additional, individual protocols, and never added any. The documented behaviour for this would be to fail ALL curl transfers, so it shouldn't happen anywhere in production situations (since generally people want to do transfers with curl). However, I could still imagine it happening, such as when the list of allowed protocols is programmatically computed in a system where a particular situation should not allow any transfers. But this bug means that transfers would go ahead, anyway. In a situation where something is relying on curl to block an unencrypted transfer, the consequences of this bug can be pretty severe (unencrypted data travelling over the Internet) and therefore High severity. On the other hand, IF this is the only situation where this bug occurs (where all protocols are supposed to be disabled), then I'm guessing this generally pretty uncommon and therefore Medium or even Low may be more appropriate. It's hard to know if anyone is relying on this. I bisected the problem to [this commit]( https://github.com/curl/curl/commit/e6f8445edef8e7996d1cfb141d6df184efef972c) which was released in 7.85.0 and introduced string-based protocol selection: ``` e6f8445edef8e7996d1cfb141d6df184efef972c is the first bad commit commit e6f8445edef8e7996d1cfb141d6df184efef972c Author: Daniel Stenberg <daniel@ …

Source code

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