curl - Debian Package Tracker

general

source: curl (main)
version: 8.20.0-2
maintainer: Debian Curl Maintainers (DMD)
uploaders: Sergio Durigan Junior [DMD] – Samuel Henrique [DMD] – Carlos Henrique Lima Melara [DMD]
arch: all any
std-ver: 4.7.4
VCS: Git (Browse, QA)

versions [more versions can be listed by madison] [old versions available from snapshot.debian.org]

[pool directory]

o-o-stable: 7.74.0-1.3+deb11u13
o-o-sec: 7.74.0-1.3+deb11u16
o-o-p-u: 7.74.0-1.3+deb11u13
oldstable: 7.88.1-10+deb12u14
old-sec: 7.88.1-10+deb12u5
old-bpo: 8.14.1-2+deb13u2~bpo13+1
stable: 8.14.1-2+deb13u3
stable-bpo: 8.20.0-2~bpo13+1
testing: 8.20.0-2
unstable: 8.20.0-2
exp: 8.20.0-2+exp1
NEW/unstable: 8.20.0-3

versioned links

7.74.0-1.3+deb11u13: [.dsc, use dget on this link to retrieve source package] [changelog] [copyright] [rules] [control]
7.74.0-1.3+deb11u16: [.dsc, use dget on this link to retrieve source package] [changelog] [copyright] [rules] [control]
7.88.1-10+deb12u5: [.dsc, use dget on this link to retrieve source package] [changelog] [copyright] [rules] [control]
7.88.1-10+deb12u14: [.dsc, use dget on this link to retrieve source package] [changelog] [copyright] [rules] [control]
8.14.1-2+deb13u2~bpo13+1: [.dsc, use dget on this link to retrieve source package] [changelog] [copyright] [rules] [control]
8.14.1-2+deb13u3: [.dsc, use dget on this link to retrieve source package] [changelog] [copyright] [rules] [control]
8.20.0-2~bpo13+1: [.dsc, use dget on this link to retrieve source package] [changelog] [copyright] [rules] [control]
8.20.0-2: [.dsc, use dget on this link to retrieve source package] [changelog] [copyright] [rules] [control]
8.20.0-2+exp1: [.dsc, use dget on this link to retrieve source package] [changelog] [copyright] [rules] [control]

binaries

curl (32 bugs: 0, 22, 10, 0)
libcurl3t64-gnutls
libcurl4-doc
libcurl4-gnutls-dev
libcurl4-openssl-dev (4 bugs: 0, 4, 0, 0)
libcurl4t64

action needed

9 bugs tagged patch in the BTS normal

The BTS contains patches fixing 9 bugs (10 if counting merged bugs), consider including or untagging them.

Created: 2026-04-06 Last update: 2026-05-30 10:30

version in VCS is newer than in repository, is it time to upload? normal

vcswatch reports that this package seems to have a new changelog entry (version 8.20.0-3, distribution unstable) and new commits in its VCS. You should consider whether it's time to make an upload.

Here are the relevant commit messages:

commit 37bb5a615dd52a50b9c23fcf6fafbb0b10558c28
Author: Sergio Durigan Junior <sergiodj@debian.org>
Date:   Fri May 29 17:19:58 2026 -0400

    changelog for 8.20.0-3

commit 288196cca7af5b1c6b7b8586cff7a2820e8cb1e7
Author: Sergio Durigan Junior <sergiodj@debian.org>
Date:   Mon May 25 19:22:39 2026 -0400

    d/copyright: Update file.

commit d093d6e11182cfd3821ef12550977258570e3a68
Author: Sergio Durigan Junior <sergiodj@debian.org>
Date:   Sun May 24 17:59:42 2026 -0400

    d/control: Fix Breaks/Replaces version on libcurl4-gnutls.

commit d5d905f9da23ee0d062ebf1313cd7f6dd010716b
Author: Sergio Durigan Junior <sergiodj@debian.org>
Date:   Sun May 24 17:14:05 2026 -0400

    Update changelog for 8.20.0-3 release

commit 6f7eee66ab3970fad95e4f8bd8b03be7e38eb5d5
Author: Sergio Durigan Junior <sergiodj@debian.org>
Date:   Sat May 16 20:17:27 2026 -0400

    d/libcurl4-gnutls.lintian-overrides: Adjust for new package name.

