Curl

Successfully using libcurl to do a transfer over a specific HTTP proxy (`proxyA`) with **Digest** authentication and then changing the proxy host to a second one (`proxyB`) for a second transfer, reusing the same handle, makes libcurl wrongly pass on the `Proxy-Authorization:` header field meant for `proxyA`, to `proxyB`.

Published: 2026-05-13T08:29:08.900Z
Updated: 2026-09-15T06:03:07.424Z

When curl is told to use the Certificate Status Request TLS extension, often referred to as *OCSP stapling*, to verify that the server certificate is valid, it fails to detect OCSP problems and instead wrongly consider the response as fine.

Published: 2026-05-13T08:28:53.697Z
Updated: 2026-05-13T14:20:33.908Z

When asked to both use a `.netrc` file for credentials and to follow HTTP redirects, libcurl could leak the password used for the first host to the followed-to host under certain circumstances.

Published: 2026-05-13T08:28:36.166Z
Updated: 2026-09-15T06:03:05.855Z

Using libcurl, when a custom `Host:` header is first set for an HTTP request and a second request is subsequently done using the same *easy handle* but without the custom `Host:` header set, the second request would use stale information and pass on cookies meant for the first host in the second request. Leak them.

Published: 2026-05-13T08:28:19.273Z
Updated: 2026-09-15T06:03:04.059Z

curl might erroneously pass on credentials for a first proxy to a second proxy. This can happen when the following conditions are true: 1. curl is setup to use specific different proxies for different URL schemes 2. the first proxy needs credentials 3. the second proxy uses no credentials 4. while using the first proxy (using say `http://`), curl is asked to follow a redirect to a URL using another scheme (say `https://`), accessed using a second, different, proxy

Published: 2026-05-13T08:28:03.004Z
Updated: 2026-09-15T06:03:02.453Z