CVE-2023-27535 - Authentication Bypass in libcurl FTP Connection Reuse (Explained, With Exploit Example)

When we use powerful tools, it’s easy to forget that tiny details can leave big cracks open. That’s what CVE-2023-27535, an authentication bypass vulnerability in libcurl, has shown us. If you ever use libcurl for FTP transfers — especially in shared or multi-user environments, or with multiple sets of FTP credentials — you must understand what happened, how exploit works, and how to protect your systems.

What is CVE-2023-27535?

CVE-2023-27535 is an authentication bypass vulnerability in libcurl, a massively popular library for transferring data with URLs. The bug affects versions before 8... The core issue is how FTP connections are reused in libcurl: when making multiple FTP transfers, libcurl reuses already established connections for efficiency. This is fine unless the reused connection was made using different authentication or security settings — like a different username, password, FTP account, or SSL mode.

Unfortunately, libcurl’s connection-pool matching logic did not include several important options in its checks:

CURLOPT_USE_SSL

This flaw means it’s dangerously easy for another transfer to "accidentally" reuse a connection with different settings, sending the wrong credentials, and potentially allowing unintended access to sensitive files.

libcurl keeps this connection in a pool for later reuse.

3. Later, another transfer to ftp.example.com is made, but this time as User B — with a different CURLOPT_FTP_ACCOUNT or SSL mode, for instance.
4. libcurl’s buggy matching logic says: “Hey, this old connection looks similar!” and reuses it...
5. The result: This second transfer happens using User A's old authentication context, possibly giving User B access they should NOT have.


## Exploit Example (C/C++)

To really see the bug, you can simulate it yourself. This is a distilled example in C using libcurl’s API. Let's see what happens if you swap accounts between transfers:

#include <curl/curl.h>
#include <stdio.h>

int main(void) {
    CURL *curl;
    CURLcode res;

    curl_global_init(CURL_GLOBAL_DEFAULT);

    // 1. First transfer: User A
    curl = curl_easy_init();
    if(curl) {
        curl_easy_setopt(curl, CURLOPT_URL, "ftp://ftp.example.com/fileA.txt");
        curl_easy_setopt(curl, CURLOPT_USERNAME, "userA");
        curl_easy_setopt(curl, CURLOPT_PASSWORD, "passwordA");
        curl_easy_setopt(curl, CURLOPT_FTP_ACCOUNT, "accountA"); // Not included in "connection unique" check!
        curl_easy_perform(curl);  // open connection, authenticate as userA

        // 2. Transfer for another user, different account ONLY
        curl_easy_setopt(curl, CURLOPT_URL, "ftp://ftp.example.com/fileB.txt");
        curl_easy_setopt(curl, CURLOPT_USERNAME, "userB");
        curl_easy_setopt(curl, CURLOPT_PASSWORD, "passwordB");
        curl_easy_setopt(curl, CURLOPT_FTP_ACCOUNT, "accountB"); // This setting IGNORED in matching!
        res = curl_easy_perform(curl); // may reuse old connection!
        curl_easy_cleanup(curl);
    }

    curl_global_cleanup();
    return ;
}

Expected: The upload/download for User B should happen as B.

Buggy reality: The reused connection can actually keep using User A’s credentials/settings if the system is still running a vulnerable libcurl — possibly letting User B read, write, or even delete files as User A.

Why Does This Happen?

The code that matches connections in libcurl did NOT look at values for CURLOPT_FTP_ACCOUNT, CURLOPT_FTP_ALTERNATIVE_TO_USER, CURLOPT_FTP_SSL_CCC, or CURLOPT_USE_SSL. So if two transfers went to the same host and port, same "plain" user and basic auth, but changed one of these -- libcurl still saw the two requests as good enough to share the same connection. This slight mismatch may look harmless, but on real servers, these settings matter a lot (for example, ACCOUNT can give extra privileges).

Official References & Links

- cURL Security Advisory - March 2023
- CVE-2023-27535 on NIST
- Upstream curl GitHub patch
- Detailed libcurl documentation

Upgrade now!

- The only reliable fix is to upgrade libcurl to 8.. or newer. Connection matching has been fixed there to respect these settings.

curl_easy_setopt(curl, CURLOPT_FORBID_REUSE, 1L);

`
- Always verify which user credentials are being used *before* sensitive transfers.

---

## Conclusion

CVE-2023-27535 is a great example of why connection "optimization" needs strong security checks. Don’t let old connections create new security nightmares! Remember, in environments where people share FTP servers, this little oversight could enable privilege escalation, data leakage, or damage. Patch your libcurl, and use connection pools with caution in security-sensitive applications.

Security is about the details — and this CVE shows how important those details are.

---

Stay safe, and keep your libraries patched!

Timeline

Published on: 03/30/2023 20:15:00 UTC
Last modified on: 04/21/2023 23:15:00 UTC