commit b8327c2a3e2c8db0ef1aa98e19eb5fc54bd1cbe6
Author: Sergio Durigan Junior <sergiodj@debian.org>
Date:   Sat May 16 19:28:55 2026 -0400

    d/libcurl4-gnutls.symbols: Fix version on all libcurl4-gnutls symbols.
    
    We have to mark all symbols as having been introduced by the latest
    Debian release of the package.  This is necessary because we want
    future programs to link against this version specifically, not
    previous libcurl3t64-gnutls versions.

commit 33de9563a866c69dc8e90c57e7e0de187f335e72
Author: Sergio Durigan Junior <sergiodj@debian.org>
Date:   Tue May 5 22:05:53 2026 -0400

    d/rules: Adjust install-curl recipe to use libcurl4-gnutls.

commit f252c265dcfdc7dbdb22be3e8448f571efe24995
Author: Sergio Durigan Junior <sergiodj@debian.org>
Date:   Tue May 5 22:00:55 2026 -0400

    d/libcurl4-gnutls.symbols: Add CURL_GNUTLS_3 symbols.

commit 015f6d89e3f50c5574cf120ac2c467226fb9347d
Author: Sergio Durigan Junior <sergiodj@debian.org>
Date:   Tue May 5 21:57:32 2026 -0400

    d/libcurl3t64-gnutls*: Rename to d/libcurl4-gnutls*.

commit 2a2b1d8971675d1cd0fdf0287d94cd6ce24160fd
Author: Sergio Durigan Junior <sergiodj@debian.org>
Date:   Tue May 5 21:56:38 2026 -0400

    d/control: New package libcurl4-gnutls.
    
    Also turn libcurl3t64-gnutls into a transitional package that depends
    on libcurl4-gnutls.

commit c071fd3f7fbe4847ae2b9c0605d0e28072739457
Author: Sergio Durigan Junior <sergiodj@debian.org>
Date:   Tue May 5 21:44:40 2026 -0400

    d/p/Implement-symbol-versioning-for-CURL_GNUTLS_3.patch:
    
    Implement symbol versioning for CURL_GNUTLS_3 symbols.
    
    Closes: #1020780

commit 5af2d64faaed80ccab6b63d9353976b5b538a9f3
Author: Sergio Durigan Junior <sergiodj@debian.org>
Date:   Thu Apr 23 20:58:33 2026 -0400

    d/libgnutls3t64-gnutls.symbols: s/CURL_GNUTLS_3/CURL_GNUTLS_4/.

commit e1e7a4cdf0aa666498227fb1f545837e84102bfd
Author: Sergio Durigan Junior <sergiodj@debian.org>
Date:   Thu Apr 23 20:57:36 2026 -0400

    d/p/ZZZgnutls-build.patch: Use same SO version for both libraries.

Created: 2026-05-23 Last update: 2026-05-29 22:33

1 open merge request in Salsa normal

There is 1 open merge request for this package on Salsa. You should consider reviewing and/or merging these merge requests.

Created: 2026-05-13 Last update: 2026-05-24 22:00

lintian reports 1 warning normal

Lintian reports 1 warning about this package. You should make the package lintian clean getting rid of them.

Created: 2026-05-13 Last update: 2026-05-13 21:30

6 low-priority security issues in trixie low

There are 6 open security issues in trixie.

6 issues left for the package maintainer to handle:

