Windows TLS 1.3 data corruption risk with schannel 0.1.28
Open 💬 2 comments Opened Jul 12, 2026 by Kangaxx-0
While investigating a Windows TLS issue, I noticed that Codex still resolves schannel 0.1.28 in both codex-rs/Cargo.lock and MODULE.bazel.lock.
On Windows, Codex's default reqwest configuration can use this dependency path: reqwest -> hyper-tls -> native-tls -> schannel
That version has a known TLS 1.3 bug in its nonblocking stream handling. When reads and writes are interleaved while application data is still buffered, a post-handshake message can cause the pending data to be sent twice. The server then receives corrupted application data
schannel 0.1.29 includes a fix for TLS 1.3 data corruption caused by buffered application data being sent twice while handling SEC_I_RENEGOTIATE:
2 Comments
One scope clarification: the behavior that led me to investigate this was observed while using a custom model provider, not an OpenAI-hosted model endpoint.
We’ve independently encountered the same issue in our Rust-based agent when using third-party model endpoints such as DeepSeek. Our build was also using schannel v0.1.28, and the issue is real and reproducible. Related investigation: https://github.com/r1n7aro/Locus/issues/48