✓ProveIt
Examples / Report #1892780 Saved analysis

CVE-2023-27535: FTP too eager connection reuse

curl · 2023-03-058.7s analysis · $0.007 in model calls

What the report claims

libcurl FTP(S) protocol reuses connections even when different CURLOPT_FTP_ACCOUNT or --ftp-account values are specified, causing wrong credentials to be used.

Compare with curl's recorded outcome

Known vulnerability

A real vulnerability: CVE-2023-27535 FTP too eager connection reuse

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?
  • No curl source code was provided for the revision in question (8cfc936f5c9d), so the FTP connection reuse logic cannot be examined.
  • The deterministic checks only confirm that symbols like CURLOPT_FTP_ACCOUNT and STRING_FTP_ALTERNATIVE_TO_USER exist, not how they are used in connection reuse decisions.
  • The RFC 959 excerpts provided do not contain the reply code definitions needed to verify claim C3.
  • The report is plausible and includes concrete reproduction steps, but the code evidence required to confirm the vulnerability is missing.
What still needs checking
  • The FTP connection reuse implementation (likely in lib/ftp.c or similar) showing how CURLOPT_FTP_ACCOUNT and STRING_FTP_ALTERNATIVE_TO_USER are compared when deciding whether to reuse a connection.
  • The handling of FTP reply code 332 in the protocol state machine.
How this analysis ran 5 claims · 0 citations verified

Checked against curl master on 2023-03-05 (8cfc936f5c9d). 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 · 4 references checked out, 0 did not
2 · Claims
NVIDIA-Nemotron-3-Nano-30B-A3B
5 claims · 1572 tokens · $0.0002
3 · Evidence
0 code snippets
real curl source at 8cfc936f5c9d · 3 docs via Tavily
4 · Judgment
Nemotron-3-Ultra-550b-a55b
4430 tokens · 6.3s · $0.0072
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 reproduction steps. To evaluate this, we need to see the FTP connection reuse logic in libcurl (likely in lib/ftp.c) around the revision you tested. Could you point to the specific function or file where connection reuse is decided, or provide a link to the relevant code on GitHub? The symbols CURLOPT_FTP_ACCOUNT and STRING_FTP_ALTERNATIVE_TO_USER exist, but we need to see how they factor into the reuse check.

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

Report claims

C1flaw not verifiable

Connection reuse occurs when different CURLOPT_FTP_ACCOUNT values are specified for different connections and the server replies with code 332

Read the reasoning

The central claim is that FTP connection reuse occurs incorrectly when CURLOPT_FTP_ACCOUNT differs and the server sends reply 332. No curl source code was provided in the context (curl_source states 'no curl code could be retrieved'), so the connection reuse logic cannot be examined to confirm or contradict this claim.

C2location not verifiable

The flaw is in the FTP connection reuse logic in libcurl

Read the reasoning

The claim locates the flaw in 'FTP connection reuse logic' but no source files or functions are provided to verify this location.

C3trigger not verifiable

Server sends reply code 332 to request account authentication

Read the reasoning

The claim that reply code 332 requests account authentication per RFC 959 cannot be verified from the provided external sources. The RFC 959 excerpts (E3) are truncated page headers without the reply code definitions. No decisive sentence confirming the meaning of code 332 is present.

C4impact not verifiable

Wrong cached credentials are used for subsequent FTP requests

Read the reasoning

This impact claim depends on C1 being true. Since C1 is not verifiable without the connection reuse code, C4 cannot be assessed.

C5reproduction not verifiable

Use three terminals to start netcat listeners, send FTP commands with 332 reply, then run curl with different --ftp-account values

Read the reasoning

The reproduction steps describe a test setup using netcat and curl command lines. While the steps are concrete, they cannot be validated against the actual curl implementation without the FTP connection reuse code.

What the report says about other projects

not addressed RFC 959 defines reply code 332 as requesting account authentication

Read the original report

Full report on HackerOne ↗

## Summary: libcurl FTP(S) protocol will reuse connection even if different `CURLOPT_FTP_ACCOUNT` (libcurl) or `--ftp-account` (curl) is specified for different connections and the server requests account authentication via reply code `332`. It appears that `STRING_FTP_ALTERNATIVE_TO_USER ` (libcurl) or `--ftp-alternative-to-user` (curl) is also affected and should also result in caching being refused. ## Steps To Reproduce: 1. terminal 1: `echo -e "foo\n" | nc -v -l -p 9998; echo -e "bar\n" | nc -v -l -p 9998` 2. terminal 2: `echo -ne "220 a\n331 b\n332 c\n230 d\n257 \"/\"\n229 (|||9998|)\n200 e\n213 4\n150 f\n226 g\n229 (|||9998|)\n213 4\n150 f\n226 g\n" | nc -v -l -p 9999` 3. terminal 3: `curl -v --ftp-account alice "ftp://ftp@server:9999/file1" -: --ftp-account bob "ftp://ftp@server:9999/file2"` As a result connection authenticated as user `alice` will be used when fetching `file2` regardless that user `bob` was specified for fetching it. ## Remediation * Don't reuse connection if `CURLOPT_FTP_ACCOUNT` or `STRING_FTP_ALTERNATIVE_TO_USER` are different. ## Supporting Material/References: * https://www.ietf.org/rfc/rfc0959.txt ## Impact Accessing content with wrong cached credentials.

Source code

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