CVE-2026-3783: (needs triaging) When an OAuth2 bearer token is used for an HTTP(S) transfer, and that transfer performs a redirect to a second URL, curl could leak that token to the second hostname under some circumstances. If the hostname that the first request is redirected to has information in the used .netrc file, with either of the `machine` or `default` keywords, curl would pass on the bearer token set for the first host also to the second one.
CVE-2026-3784: (needs triaging) curl would wrongly reuse an existing HTTP proxy connection doing CONNECT to a server, even if the new request uses different credentials for the HTTP proxy. The proper behavior is to create or use a separate connection.
CVE-2026-5773: (needs triaging) libcurl might in some circumstances reuse the wrong connection for SMB(S) transfers. libcurl features a pool of recent connections so that subsequent requests can reuse an existing connection to avoid overhead. When reusing a connection a range of criteria must be met. Due to a logical error in the code, a network transfer operation that was requested by an application could wrongfully reuse an existing SMB connection to the same server that was using a different 'share' than the new subsequent transfer should. This could in unlucky situations lead to the download of the wrong file or the upload of a file to the wrong place. When this happens, the same credentials are used and the server name is the same.
CVE-2026-7168: (needs triaging) 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`.
CVE-2025-14524: (needs triaging) When an OAuth2 bearer token is used for an HTTP(S) transfer, and that transfer performs a cross-protocol redirect to a second URL that uses an IMAP, LDAP, POP3 or SMTP scheme, curl might wrongly pass on the bearer token to the new target host.
CVE-2025-14819: (needs triaging) When doing TLS related transfers with reused easy or multi handles and altering the `CURLSSLOPT_NO_PARTIALCHAIN` option, libcurl could accidentally reuse a CA store cached in memory for which the partial chain option was reversed. Contrary to the user's wishes and expectations. This could make libcurl find and accept a trust chain that it otherwise would not.

You can find information about how to handle these issues in the security team's documentation.

7 issues that should be fixed with the next stable update:

CVE-2026-1965: libcurl can in some circumstances reuse the wrong connection when asked to do an Negotiate-authenticated HTTP or HTTPS request. libcurl features a pool of recent connections so that subsequent requests can reuse an existing connection to avoid overhead. When reusing a connection a range of criterion must first be met. Due to a logical error in the code, a request that was issued by an application could wrongfully reuse an existing connection to the same server that was authenticated using different credentials. One underlying reason being that Negotiate sometimes authenticates *connections* and not *requests*, contrary to how HTTP is designed to work. An application that allows Negotiate authentication to a server (that responds wanting Negotiate) with `user1:password1` and then does another operation to the same server also using Negotiate but with `user2:password2` (while the previous connection is still alive) - the second request wrongly reused the same connection and since it then sees that the Negotiate negotiation is already made, it just sends the request over that connection thinking it uses the user2 credentials when it is in fact still using the connection authenticated for user1... The set of authentication methods to use is set with `CURLOPT_HTTPAUTH`. Applications can disable libcurl's reuse of connections and thus mitigate this problem, by using one of the following libcurl options to alter how connections are or are not reused: `CURLOPT_FRESH_CONNECT`, `CURLOPT_MAXCONNECTS` and `CURLMOPT_MAX_HOST_CONNECTIONS` (if using the curl_multi API).
CVE-2026-3805: When doing a second SMB request to the same host again, curl would wrongly use a data pointer pointing into already freed memory.
CVE-2026-4873: A vulnerability exists where a connection requiring TLS incorrectly reuses an existing unencrypted connection from the same connection pool. If an initial transfer is made in clear-text (via IMAP, SMTP, or POP3), a subsequent request to that same host bypasses the TLS requirement and instead transmit data unencrypted.
CVE-2026-5545: libcurl might in some circumstances reuse the wrong connection when asked to do an authenticated HTTP(S) request after a Negotiate-authenticated one, when both use the same host. libcurl features a pool of recent connections so that subsequent requests can reuse an existing connection to avoid overhead. When reusing a connection a range of criteria must be met. Due to a logical error in the code, a request that was issued by an application could wrongfully reuse an existing connection to the same server that was authenticated using different credentials. An application that first uses Negotiate authentication to a server with `user1:password1` and then does another operation to the same server asking for any authentication method but for `user2:password2` (while the previous connection is still alive) - the second request gets confused and wrongly reuses the same connection and sends the new request over that connection thinking it uses a mix of user1's and user2's credentials when it is in fact still using the connection authenticated for user1...
CVE-2026-6253: 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
CVE-2026-6276: 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.
CVE-2026-6429: 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.

Created: 2026-01-07 Last update: 2026-05-22 05:00

6 low-priority security issues in bookworm low

There are 6 open security issues in bookworm.

6 issues left for the package maintainer to handle:

CVE-2026-1965: (needs triaging) libcurl can in some circumstances reuse the wrong connection when asked to do an Negotiate-authenticated HTTP or HTTPS request. libcurl features a pool of recent connections so that subsequent requests can reuse an existing connection to avoid overhead. When reusing a connection a range of criterion must first be met. Due to a logical error in the code, a request that was issued by an application could wrongfully reuse an existing connection to the same server that was authenticated using different credentials. One underlying reason being that Negotiate sometimes authenticates *connections* and not *requests*, contrary to how HTTP is designed to work. An application that allows Negotiate authentication to a server (that responds wanting Negotiate) with `user1:password1` and then does another operation to the same server also using Negotiate but with `user2:password2` (while the previous connection is still alive) - the second request wrongly reused the same connection and since it then sees that the Negotiate negotiation is already made, it just sends the request over that connection thinking it uses the user2 credentials when it is in fact still using the connection authenticated for user1... The set of authentication methods to use is set with `CURLOPT_HTTPAUTH`. Applications can disable libcurl's reuse of connections and thus mitigate this problem, by using one of the following libcurl options to alter how connections are or are not reused: `CURLOPT_FRESH_CONNECT`, `CURLOPT_MAXCONNECTS` and `CURLMOPT_MAX_HOST_CONNECTIONS` (if using the curl_multi API).
CVE-2026-4873: (needs triaging) A vulnerability exists where a connection requiring TLS incorrectly reuses an existing unencrypted connection from the same connection pool. If an initial transfer is made in clear-text (via IMAP, SMTP, or POP3), a subsequent request to that same host bypasses the TLS requirement and instead transmit data unencrypted.
CVE-2026-5545: (needs triaging) libcurl might in some circumstances reuse the wrong connection when asked to do an authenticated HTTP(S) request after a Negotiate-authenticated one, when both use the same host. libcurl features a pool of recent connections so that subsequent requests can reuse an existing connection to avoid overhead. When reusing a connection a range of criteria must be met. Due to a logical error in the code, a request that was issued by an application could wrongfully reuse an existing connection to the same server that was authenticated using different credentials. An application that first uses Negotiate authentication to a server with `user1:password1` and then does another operation to the same server asking for any authentication method but for `user2:password2` (while the previous connection is still alive) - the second request gets confused and wrongly reuses the same connection and sends the new request over that connection thinking it uses a mix of user1's and user2's credentials when it is in fact still using the connection authenticated for user1...
CVE-2026-6253: (needs triaging) 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
CVE-2026-6276: (needs triaging) 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.
CVE-2026-6429: (needs triaging) 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.

You can find information about how to handle these issues in the security team's documentation.

7 issues that should be fixed with the next stable update:

CVE-2026-3783: When an OAuth2 bearer token is used for an HTTP(S) transfer, and that transfer performs a redirect to a second URL, curl could leak that token to the second hostname under some circumstances. If the hostname that the first request is redirected to has information in the used .netrc file, with either of the `machine` or `default` keywords, curl would pass on the bearer token set for the first host also to the second one.
CVE-2026-3784: curl would wrongly reuse an existing HTTP proxy connection doing CONNECT to a server, even if the new request uses different credentials for the HTTP proxy. The proper behavior is to create or use a separate connection.
CVE-2026-5773: libcurl might in some circumstances reuse the wrong connection for SMB(S) transfers. libcurl features a pool of recent connections so that subsequent requests can reuse an existing connection to avoid overhead. When reusing a connection a range of criteria must be met. Due to a logical error in the code, a network transfer operation that was requested by an application could wrongfully reuse an existing SMB connection to the same server that was using a different 'share' than the new subsequent transfer should. This could in unlucky situations lead to the download of the wrong file or the upload of a file to the wrong place. When this happens, the same credentials are used and the server name is the same.
CVE-2026-7168: 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`.
CVE-2025-10148: curl's websocket code did not update the 32 bit mask pattern for each new outgoing frame as the specification says. Instead it used a fixed mask that persisted and was used throughout the entire connection. A predictable mask pattern allows for a malicious server to induce traffic between the two communicating parties that could be interpreted by an involved proxy (configured or transparent) as genuine, real, HTTP traffic with content and thereby poison its cache. That cached poisoned content could then be served to all users of that proxy.
CVE-2025-14524: When an OAuth2 bearer token is used for an HTTP(S) transfer, and that transfer performs a cross-protocol redirect to a second URL that uses an IMAP, LDAP, POP3 or SMTP scheme, curl might wrongly pass on the bearer token to the new target host.
CVE-2025-14819: When doing TLS related transfers with reused easy or multi handles and altering the `CURLSSLOPT_NO_PARTIALCHAIN` option, libcurl could accidentally reuse a CA store cached in memory for which the partial chain option was reversed. Contrary to the user's wishes and expectations. This could make libcurl find and accept a trust chain that it otherwise would not.

