curl - Debian Package Tracker

general

source: curl (main)
version: 8.21.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+deb12u15
old-sec: 7.88.1-10+deb12u5
old-bpo: 8.14.1-2+deb13u2~bpo13+1
old-p-u: 7.88.1-10+deb12u15
stable: 8.14.1-2+deb13u4
stable-bpo: 8.20.0-5~bpo13+1
testing: 8.20.0-5
unstable: 8.21.0-2
exp: 8.21.0-2+exp1

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+deb12u15: [.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+deb13u4: [.dsc, use dget on this link to retrieve source package] [changelog] [copyright] [rules] [control]
8.20.0-5~bpo13+1: [.dsc, use dget on this link to retrieve source package] [changelog] [copyright] [rules] [control]
8.20.0-5: [.dsc, use dget on this link to retrieve source package] [changelog] [copyright] [rules] [control]
8.21.0-1+exp1: [.dsc, use dget on this link to retrieve source package] [changelog] [copyright] [rules] [control]
8.21.0-2: [.dsc, use dget on this link to retrieve source package] [changelog] [copyright] [rules] [control]
8.21.0-2+exp1: [.dsc, use dget on this link to retrieve source package] [changelog] [copyright] [rules] [control]

binaries

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

action needed

Debci reports failed tests high

unstable: fail (log)
The tests ran in 0:19:45
Last run: 2026-07-09T20:06:45.000Z
Previous status: unknown

testing: pass (log)
The tests ran in 0:11:56
Last run: 2026-06-01T09:07:42.000Z
Previous status: unknown

stable: fail (log)
The tests ran in 0:08:46
Last run: 2026-07-11T16:25:24.000Z
Previous status: unknown

Created: 2026-07-09 Last update: 2026-07-12 17:32

18 security issues in forky high

There are 18 open security issues in forky.

18 important issues:

CVE-2026-8286: A vulnerability exists where a new transfer that uses STARTTLS to upgrade the connection might reuse an existing live connection even though the TLS configuration mismatches so it should not.
CVE-2026-8458: libcurl might in some circumstances reuse the wrong connection when asked to do Negotiate-authenticated ones, even when they are set to use different 'services'. 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 services.
CVE-2026-8924: A flaw in curl’s cookie parsing logic allows a malicious HTTP server to set 'super cookies' that bypass the Public Suffix List check. This enables an attacker-controlled origin to inject cookies that curl subsequently scopes and transmits to unrelated third-party domains.
CVE-2026-8925: The curl logic that works with SASL authentication could end up cleaning up the GSASL context *twice* without clearing the pointer in between, making it `free()` the same pointer twice.
CVE-2026-8926: When asking curl to use a `.netrc` file to find credentials and at the same time specifying a URL with a username(without a password), like `https://user@example.com/`, curl could wrongly get and use the password for *another* user set in the `.netrc` file for that host if such a one exists and there is no match for the specified user.
CVE-2026-8927: When reusing a libcurl handle for sequential transfers driven by environment-variable proxy configuration, libcurl fails to clear the proxy authentication state between requests. Specifically, if the initial transfer authenticates against `proxyA` using Digest auth, a subsequent transfer routed through `proxyB` erroneously leaks the `Proxy-Authorization:` header intended solely for `proxyA`.
CVE-2026-8932: libcurl would reuse a previously created connection even when some mTLS config related option had been changed that should have prohibited reuse. libcurl keeps previously used connections in a connection pool for subsequent transfers to reuse if one of them matches the setup. However, some TLS settings related to client certificates were left out from the configuration match checks, making them match too easily. In particular options related to the private key.
CVE-2026-9079: libcurl had a flaw that when instructed to clear proxy authentication credentials which made it not do so, leaving the old credentials around to get used for subsequent transfers that should not know nor use them.
CVE-2026-9080: Calling `curl_easy_pause()` within the event-based `CURLMOPT_SOCKETFUNCTION` callback triggers a use-after-free vulnerability, where libcurl attempts to store a flag using a dangling struct pointer immediately after that pointer's memory has been freed.
CVE-2026-9545: In this scenario, libcurl first uses a proper HTTP/3 server for the initial transfers, and when it makes a second transfer to the same site it has been replaced by the attacker's impostor machine - without a valid certificate. When libcurl returns to the hostname the second time with a cached SSL session (`CURLOPT_SSL_SESSIONID_CACHE` is not disabled) and early data enabled (the `CURLSSLOPT_EARLYDATA` bit is set in `CURLOPT_SSL_OPTIONS`), libcurl might send off the second request's bytes on that new connection *before* enforcing the certificate verification failure. Potentially leaking sensitive information.
CVE-2026-9546: A vulnerability in libcurl caused the HTTP `Referer:` header to persist even when explicitly cleared. While the documentation states that passing NULL to `CURLOPT_REFERER` suppresses the header, the option failed to clear the internal state. As a result the previous referrer string was erroneously reused and sent in subsequent requests, potentially leaking sensitive information to unintended servers.
CVE-2026-9547: When a libcurl-based application performs transfers via `SCP://` or `SFTP://` and utilizes the `CURLOPT_SSH_KEYFUNCTION` callback, it may silently accept an untrusted server. This vulnerability occurs when a server presents a host key type that does not match the specific key type already recorded for that host in the `known_hosts` file. Instead of rejecting the mismatch, the callback mechanism fails to properly enforce the restriction, allowing the connection to succeed without warning and risking a potential man-in-the-middle attack.
CVE-2026-10536: A use-after-free vulnerability exists in libcurl when an application configures an HTTP/2 stream-dependency tree via `CURLOPT_STREAM_DEPENDS` or `CURLOPT_STREAM_DEPENDS_E`, subsequently invokes `curl_easy_reset()`, and finally terminates the handle with `curl_easy_cleanup()`. During this final cleanup phase, libcurl attempts to access and modify an internal structure that was already freed during the reset operation.
CVE-2026-11352: An issue in curl’s QUIC UDP receive function allows a malicious HTTP/3 server to trigger a remote denial of service against a curl or libcurl client. Because the helper function discards zero-length UDP datagrams before counting them toward the per-call packet budget, a connected QUIC peer can continuously stream empty datagrams to indefinitely stall the client.
CVE-2026-11564: libcurl keeps previously used connections in a connection pool for subsequent transfers to reuse if one of them matches the setup. An easy handle that first uses default native CA trust can continue trusting the native platform store after the application switches that same handle to custom CA material for a later transfer.
CVE-2026-11586: By default, curl automatically responds to WebSocket PING frames. Because curl lacks an upper bound on memory allocation for unacknowledged frames, a malicious server can exhaust all available memory by flooding curl with rapid, sequential PING messages.
CVE-2026-11856: Successfully using libcurl to do a transfer to a specific HTTP origin (`hostA`) with **Digest** authentication and then changing the origin to a different one (`hostB`) for a second transfer, reusing the same handle, makes libcurl wrongly pass on the `Authorization:` header field meant for `hostA`, to `hostB`.
CVE-2026-12064: When a user invokes curl using a schemeless URL combined with `--proto-default` sftp (or scp), a disconnect occurs between the tool layer and libcurl. The tool layer incorrectly infers the URL scheme, which erroneously bypasses the initialization of critical SSH security options like CURLOPT_SSH_HOST_PUBLIC_KEY_SHA256 and CURLOPT_SSH_KNOWNHOSTS. Conversely, the libcurl runtime successfully honors CURLOPT_DEFAULT_PROTOCOL and establishes the connection via SFTP/SCP as specified. Because the tool layer skipped the security configuration, these SSH host verification options are silently omitted, causing curl to connect to an unverified SSH remote host without throwing an error.

Created: 2026-06-24 Last update: 2026-07-12 04:49

The VCS repository is not up to date, push the missing commits. high

vcswatch reports that the current version of the package is not in its VCS.
Either you need to push your commits and/or your tags, or the information about the package's VCS are out of date. A common cause of the latter issue when using the Git VCS is not specifying the correct branch when the packaging is not in the default one (remote HEAD branch), which is usually "master" but can be modified in salsa.debian.org in the project's general settings with the "Default Branch" field). Alternatively the Vcs-Git field in debian/control can contain a "-b <branch-name>" suffix to indicate what branch is used for the Debian packaging.

