{“lastseen”:”2025-11-26T10:25:50″,”description”:”## Summary:\\n\\nVulnerability impact: When curl attempts to download files from a malicious FTP server, it triggers an infinite loop in the code execution.\\n\\nI discovered this issue in the FTP functionality of the curl project .As described in https:\/\/github.com\/curl\/curl\/blob\/master\/docs\/cmdline-opts\/disable-epsv.md, curl uses EPSV mode as the default FTP file transfer method. In simple terms, the EPSV mode works as follows: the FTP server opens a TCP port and waits for the client to connect, then sends data to the client through this port.\\n\\nIn the state machine of curl, the `state_performing` function in `\/lib\/multi.c` calls the `Curl_sendrecv` function at [1] to receive data from the peer:\\n“`\\nstatic CURLMcode state_performing(struct Curl_easy *data,\\n struct curltime *nowp,\\n bool *stream_errorp,\\n CURLcode *resultp)\\n{\\n char *newurl = NULL;\\n bool retry = FALSE;\\n CURLMcode rc = CURLM_OK;\\n CURLcode result = *resultp = CURLE_OK;\\n *stream_errorp = FALSE;\\n\\n if(mspeed_check(data, nowp) == CURLE_AGAIN)\\n return CURLM_OK;\\n\\n \/* read\/write data if it is ready to do so *\/\\n result = Curl_sendrecv(data, nowp); \/\/ [1] call Curl_sendrecv\\n\\n if(data-\\u003ereq.done || (result == CURLE_RECV_ERROR)) {\\n \/* If CURLE_RECV_ERROR happens early enough, we assume it was a race\\n * condition and the server closed the reused connection exactly when we\\n * wanted to use it, so figure out if that is indeed the case.\\n *\/\\n CURLcode ret = Curl_retry_request(data, \\u0026newurl);\\n if(!ret)\\n retry = !!newurl;\\n else if(!result)\\n result = ret;\\n\\n if(retry) {\\n \/* if we are to retry, set the result to OK and consider the\\n request as done *\/\\n result = CURLE_OK;\\n data-\\u003ereq.done = TRUE;\\n }\\n }\\n…\\n“`\\n\\n\\nThe `Curl_sendrecv` function calls `sendrecv_dl` at [2]:\\n“`\\nCURLcode Curl_sendrecv(struct Curl_easy *data, struct curltime *nowp)\\n{\\n struct SingleRequest *k = \\u0026data-\\u003ereq;\\n CURLcode result = CURLE_OK;\\n\\n DEBUGASSERT(nowp);\\n if(Curl_xfer_is_blocked(data)) {\\n result = CURLE_OK;\\n goto out;\\n }\\n\\n \/* We go ahead and do a read if we have a readable socket or if the stream\\n was rewound (in which case we have data in a buffer) *\/\\n if(k-\\u003ekeepon \\u0026 KEEP_RECV) {\\n result = sendrecv_dl(data, k); \/\/[2] call sendrecv_dl\\n if(result || data-\\u003ereq.done)\\n goto out;\\n }\\n \\n…\\n“`\\n\\nThe `sendrecv_dl` function further calls `xfer_recv_resp` to receive data. If our malicious FTP server opens an EPSV port but does not send any data to the client, `xfer_recv_resp` will return `-1`, and the value of `result` will be set to `CURLE_AGAIN`. Subsequently, at [4], the `result` is set to `CURLE_OK`. This means that even if `xfer_recv_resp` fails to receive any data, the `sendrecv_dl` function still returns `CURLE_OK`.\\n\\n“`\\nstatic CURLcode sendrecv_dl(struct Curl_easy *data,\\n struct SingleRequest *k)\\n{\\n…\\n rcvd_eagain = FALSE;\\n nread = xfer_recv_resp(data, buf, bytestoread, is_multiplex, \\u0026result); \/\/ [3] call xfer_recv_resp\\n if(nread \\u003c 0) {\\n if(CURLE_AGAIN != result)\\n goto out; \/* real error *\/\\n rcvd_eagain = TRUE;\\n result = CURLE_OK; \/\/[4]set result to CURLE_OK\\n if(data-\\u003ereq.download_done \\u0026\\u0026 data-\\u003ereq.no_body \\u0026\\u0026\\n !data-\\u003ereq.resp_trailer) {\\n DEBUGF(infof(data, \\”EAGAIN, download done, no trailer announced, \\”\\n \\”not waiting for EOS\\”));\\n nread = 0;\\n \/* continue as if we received the EOS *\/\\n }\\n else\\n break; \/* get out of loop *\/\\n }\\n…\\n“`\\n\\n\\nLet’s continue examining the `state_performing` function:\\n“`\\nstatic CURLMcode state_performing(struct Curl_easy *data,\\n struct curltime *nowp,\\n bool *stream_errorp,\\n CURLcode *resultp)\\n{\\n char *newurl = NULL;\\n bool retry = FALSE;\\n CURLMcode rc = CURLM_OK;\\n CURLcode result = *resultp = CURLE_OK;\\n *stream_errorp = FALSE;\\n\\n if(mspeed_check(data, nowp) == CURLE_AGAIN)\\n return CURLM_OK;\\n\\n \/* read\/write data if it is ready to do so *\/\\n result = Curl_sendrecv(data, nowp);\\n\\n if(data-\\u003ereq.done || (result == CURLE_RECV_ERROR)) { \/\/ [5] data-\\u003ereq.done == 0, result==CURLE_OK\\n \/* If CURLE_RECV_ERROR happens early enough, we assume it was a race\\n * condition and the server closed the reused connection exactly when we\\n * wanted to use it, so figure out if that is indeed the case.\\n *\/\\n CURLcode ret = Curl_retry_request(data, \\u0026newurl);\\n if(!ret)\\n retry = !!newurl;\\n else if(!result)\\n result = ret;\\n\\n if(retry) {\\n \/* if we are to retry, set the result to OK and consider the\\n request as done *\/\\n result = CURLE_OK;\\n data-\\u003ereq.done = TRUE;\\n }\\n }\\n#ifndef CURL_DISABLE_HTTP\\n else if((CURLE_HTTP2_STREAM == result) \\u0026\\u0026\\n Curl_h2_http_1_1_error(data)) {\\n CURLcode ret = Curl_retry_request(data, \\u0026newurl);\\n\\n if(!ret) {\\n infof(data, \\”Downgrades to HTTP\/1.1\\”);\\n streamclose(data-\\u003econn, \\”Disconnect HTTP\/2 for HTTP\/1\\”);\\n data-\\u003estate.http_neg.wanted = CURL_HTTP_V1x;\\n data-\\u003estate.http_neg.allowed = CURL_HTTP_V1x;\\n \/* clear the error message bit too as we ignore the one we got *\/\\n data-\\u003estate.errorbuf = FALSE;\\n if(!newurl)\\n \/* typically for HTTP_1_1_REQUIRED error on first flight *\/\\n newurl = strdup(data-\\u003estate.url);\\n if(!newurl) {\\n result = CURLE_OUT_OF_MEMORY;\\n }\\n else {\\n \/* if we are to retry, set the result to OK and consider the request\\n as done *\/\\n retry = TRUE;\\n result = CURLE_OK;\\n data-\\u003ereq.done = TRUE;\\n }\\n }\\n else\\n result = ret;\\n }\\n#endif\\n\\n if(result) { \/\/[6] result==CURLE_OK\\n \/*\\n * The transfer phase returned error, we mark the connection to get closed\\n * to prevent being reused. This is because we cannot possibly know if the\\n * connection is in a good shape or not now. Unless it is a protocol which\\n * uses two \\”channels\\” like FTP, as then the error happened in the data\\n * connection.\\n *\/\\n\\n if(!(data-\\u003econn-\\u003ehandler-\\u003eflags \\u0026 PROTOPT_DUAL) \\u0026\\u0026\\n result != CURLE_HTTP2_STREAM)\\n streamclose(data-\\u003econn, \\”Transfer returned error\\”);\\n\\n multi_posttransfer(data);\\n multi_done(data, result, TRUE);\\n }\\n else if(data-\\u003ereq.done \\u0026\\u0026 !Curl_cwriter_is_paused(data)) { \/\/[7] data-\\u003ereq.done == 0\\n const struct Curl_handler *handler = data-\\u003econn-\\u003ehandler;\\n\\n \/* call this even if the readwrite function returned error *\/\\n multi_posttransfer(data);\\n\\n \/* When we follow redirects or is set to retry the connection, we must to\\n go back to the CONNECT state *\/\\n if(data-\\u003ereq.newurl || retry) {\\n followtype follow = FOLLOW_NONE;\\n if(!retry) {\\n \/* if the URL is a follow-location and not just a retried request then\\n figure out the URL here *\/\\n free(newurl);\\n newurl = data-\\u003ereq.newurl;\\n data-\\u003ereq.newurl = NULL;\\n follow = FOLLOW_REDIR;\\n }\\n else\\n follow = FOLLOW_RETRY;\\n (void)multi_done(data, CURLE_OK, FALSE);\\n \/* multi_done() might return CURLE_GOT_NOTHING *\/\\n result = multi_follow(data, handler, newurl, follow);\\n if(!result) {\\n multistate(data, MSTATE_SETUP);\\n rc = CURLM_CALL_MULTI_PERFORM;\\n }\\n }\\n else {\\n \/* after the transfer is done, go DONE *\/\\n\\n \/* but first check to see if we got a location info even though we are\\n not following redirects *\/\\n if(data-\\u003ereq.location) {\\n free(newurl);\\n newurl = data-\\u003ereq.location;\\n data-\\u003ereq.location = NULL;\\n result = multi_follow(data, handler, newurl, FOLLOW_FAKE);\\n if(result) {\\n *stream_errorp = TRUE;\\n result = multi_done(data, result, TRUE);\\n }\\n }\\n\\n if(!result) {\\n multistate(data, MSTATE_DONE);\\n rc = CURLM_CALL_MULTI_PERFORM;\\n }\\n }\\n }\\n else { \/* not errored, not done *\/\\n mspeed_check(data, nowp); \/\/ [8]\\n }\\n free(newurl);\\n *resultp = result;\\n return rc;\\n}\\n\\n“`\\n\\nSince no data was received, the `data-\\u003ereq.done` flag remains 0. Furthermore, because the result is `CURLE_OK`, the conditional checks at [5], [6], and [7] all evaluate to false. The code then proceeds to [8] (not errored, not done).\\n\\nThis causes curl’s current state machine flag (`data-\\u003emstate`) to remain unchanged, still set to `MSTATE_PERFORMING`. Subsequently, the curl code repeatedly enters the `state_performing` function, resulting in an infinite loop.\\n\\n\\n\\n## Affected version\\n\\ncurl : https:\/\/github.com\/curl\/curl\/archive\/refs\/tags\/curl-8_17_0.tar.gz\\nplatform : ubuntu22.04\\n\\n“`\\n\u279c src .\/curl -V \\ncurl 8.17.0-DEV (x86_64-pc-linux-gnu) libcurl\/8.17.0-DEV zlib\/1.2.11 libpsl\/0.19.1\\nRelease-Date: [unreleased]\\nProtocols: dict file ftp gopher http imap ipfs ipns mqtt pop3 rtsp smtp telnet tftp ws\\nFeatures: alt-svc AsynchDNS IPv6 Largefile libz PSL threadsafe UnixSockets\\n“`\\n## Steps To Reproduce:\\n\\n1. Download the attached .\/ftp_poc.py file and run: sudo python3 .\/ftp_poc.py. This will start a malicious FTP service on port 21 of the current machine.\\n2. Run the following curl command, replacing 192.168.23.1 in the command with the address of your own malicious FTP server:\\n“`\\n.\/curl -u anonymous:123 ‘ftp:\/\/192.168.23.1\/test’ -o .\/test\\n“`\\n\\n3. The curl program will enter an infinite code loop and will not exit on its own.\\n\\n## Impact\\n\\n## Summary:\\nWhen curl attempts to download files from a malicious FTP server, it triggers an infinite loop in the code execution.”,”published”:”2025-11-26T08:34:04″,”modified”:”2025-11-26T09:32:38″,”type”:”hackerone”,”title”:”curl: Infinite loop issue in the state machine of the curl project”,”source”:””,”references”:””,”id”:”H1:3442060″,”bulletinFamily”:”bugbounty”,”cwe”:null,”cvelist”:[],”sourceData”:””,”sourceHref”:””,”cvss”:{“score”:0,”severity”:”NONE”,”vector”:”NONE”,”version”:”NONE”},”cvss2″:{},”cvss3″:{“version”:””,”vectorString”:””,”baseScore”:0,”baseSeverity”:””,”attackVector”:””,”attackComplexity”:””,”privilegesRequired”:””,”userInteraction”:””,”scope”:””,”confidentialityImpact”:””,”integrityImpact”:””,”availabilityImpact”:””,”cvssV3″:{“version”:””,”vectorString”:””,”baseScore”:0,”baseSeverity”:””,”attackVector”:””,”attackComplexity”:””,”privilegesRequired”:””,”userInteraction”:””,”scope”:””,”confidentialityImpact”:””,”integrityImpact”:””,”availabilityImpact”:””}},”href”:”https:\/\/hackerone.com\/reports\/3442060″,”category_name”:”News”,”post_link”:””,”product”:””,”version”:””,”vendor”:””,”ai_description”:””,”ai_severity”:””,”ai_vendor”:””,”ai_product”:””,”ai_version”:””,”ai_score”:0}<\/p>\n","protected":false},"excerpt":{"rendered":"
{“lastseen”:”2025-11-26T10:25:50″,”description”:”## Summary:\\n\\nVulnerability impact: When curl attempts to download files from a malicious FTP server, it triggers an infinite loop in the code execution.\\n\\nI discovered this…<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[4],"tags":[6,8,12,117,13,33,7,11,5],"class_list":["post-27698","post","type-post","status-publish","format-standard","hentry","category-category_news","tag-cve","tag-cvss","tag-exploit","tag-hackerone","tag-news","tag-none","tag-security","tag-tapic","tag-vulnerability"],"yoast_head":"\n