Affected: Homebrew: jupyterlab

# CurlAsyncHTTPClient leaks per-request credentials on handle reuse

## Summary

`CurlAsyncHTTPClient` pools and reuses `pycurl` handles across requests but does not reset them between requests, and several per-request options are applied with no clearing branch. As a result, sensitive state set by one request persists onto a later request on the same client that does not set it. Two credential vectors are demonstrated below — a client TLS certificate (`SSLCERT`/`SSLKEY`) and proxy basic-auth credentials (`PROXYUSERPWD`) — both leaking to a different, unintended host. This affects all released versions through 6.5.6.

## Details

In `tornado/curl_httpclient.py`, handles are created once and returned to a free list for reuse (`_process_queue` pops the handle at line 200, `_finish` re-appends it at line 245), and `_curl_setup_request` is never preceded by `curl.reset()`. The function clears *some* carried-over state on the reused handle — `unsetopt(PROXYUSERPWD)` in the no-proxy branch (line 394), `unsetopt(USERPWD)` when no auth is set (line 495), and the HTTP-method flag reset (lines 428-432) — but other options have no equivalent clearing path and persist until a later request sets them again.

**Vector A — client TLS certificate (`SSLCERT`/`SSLKEY`).** Set-only, no clearing branch:

```python # tornado/curl_httpclient.py (v6.5.6), lines 498-502 if request.client_cert is not None: curl.setopt(pycurl.SSLCERT, request.client_cert)

if request.client_key is not None: c…

Tornado before 6.5.7 contains a credential leak vulnerability in CurlAsyncHTTPClient where pycurl handles are reused across requests without proper state clearing. Attackers can obtain sensitive credentials by issuing requests through the same client instance, allowing TLS certificates or proxy authentication to persist across unintended requests.

Tornado before 6.5.7 contains a credential leak vulnerability in CurlAsyncHTTPClient where pycurl handles are reused across requests without proper state clearing. Attackers can obtain sensitive credentials by issuing requests through the same client instance, allowing TLS certificates or proxy authentication to persist across unintended requests.

Affected: openEuler:24.03-LTS-SP1: python-tornado

Tornado is a Python web framework and asynchronous networking library, originally developed at FriendFeed. By using non-blocking network I/O, Tornado can scale to tens of thousands of open connections, making it ideal for long polling, WebSockets, and other applications that require a long-lived connection to each user. Security Fix(es):

Tornado before 6.3.3 contains an HTTP request smuggling vulnerability due to improper parsing of Content-Length headers accepting non-standard characters. Attackers can send crafted HTTP requests with these characters to bypass proxy validation and smuggle requests when deployed behind certain proxies.(CVE-2023-54397)

Tornado before 6.4.1 ignores duplicate Transfer-Encoding: chunked headers, treating requests as having no message body and parsing the chunked body as a subsequent request. Attackers can exploit this inconsistency when Tornado is deployed behind proxies to perform HTTP request smuggling, enabling access control bypass, cache poisoning, or connection desynchronization.(CVE-2024-14029)

Tornado before 6.4.1 contains a CRLF injection vulnerability in CurlAsyncHTTPClient that fails to reject carriage return and line feed characters in request headers. Attackers can inject CRLF sequences into header values to inject arbitrary headers or construct entirely new HTTP requests.(CVE-2024-58384)

Tornado before 6.5.8 contains a memory amplification vulnerability in parse_multipart_form_data that splits multipart data before validatin…

Affected: Ubuntu:Pro:16.04:LTS: python-tornado, Ubuntu:Pro:18.04:LTS: python-tornado, Ubuntu:Pro:20.04:LTS: python-tornado, Ubuntu:Pro:22.04:LTS: python-tornado, Ubuntu:24.04:LTS: python-tornado, Ubuntu:26.04:LTS: python-tornado

Tornado before 6.5.7 contains a credential leak vulnerability in CurlAsyncHTTPClient where pycurl handles are reused across requests without proper state clearing. Attackers can obtain sensitive credentials by issuing requests through the same client instance, allowing TLS certificates or proxy authentication to persist across unintended requests.