Created: 2026-06-04 Last update: 2026-07-10 03:20

debian/patches: 1 patch with invalid metadata, 2 patches to forward upstream high

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

1 patch with invalid metadata that ought to be fixed.
2 patches 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-06-29 10:49

The package has not entered testing even though the delay is over normal

The package has not entered testing even though the 5-day delay is over. Check why.

Created: 2026-07-04 Last update: 2026-07-12 18:19

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-06-02 Last update: 2026-07-12 17:30

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-06-30 Last update: 2026-06-30 04:48

13 low-priority security issues in trixie low

There are 13 open security issues in trixie.

13 issues left for the package maintainer to handle:

CVE-2026-8286: (needs triaging) A vulnerability exists where a new transfer that uses STARTTLS to upgrade the connection might reuse an existing live connection even though the TLS configuration mismatches so it should not.
CVE-2026-8458: (needs triaging) libcurl might in some circumstances reuse the wrong connection when asked to do Negotiate-authenticated ones, even when they are set to use different 'services'. 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 services.
CVE-2026-8924: (needs triaging) A flaw in curl’s cookie parsing logic allows a malicious HTTP server to set 'super cookies' that bypass the Public Suffix List check. This enables an attacker-controlled origin to inject cookies that curl subsequently scopes and transmits to unrelated third-party domains.
CVE-2026-8926: (needs triaging) When asking curl to use a `.netrc` file to find credentials and at the same time specifying a URL with a username(without a password), like `https://user@example.com/`, curl could wrongly get and use the password for *another* user set in the `.netrc` file for that host if such a one exists and there is no match for the specified user.
CVE-2026-8927: (needs triaging) When reusing a libcurl handle for sequential transfers driven by environment-variable proxy configuration, libcurl fails to clear the proxy authentication state between requests. Specifically, if the initial transfer authenticates against `proxyA` using Digest auth, a subsequent transfer routed through `proxyB` erroneously leaks the `Proxy-Authorization:` header intended solely for `proxyA`.
CVE-2026-8932: (needs triaging) libcurl would reuse a previously created connection even when some mTLS config related option had been changed that should have prohibited reuse. libcurl keeps previously used connections in a connection pool for subsequent transfers to reuse if one of them matches the setup. However, some TLS settings related to client certificates were left out from the configuration match checks, making them match too easily. In particular options related to the private key.
CVE-2026-9079: (needs triaging) libcurl had a flaw that when instructed to clear proxy authentication credentials which made it not do so, leaving the old credentials around to get used for subsequent transfers that should not know nor use them.
CVE-2026-9080: (needs triaging) Calling `curl_easy_pause()` within the event-based `CURLMOPT_SOCKETFUNCTION` callback triggers a use-after-free vulnerability, where libcurl attempts to store a flag using a dangling struct pointer immediately after that pointer's memory has been freed.
CVE-2026-9545: (needs triaging) In this scenario, libcurl first uses a proper HTTP/3 server for the initial transfers, and when it makes a second transfer to the same site it has been replaced by the attacker's impostor machine - without a valid certificate. When libcurl returns to the hostname the second time with a cached SSL session (`CURLOPT_SSL_SESSIONID_CACHE` is not disabled) and early data enabled (the `CURLSSLOPT_EARLYDATA` bit is set in `CURLOPT_SSL_OPTIONS`), libcurl might send off the second request's bytes on that new connection *before* enforcing the certificate verification failure. Potentially leaking sensitive information.
CVE-2026-9547: (needs triaging) When a libcurl-based application performs transfers via `SCP://` or `SFTP://` and utilizes the `CURLOPT_SSH_KEYFUNCTION` callback, it may silently accept an untrusted server. This vulnerability occurs when a server presents a host key type that does not match the specific key type already recorded for that host in the `known_hosts` file. Instead of rejecting the mismatch, the callback mechanism fails to properly enforce the restriction, allowing the connection to succeed without warning and risking a potential man-in-the-middle attack.
CVE-2026-10536: (needs triaging) A use-after-free vulnerability exists in libcurl when an application configures an HTTP/2 stream-dependency tree via `CURLOPT_STREAM_DEPENDS` or `CURLOPT_STREAM_DEPENDS_E`, subsequently invokes `curl_easy_reset()`, and finally terminates the handle with `curl_easy_cleanup()`. During this final cleanup phase, libcurl attempts to access and modify an internal structure that was already freed during the reset operation.
CVE-2026-11856: (needs triaging) Successfully using libcurl to do a transfer to a specific HTTP origin (`hostA`) with **Digest** authentication and then changing the origin to a different one (`hostB`) for a second transfer, reusing the same handle, makes libcurl wrongly pass on the `Authorization:` header field meant for `hostA`, to `hostB`.
CVE-2026-12064: (needs triaging) When a user invokes curl using a schemeless URL combined with `--proto-default` sftp (or scp), a disconnect occurs between the tool layer and libcurl. The tool layer incorrectly infers the URL scheme, which erroneously bypasses the initialization of critical SSH security options like CURLOPT_SSH_HOST_PUBLIC_KEY_SHA256 and CURLOPT_SSH_KNOWNHOSTS. Conversely, the libcurl runtime successfully honors CURLOPT_DEFAULT_PROTOCOL and establishes the connection via SFTP/SCP as specified. Because the tool layer skipped the security configuration, these SSH host verification options are silently omitted, causing curl to connect to an unverified SSH remote host without throwing an error.

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

