TOCTOU Race Condition in HTTP/2 Connection Reuse Leads to Certificate Validation Bypass
What the report claims
TOCTOU race condition in HTTP/2 connection reuse allows certificate validation bypass via post-handshake CA file modification.
Compare with curl's recorded outcome
Labeled AI slop
curl's maintainer lists this report as AI slop
Shown for comparison after analysis. The pipeline did not see this label.
ProveIt's finding
The available evidence does not settle the report. A maintainer should investigate.
curl policy: Local attackers already presentSee the withdrawn model reasoning
The following reasoning failed the citation check and does not support the final finding.
- The attack requires local write access to the CA trust store file, which curl's policy explicitly excludes: 'When an issue can only be attacked by an attacker present on the local system... the problem is not really in curl' and 'curl cannot protect against attacks where an attacker has write access to the same directory where curl is directed to save files.'
- The PoC does not demonstrate a Man-in-the-Middle attack: both requests go to the legitimate server (server log confirms). The server's certificate is unchanged and valid for the host. Connection reuse continues to the real server — the attacker gains no interception capability.
- RFC 7540 Section 9.1.1 requires the certificate to be valid for the host, which it remains. The trust store change is a local configuration mutation, not a certificate validity change.
- The relevant curl connection reuse and certificate validation code was not provided for verification, but the policy and attack analysis are sufficient.
How this analysis ran 5 claims · 0 citations verified
Evidence check: judge quoted an external source that does not say that (https://datatracker.ietf.org/doc/html/rfc7540#section-9.1.1)
Checked against curl master on 2025-09-11 (839b22863e2f). Test evaluation split. Citation verification checks that a referenced line was in the evidence; it does not prove the model interpreted it correctly.
Inspect the withdrawn draft reply
This draft belongs to the withdrawn judgment. It may contain unsupported claims.
Thank you for the detailed report. However, this falls under curl's 'Local attackers already present' and 'Saving files' policy exclusions: an attacker who can modify your CA trust store file already controls what curl trusts and can do far worse. The PoC shows both requests reaching the legitimate server — no MitM is achieved because connection reuse keeps the original TLS session to the real server. The certificate remains valid for the host per RFC 7540; only the local trust store changed. This is not considered a security vulnerability in curl.
Inspect all claims and source code 5 claims · 1 code excerpts
This model judgment was withdrawn. The claim assessments below are preserved for inspection and may be wrong.
Report claims
libcurl assumes trust from initial certificate validation is permanent for the entire connection lifecycle
Read the reasoning
The provided source code only shows curl_easy_perform (lib/easy.c:844-847), a thin wrapper. The actual TLS handshake, certificate validation, and HTTP/2 connection reuse logic (likely in lib/vtls.c, lib/openssl.c, lib/conncache.c, or lib/http2.c) are not provided. Cannot verify whether libcurl assumes trust is permanent.
in libcurl's handling of persistent HTTP/2 connections during TLS handshake
Read the reasoning
The code handling persistent HTTP/2 connections and TLS handshake is not in the provided source snippets. SSL_CTX_set_alpn_protocols is an OpenSSL API, not curl's connection reuse logic.
attacker modifies CA file on disk after initial validation but before subsequent requests
Read the reasoning
The attack script (attack.sh in the report) demonstrates this trigger: a background process swaps the CA file symlink after 0.5s while curl makes two requests. This is a described attack vector, not a code claim.
subsequent HTTP/2 streams bypass certificate validation enabling full Man-in-the-Middle attack
Read the reasoning
The PoC shows both requests go to the same legitimate server presenting a certificate signed by the legitimate CA. The CA file swap changes the client's trust store, not the server's certificate. Connection reuse continues to the real server — no MitM position is gained. The attacker would need to redirect traffic to their own server, but connection reuse prevents that. RFC 7540 requires the certificate to be valid for the host, which it remains.
symlink swap race condition causing both requests to succeed despite CA change
Read the reasoning
The attack script demonstrates this race condition: symlink swap between requests causing both to succeed. This describes the PoC behavior accurately.
What the report says about other projects
confirmed The server certificate must be signed by a trusted CA for validation to succeed
“The certificates to add to the trust store can be specified using following options. -CAfile file Load the specified file which contains a certificate or several of them in case the input is in PEM or PKCS#12 format.” source
confirmed HTTP/2 connection reuse requires the same TLS session to be reused only if the security parameters are identical
“For 'https' resources, connection reuse additionally depends on having a certificate that is valid for the host in the URI. The certificate presented by the server MUST satisfy any checks that the client would perform when forming a new TLS connection for the host in the URI.” source
Read the original report (excerpt)
Source code
| 844 | CURLcode curl_easy_perform(CURL *data) |
| 845 | { |
| 846 | return easy_perform(data, FALSE); |
| 847 | } |