bypass of this Fixed #2437131 [ Inadequate Protocol Restriction Enforcement in curl ]
What the report claims
The --proto option's protocol restrictions can be bypassed, allowing HTTP requests despite explicit disabling of all protocols.
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
The code does what the report says, but curl's own policy may exclude it. A maintainer decides.
curl policy: Tricking a user to run a command lineSee the withdrawn model reasoning
The following reasoning failed the citation check and does not support the final finding.
- The report's own reproduction steps show two independent curl invocations, not a bypass within a single invocation.
- The first command correctly blocks HTTP when --proto disables it.
- The second command succeeds because it explicitly uses '--proto http' to allow HTTP.
- No code path is shown where an attacker-controlled input evades the --proto restriction of the same command.
- The project policy lists 'Tricking a user to run a command line' as not a security issue.
How this analysis ran 5 claims · 0 citations verified
Evidence check: the behavior is real; the project's policy section 'Tricking a user to run a command line' may exclude it
Checked against curl master on 2024-12-18 (c5052a01874b). Dev evaluation split. Citation verification checks that a referenced line was in the evidence; it does not prove the model interpreted it correctly.
Inspect the withdrawn draft reply
This draft belongs to the withdrawn judgment. It may contain unsupported claims.
The reproduction steps show two separate curl commands. The first ('--proto -all,-http') correctly blocks HTTP. The second ('--proto http') explicitly allows HTTP in a new, independent invocation. This is expected behavior: each curl command evaluates its own --proto option. No bypass of a single command's restrictions is demonstrated. If you believe a single invocation can evade its own --proto setting, please provide a single command line that does so.
Inspect all claims and source code 5 claims · 0 code excerpts
This model judgment was withdrawn. The claim assessments below are preserved for inspection and may be wrong.
Report claims
The --proto option can be bypassed to allow unintended protocols
Read the reasoning
The report claims a bypass of protocol restrictions, but the described behavior shows two independent curl commands. The first correctly enforces the restriction (HTTP disabled). The second explicitly requests HTTP and gets it. No single invocation bypasses its own --proto setting.
The bypass occurs in the protocol restriction enforcement logic
Read the reasoning
No bypass within a single invocation is demonstrated. The enforcement logic appears to work as designed: each curl command evaluates its own --proto argument independently.
Using --proto -all,-http or --proto =all to attempt to disable HTTP
Read the reasoning
The trigger commands are misunderstood by the reporter. '--proto =all' enables all protocols including HTTP; '--proto -all,-http' disables all then redundantly disables HTTP. The first command in the reproduction fails as expected when HTTP is disabled.
HTTP requests can be made over plaintext despite restrictions
Read the reasoning
HTTP requests succeed only when the current invocation's --proto option allows HTTP. The 'initial restrictions' applied only to the first invocation. This is expected behavior, not a flaw.
Reproduce by running curl --proto -all,-http http://example.com and observing the error, then curl --proto http http://evil.com to bypass
Read the reasoning
The reproduction steps do not demonstrate a bypass. They demonstrate that each curl command independently evaluates its --proto argument. The second command works because it requests HTTP, not because it evades a prior restriction.
Read the original report (excerpt)
Source code
No source code was retrieved for this analysis. The evidence may be incomplete.