Created: 2026-01-07 Last update: 2026-07-12 04:49

14 low-priority security issues in bookworm low

There are 14 open security issues in bookworm.

14 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.
CVE-2026-8286: (postponed; to be fixed through a stable update) A vulnerability exists where a new transfer that uses STARTTLS to upgrade the connection might reuse an existing live connection even though the TLS configuration mismatches so it should not.
CVE-2026-8458: (postponed; to be fixed through a stable update) libcurl might in some circumstances reuse the wrong connection when asked to do Negotiate-authenticated ones, even when they are set to use different 'services'. 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 services.
CVE-2026-8924: (postponed; to be fixed through a stable update) A flaw in curl’s cookie parsing logic allows a malicious HTTP server to set 'super cookies' that bypass the Public Suffix List check. This enables an attacker-controlled origin to inject cookies that curl subsequently scopes and transmits to unrelated third-party domains.
CVE-2026-8927: (postponed; to be fixed through a stable update) When reusing a libcurl handle for sequential transfers driven by environment-variable proxy configuration, libcurl fails to clear the proxy authentication state between requests. Specifically, if the initial transfer authenticates against `proxyA` using Digest auth, a subsequent transfer routed through `proxyB` erroneously leaks the `Proxy-Authorization:` header intended solely for `proxyA`.
CVE-2026-8932: (postponed; to be fixed through a stable update) libcurl would reuse a previously created connection even when some mTLS config related option had been changed that should have prohibited reuse. libcurl keeps previously used connections in a connection pool for subsequent transfers to reuse if one of them matches the setup. However, some TLS settings related to client certificates were left out from the configuration match checks, making them match too easily. In particular options related to the private key.
CVE-2026-10536: (postponed; to be fixed through a stable update) A use-after-free vulnerability exists in libcurl when an application configures an HTTP/2 stream-dependency tree via `CURLOPT_STREAM_DEPENDS` or `CURLOPT_STREAM_DEPENDS_E`, subsequently invokes `curl_easy_reset()`, and finally terminates the handle with `curl_easy_cleanup()`. During this final cleanup phase, libcurl attempts to access and modify an internal structure that was already freed during the reset operation.
CVE-2026-11856: (postponed; to be fixed through a stable update) Successfully using libcurl to do a transfer to a specific HTTP origin (`hostA`) with **Digest** authentication and then changing the origin to a different one (`hostB`) for a second transfer, reusing the same handle, makes libcurl wrongly pass on the `Authorization:` header field meant for `hostA`, to `hostB`.
CVE-2026-12064: (postponed; to be fixed through a stable update) When a user invokes curl using a schemeless URL combined with `--proto-default` sftp (or scp), a disconnect occurs between the tool layer and libcurl. The tool layer incorrectly infers the URL scheme, which erroneously bypasses the initialization of critical SSH security options like CURLOPT_SSH_HOST_PUBLIC_KEY_SHA256 and CURLOPT_SSH_KNOWNHOSTS. Conversely, the libcurl runtime successfully honors CURLOPT_DEFAULT_PROTOCOL and establishes the connection via SFTP/SCP as specified. Because the tool layer skipped the security configuration, these SSH host verification options are silently omitted, causing curl to connect to an unverified SSH remote host without throwing an error.

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