Created: 2025-09-10 Last update: 2026-05-22 05:00

debian/patches: 1 patch to forward upstream low

Among the 4 debian patches available in version 8.20.0-2 of the package, we noticed the following issues:

1 patch where the metadata indicates that the patch has not yet been forwarded upstream. You should either forward the patch upstream or update the metadata to document its real status.

Created: 2023-02-26 Last update: 2026-05-13 20:02

testing migrations

This package will soon be part of the auto-openssl transition. You might want to ensure that your package is ready for it. You can probably find supplementary information in the debian-release archives or in the corresponding release.debian.org bug.

news

[rss feed]

[2026-05-24] Accepted curl 8.20.0-2~bpo13+1 (source) into stable-backports (Samuel Henrique)
[2026-05-23] Accepted curl 8.20.0-2+exp1 (source) into experimental (Carlos Henrique Lima Melara)
[2026-05-22] curl 8.20.0-2 MIGRATED to testing (Debian testing watch)
[2026-05-13] Accepted curl 8.20.0-2 (source) into unstable (Carlos Henrique Lima Melara)
[2026-05-11] curl 8.20.0-1 MIGRATED to testing (Debian testing watch)
[2026-05-02] Accepted curl 8.14.1-2+deb13u3 (source) into proposed-updates (Debian FTP Masters) (signed by: Samuel Henrique)
[2026-04-30] Accepted curl 8.20.0-1+exp (source) into experimental (Samuel Henrique)
[2026-04-29] Accepted curl 8.20.0-1 (source) into unstable (Samuel Henrique)
[2026-04-23] Accepted curl 8.20.0~rc3-1 (source) into unstable (Samuel Henrique)
[2026-04-23] Accepted curl 8.20.0~rc3-1+exp1 (source) into experimental (Samuel Henrique)
[2026-04-15] Accepted curl 8.20.0~rc2-1+exp1 (source) into experimental (Carlos Henrique Lima Melara)
[2026-04-15] Accepted curl 8.20.0~rc2-1 (source) into unstable (Carlos Henrique Lima Melara)
[2026-04-08] Accepted curl 8.20.0~rc1-1+exp3 (source) into experimental (Carlos Henrique Lima Melara)
[2026-04-07] Accepted curl 8.20.0~rc1-1+exp2 (source) into experimental (Samuel Henrique)
[2026-04-04] Accepted curl 8.20.0~rc1-1+exp1 (source) into experimental (Samuel Henrique)
[2026-04-03] curl 8.19.0-3 MIGRATED to testing (Debian testing watch)
[2026-03-27] Accepted curl 8.19.0-3+exp2 (source) into experimental (Samuel Henrique)
[2026-03-27] Accepted curl 8.19.0-3+exp1 (source) into experimental (Samuel Henrique)
[2026-03-27] Accepted curl 8.19.0-3 (source) into unstable (Carlos Henrique Lima Melara)
[2026-03-27] Accepted curl 8.19.0-2 (source) into unstable (Carlos Henrique Lima Melara)
[2026-03-26] Accepted curl 8.19.0-1+exp1 (source) into experimental (Samuel Henrique)
[2026-03-18] Accepted curl 8.19.0-1~bpo13+1 (source) into stable-backports (Samuel Henrique)
[2026-03-18] curl 8.19.0-1 MIGRATED to testing (Debian testing watch)
[2026-03-12] Accepted curl 8.19.0-1 (source) into unstable (Carlos Henrique Lima Melara)
[2026-02-28] Accepted curl 8.19.0~rc3-1 (source) into unstable (Carlos Henrique Lima Melara)
[2026-02-24] Accepted curl 8.19.0~rc2-2 (source) into unstable (Carlos Henrique Lima Melara)
[2026-02-21] Accepted curl 8.19.0~rc2-1 (source) into unstable (Samuel Henrique)
[2026-02-15] Accepted curl 8.19.0~rc1-1~exp1 (source) into experimental (Samuel Henrique)
[2026-01-19] curl 8.18.0-2 MIGRATED to testing (Debian testing watch)
[2026-01-15] Accepted curl 8.18.0-2 (source) into unstable (Carlos Henrique Lima Melara)

bugs [bug history graph]

all: 49 53
RC: 0
I&N: 38 40
M&W: 10 12
F&P: 1
patch: 9 10

links

homepage
lintian (0, 1)
buildd: logs, exp, reproducibility, cross
popcon
browse source code
other distros
security tracker
screenshots
debian patches
debci

ubuntu

[Information about Ubuntu for Debian Developers]

version: 8.18.0-1ubuntu2
81 bugs (3 patches)