# CVE-2021-22926: CURLOPT_SSLCERT mixup with Secure Transport

curl's Secure Transport backend resolves CURLOPT_SSLCERT against the current directory before the keychain, so a planted file of the same name blocks keychain client-cert auth.

- Payout: hidden
- Severity: medium
- Program: curl
- Found by: nyymi
- Disclosed: 2021-07-21
- CVE: CVE-2021-22926
- Write-up quality: 6/10
- Original: https://hackerone.com/reports/1234760
- Library page: https://bugbountylibrary.com/r/h1%3A1234760
- Tags: area:os domain:desktop impact:dos kind:bounty platform:hackerone sev:medium tech:curl vuln:dos vuln:misconfiguration

**Target:** libcurl Secure Transport TLS backend (macOS)
**Root cause:** The Secure Transport backend does not check whether CURLOPT_SSLCERT names a keychain nickname before treating it as a file path, so a same-named file in the CWD takes precedence over the keychain entry. The NSS backend has such a check; Secure Transport lacks it.
**Steps:**
1. Build curl with `configure --with-secure-transport && make`
2. Ensure keychain holds client cert nicknamed `testcert`
3. Run `./src/curl -E testcert https://testsite` (succeeds)
4. In CWD run `touch testcert`
5. Re-run `./src/curl -E testcert https://testsite` -> `curl: (58) SSL: Can't load the certificate "testcert" and its private key: OSStatus -50`
**How found:** Noticed the Secure Transport code lacks the keychain-vs-file disambiguation present in nss.c, then confirmed by planting a same-named file in the CWD and observing cert load failure.
**Exploitation:** Attacker with write access to a directory the victim runs curl from (e.g. /tmp or another user's home) creates a file matching the keychain nickname used by the app, causing cert load failure and blocking authenticated connections.
**Insight:** When a TLS backend accepts either a keychain nickname or a file path in one option, check whether path resolution happens before keychain lookup; compare sibling backends (NSS) for the missing guard.