Created: 2025-09-10 Last update: 2026-07-12 04:49

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.
excuses:
- Migration status for curl (8.20.0-5 to 8.21.0-2): BLOCKED: Rejected/violates migration policy/introduces a regression
- Issues preventing migration:
- ∙ ∙ Updating curl would introduce bugs in testing: #1141371
- ∙ ∙ Autopkgtest for cimg/3.5.2+dfsg-2: amd64: Pass, arm64: Pass, armhf: Pass, i386: Pass, loong64: Pass, ppc64el: Pass, riscv64: Test triggered (failure will be ignored), s390x: Pass
- ∙ ∙ Autopkgtest for cmake/4.3.4-1: amd64: Pass, arm64: Pass, armhf: Pass, i386: Pass, loong64: Pass, ppc64el: Pass, riscv64: Test triggered (failure will be ignored), s390x: Pass
- ∙ ∙ Autopkgtest for curl/8.21.0-2: amd64: Pass, arm64: Pass, armhf: Regression ♻ (reference ♻), i386: Pass, loong64: Pass, ppc64el: Regression ♻ (reference ♻), riscv64: Pass, s390x: Pass
- ∙ ∙ Autopkgtest for debusine/0.14.10: amd64: Pass, arm64: Pass, armhf: Failed (not a regression) ♻ (reference ♻), i386: Pass, loong64: Pass, ppc64el: Pass, riscv64: Test triggered (failure will be ignored), s390x: Pass
- ∙ ∙ Autopkgtest for dracut/111-4: amd64: Pass, arm64: Pass, armhf: No tests, superficial or marked flaky ♻ (reference ♻), i386: No tests, superficial or marked flaky ♻, loong64: Failed (not a regression) ♻ (reference ♻), ppc64el: Pass, riscv64: Test triggered (failure will be ignored), s390x: Pass
- ∙ ∙ Autopkgtest for janus/1.1.2-4: i386: Pass ♻ (reference ♻), s390x: Pass ♻ (reference ♻)
- ∙ ∙ Autopkgtest for lastpass-cli/1.6.1-4: i386: Pass ♻, s390x: Pass ♻
- ∙ ∙ Autopkgtest for libmicrohttpd/1.0.5-1: i386: Pass ♻, s390x: Pass ♻
- ∙ ∙ Autopkgtest for libreoffice/4:26.2.4.2-1: arm64: Test triggered (failure will be ignored), armhf: Test triggered (failure will be ignored), i386: Test triggered (failure will be ignored), loong64: Failed (not a regression) ♻ (reference ♻)
- ∙ ∙ Autopkgtest for nodejs/24.18.0+dfsg+~cs24.13.2-1: amd64: Pass, arm64: Pass, armhf: Pass, i386: Pass, loong64: Pass, ppc64el: Pass, riscv64: Test triggered (failure will be ignored), s390x: Pass
- ∙ ∙ Autopkgtest for ocaml-dune/3.23.1-5: amd64: Pass, arm64: Pass, armhf: Pass, i386: Pass, loong64: Test triggered (failure will be ignored), ppc64el: Pass, riscv64: Pass, s390x: Pass
- ∙ ∙ Autopkgtest for ostree/2026.1-1: i386: Pass ♻, s390x: Pass ♻ (reference ♻)
- ∙ ∙ Autopkgtest for privoxy/4.2.0-1: amd64: Failed (not a regression) ♻ (reference ♻), arm64: Failed (not a regression) ♻ (reference ♻), armhf: Pass, i386: Failed (not a regression) ♻ (reference ♻), loong64: Pass, ppc64el: Pass, riscv64: Regression ♻ (reference ♻), s390x: Pass
- ∙ ∙ Autopkgtest for trurl/0.16.1-4: amd64: Regression ♻ (reference ♻), arm64: Regression ♻ (reference ♻), armhf: Regression ♻ (reference ♻), i386: Regression ♻ (reference ♻), loong64: Regression ♻ (reference ♻), ppc64el: Regression ♻ (reference ♻), riscv64: Regression ♻ (reference ♻), s390x: Regression ♻ (reference ♻)
- Additional info (not blocking):
- ∙ ∙ Piuparts tested OK - https://piuparts.debian.org/sid/source/c/curl.html
- ∙ ∙ Reproduced on amd64 - info
- ∙ ∙ Reproduced on arm64 - info
- ∙ ∙ Reproduced on armhf - info
- ∙ ∙ Reproduced on i386 - info
- ∙ ∙ 13 days old (needed 5 days)
- Not considered

news

[rss feed]

[2026-06-30] Accepted curl 8.14.1-2+deb13u4 (source) into proposed-updates (Debian FTP Masters) (signed by: Samuel Henrique)
[2026-06-30] Accepted curl 7.88.1-10+deb12u15 (source) into oldstable-proposed-updates (Debian FTP Masters) (signed by: Samuel Henrique)
[2026-06-28] Accepted curl 8.21.0-2+exp1 (source) into experimental (Carlos Henrique Lima Melara)
[2026-06-28] Accepted curl 8.21.0-2 (source) into unstable (Carlos Henrique Lima Melara)
[2026-06-26] Accepted curl 8.21.0-1+exp1 (source) into experimental (Carlos Henrique Lima Melara)
[2026-06-25] Accepted curl 8.21.0-1 (source) into unstable (Carlos Henrique Lima Melara)
[2026-06-19] Accepted curl 8.21.0~rc3-1+exp1 (source) into experimental (Carlos Henrique Lima Melara)
[2026-06-19] Accepted curl 8.21.0~rc3-1 (source) into unstable (Carlos Henrique Lima Melara)
[2026-06-14] Accepted curl 8.21.0~rc2-1+exp1 (source) into experimental (Samuel Henrique)
[2026-06-13] Accepted curl 8.21.0~rc2-1 (source) into unstable (Samuel Henrique)
[2026-06-08] Accepted curl 8.20.0-5~bpo13+1 (source amd64 all) into stable-backports (Debian FTP Masters) (signed by: Samuel Henrique)
[2026-06-06] curl 8.20.0-5 MIGRATED to testing (Debian testing watch)
[2026-06-04] Accepted curl 8.21.0~rc1-1+exp1 (source) into experimental (Samuel Henrique)
[2026-06-01] Accepted curl 8.20.0-5 (source) into unstable (Sergio Durigan Junior)
[2026-06-01] Accepted curl 8.20.0-4 (source) into unstable (Sergio Durigan Junior)
[2026-05-31] Accepted curl 8.20.0-3 (source amd64 all) into unstable (Debian FTP Masters) (signed by: Sergio Durigan Junior)
[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)

bugs [bug history graph]

all: 50 54
RC: 1
I&N: 37 39
M&W: 11 13
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.20.0-2ubuntu1
patches for 8.20.0-2ubuntu1