Ce mail provient de l'extérieur, restons vigilants

=====================================================================

                            CERT-Renater

                Note d'Information No. 2026/VULN439
_____________________________________________________________________

DATE                : 29/04/2026

HARDWARE PLATFORM(S): /

OPERATING SYSTEM(S): Systems running curl, libcurl versions
                              prior to 8.20.0.

=====================================================================
https://curl.se/docs/CVE-2026-7168.html
https://curl.se/docs/CVE-2026-7009.html
https://curl.se/docs/CVE-2026-6429.html
https://curl.se/docs/CVE-2026-6253.html
https://curl.se/docs/CVE-2026-5545.html
https://curl.se/docs/CVE-2026-5773.html
https://curl.se/docs/CVE-2026-4873.html
_____________________________________________________________________

CVE-2026-7168
cross-proxy Digest auth state leak

Project curl Security Advisory, April 29 2026 Permalink


VULNERABILITY

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.


INFO

An evil proxyB could use this incoming request header field to
impersonate the client in communicating with proxyA, as the header
contains the authenticated state.

There is nothing in the request details passed to proxyB that reveal
the name or the address of proxyA, which mitigates this problem.

This bug is not considered a C mistake (likely to have been avoided
had we not been using C).

This flaw does not affect the curl command line tool.

The Common Vulnerabilities and Exposures (CVE) project has assigned
the name CVE-2026-7168 to this issue.

CWE-294: Authentication Bypass by Capture-replay

Severity: Medium


AFFECTED VERSIONS

    Affected versions: curl 7.12.0 to and including 8.19.0
    Not affected versions: curl < 7.12.0 and >= 8.20.0
    Introduced-in: https://github.com/curl/curl/commit/fc6eff13b5414caf6edf

libcurl is used by many applications, but not always advertised as such!


SOLUTION

    Fixed-in: https://github.com/curl/curl/commit/c1cfdf59acbaf9504c45


RECOMMENDATIONS

We suggest you take one of the following actions immediately, in
order of preference:

A - Upgrade curl and libcurl to version 8.20.0

B - Apply the patch to your version and rebuild

C - Avoid reusing handles when changing proxies
TIMELINE

This issue was reported to the curl project on April 27, 2026.

curl 8.20.0 was released on April 29 2026, coordinated with the
publication of this advisory.


CREDITS

    Reported-by: Muhamad Arga Reksapati
    Patched-by: Daniel Stenberg

Thanks a lot!

_____________________________________________________________________

CVE-2026-7009
OCSP stapling bypass with Apple SecTrust

Project curl Security Advisory, April 29 2026 Permalink


VULNERABILITY

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.


INFO

This vulnerability only occurs when the curl meets two specific
conditions:

    Backend: It is built using an OpenSSL-based backend (including
forks like BoringSSL, AWS-LC, LibreSSL, or QuicTLS).

    Trust Store: It is used with Apple SecTrust, the feature that
allows curl to access the native CA certificate store on Apple
operating systems (macOS, iOS, iPadOS, tvOS, and watchOS).

In short, the flaw requires an OpenSSL-linked curl running on an
Apple platform using the system's native certificate store.

OCSP stapling is not a widely used feature on the open web,
perhaps partly because so many big name sites do not support
it.

This bug is not considered a C mistake (likely to have been
avoided had we not been using C).

This flaw also affects the curl command line tool.

The Common Vulnerabilities and Exposures (CVE) project has
assigned the name CVE-2026-7009 to this issue.

CWE-295: Improper Certificate Validation

Severity: Medium


AFFECTED VERSIONS

    Affected versions: curl 8.17.0 to and including 8.19.0
    Not affected versions: curl < 8.17.0 and >= 8.20.0
    Introduced-in: https://github.com/curl/curl/commit/eefd03c572996e5d

libcurl is used by many applications, but not always
advertised as such!


SOLUTION

    Fixed-in: https://github.com/curl/curl/commit/51905671e07f087e28e57


RECOMMENDATIONS

We suggest you take one of the following actions immediately,
in order of preference:

A - Upgrade curl and libcurl to version 8.20.0

B - Apply the patch to your version and rebuild

C - Avoid the combination OCSP stapling + Apple SecTrust


TIMELINE

This issue was reported to the curl project on April 25, 2026.

curl 8.20.0 was released on April 29 2026, coordinated with the
publication of this advisory.


CREDITS

    Reported-by: Carlos Carrillo
    Patched-by: Stefan Eissing

Thanks a lot!
_____________________________________________________________________

CVE-2026-6429
netrc credential leak with reused proxy connection

Project curl Security Advisory, April 29 2026 Permalink


VULNERABILITY

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.


INFO

To trigger, this flaw requires that both the original URL and the
redirect URL are using clear text http:// URLs, that both are
performed over the same HTTP proxy and that the same connection
is reused.

Similar to CVE-2024-11053

The Common Vulnerabilities and Exposures (CVE) project has assigned
the name CVE-2026-6429 to this issue.

CWE-200: Exposure of Sensitive Information to an Unauthorized Actor

Severity: Medium


AFFECTED VERSIONS

    Affected versions: from curl 7.14.0 to and including 8.19.0
    Not affected versions: curl < 7.14.0 and >= 8.20.0
    Introduced-in: https://github.com/curl/curl/commit/01165e08e0d131b399fb

libcurl is used by many applications, but not always advertised
as such!

This bug is not considered a C mistake. It is not likely to have
been avoided had we not been using C.

This flaw does not affect the curl command line tool.


SOLUTION

    Fixed-in: https://github.com/curl/curl/commit/b4024bf808bd558026fdc6

RECOMMENDATIONS

We suggest you take one of the following actions immediately, in
order of preference:

A - Upgrade to curl and libcurl 8.20.0

B - Apply the patch and rebuild libcurl

C - Avoid using the combination netrc, HTTP and HTTP proxy


TIMELINE

It was reported to the curl project on April 16th 2026. We contacted
distros@openwall on April 23.

libcurl 8.20.0 was released on April 29th 2026, coordinated with the
publication of this advisory.


CREDITS

    Reported-by: Muhamad Arga Reksapati
    Patched-by: Daniel Stenberg

Thanks a lot!
_____________________________________________________________________

CVE-2026-6253
proxy credentials leak over redirect-to proxy

Project curl Security Advisory, April 29 2026 Permalink


VULNERABILITY

curl might erroneously pass on credentials for a first proxy to a
second proxy.

This can happen when the following conditions are true:

    curl is setup to use specific different proxies for different
URL schemes
    the first proxy needs credentials
    the second proxy uses no credentials
    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


INFO

The credentials are passed on base64 encoded. The receiving proxy
gets no hint as for where or how the credentials are valid.

The Common Vulnerabilities and Exposures (CVE) project has
assigned the name CVE-2026-6253 to this issue.

CWE-522: Insufficiently Protected Credentials

Severity: Medium


AFFECTED VERSIONS

This flaw has existed since curl added support for credentials
in proxy strings.

    Affected versions: from curl 7.14.1 to and including 8.19.0
    Not affected versions: curl < 7.14.1 and >= 8.20.0
    Introduced-in: https://github.com/curl/curl/commit/3b60bb725913ce

libcurl is used by many applications, but not always advertised
as such!

This bug is not considered a C mistake. It is not likely to have
been avoided had we not been using C.

This flaw also affects the curl command line tool.


SOLUTION

    Fixed-in: https://github.com/curl/curl/commit/188c2f166a20fa97c2325

RECOMMENDATIONS

We suggest you take one of the following actions immediately,
in order of preference:

A - Upgrade to curl and libcurl 8.20.0

B - Apply the patch and rebuild libcurl

C - Avoid using proxies with credentials


TIMELINE

It was reported to the curl project on April 13th 2026. We
contacted distros@openwall on April 23.

libcurl 8.20.0 was released on April 29th 2026, coordinated
with the publication of this advisory.


CREDITS

    Reported-by: Dwij Mehta
    Patched-by: Daniel Stenberg

Thanks a lot!
_____________________________________________________________________

CVE-2026-5545
wrong reuse of HTTP Negotiate connection

Project curl Security Advisory, April 29 2026 Permalink


VULNERABILITY

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...


INFO

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).

The Common Vulnerabilities and Exposures (CVE) project has
assigned the name CVE-2026-5545 to this issue.

This flaw is similar to CVE-2026-1965.

CWE-305: Authentication Bypass by Primary Weakness

Severity: Medium


AFFECTED VERSIONS

This flaw has existed since curl started to support Negotiate.

    Affected versions: from curl 7.10.6 to and including 8.19.0
    Not affected versions: curl < 7.10.6 and >= 8.20.0
    Introduced-in: https://github.com/curl/curl/commit/e56ae1426c

libcurl is used by many applications, but not always
advertised as such!

This bug is not considered a C mistake. It is not likely to
have been avoided had we not been using C.

This flaw also affects the curl command line tool.


SOLUTION

curl 8.20.0 makes sure that connections using Negotiate are
not wrongly reused.

    Fixed-in: https://github.com/curl/curl/commit/33e43985b8f3b9e6669


RECOMMENDATIONS

We suggest you take one of the following actions immediately,
in order of preference:

A - Upgrade to curl and libcurl 8.20.0

B - Apply the patch and rebuild libcurl

C - Avoid using HTTP Negotiate in your application


TIMELINE

It was reported to the curl project on April 1st 2026. We contacted
distros@openwall on April 23.

libcurl 8.20.0 was released on April 29th 2026, coordinated with the
publication of this advisory.


CREDITS

    Reported-by: Quac Tran and Ngoc Hieu
    Patched-by: Stefan Eissing

Thanks a lot!

_____________________________________________________________________

CVE-2026-5773
wrong reuse of SMB connection

Project curl Security Advisory, April 29 2026 Permalink


VULNERABILITY

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.


INFO

curl only supports SMB version 1 and no later version. SMB version
1 is considered insecure and deprecated and is therefore commonly
disabled in servers. curl is scheduled to drop support for SMB
later in 2026. SMB support is opt-in since 8.20.0.

In this flaw, the code simply erroneously did not consider the
share name as a property to match for connection reuse.

The Common Vulnerabilities and Exposures (CVE) project has
assigned the name CVE-2026-5773 to this issue.

CWE-488: Exposure of Data Element to Wrong Session

Severity: Low


AFFECTED VERSIONS

This flaw has existed since curl started to support SMB.

    Affected versions: from curl 7.40.0 to and including 8.19.0
    Not affected versions: curl < 7.40.0 and >= 8.20.0
    Introduced-in: https://github.com/curl/curl/commit/aec2e865f0

libcurl is used by many applications, but not always advertised
as such!

This bug is not considered a C mistake. It is not likely to have
been avoided had we not been using C.

This flaw also affects the curl command line tool.


SOLUTION

curl 8.20.0 makes sure that connections using SMB never get reused.

    Fixed-in: https://github.com/curl/curl/commit/74a169575d6412d

RECOMMENDATIONS

We suggest you take one of the following actions immediately, in order
of preference:

A - Upgrade to curl and libcurl 8.20.0

B - Apply the patch and rebuild libcurl

C - Avoid using SMB


TIMELINE

It was reported to the curl project on April 5th 2026. We contacted
distros@openwall on April 23.

libcurl 8.20.0 was released on April 29th 2026, coordinated with the
publication of this advisory.


CREDITS

    Reported-by: Osama Hamad
    Patched-by: Daniel Stenberg

Thanks a lot!
_____________________________________________________________________

CVE-2026-4873
connection reuse ignores TLS requirement

Project curl Security Advisory, April 29 2026 Permalink


VULNERABILITY

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.


INFO

This flaw requires a rather special series of events to trigger.
Such a series is unlikely to be used much in the wild.

This issue only happens for transfers done using IMAP://,
POP3:// or SMTP:// URL schemes. The initial transfer and the
second transfer both need to be done to the same host, use the
same credentials and the same URL schemes. The login and the
initial transfer is done over clear-text, so the user is
obviously already accepting an insecure transmission for this.
This flaw still makes it worse as the second transfer is
intended to be secured by TLS but is not.

The Common Vulnerabilities and Exposures (CVE) project has
assigned the name CVE-2026-4873 to this issue.

CWE-319: Cleartext Transmission of Sensitive Information

Severity: Low


AFFECTED VERSIONS

    Affected versions: curl 7.20.0 to and including 8.19.0
    Not affected versions: curl < 7.20.0 and >= 8.20.0
    Introduced-in: https://github.com/curl/curl/commit/ec3bb8f727405642a

libcurl is used by many applications, but not always
advertised as such!

This bug is not considered a C mistake. It is not likely
to have been avoided had we not been using C.

This flaw also affects the curl command line tool.


SOLUTION

curl 8.20.0 fixes this logical flaw

    Fixed-in: https://github.com/curl/curl/commit/507e7be573b0a76fca597b75


RECOMMENDATIONS

We suggest you take one of the following actions immediately,
in order of preference:

A - Upgrade to curl and libcurl 8.20.0

B - Apply the patch and rebuild libcurl

C - Do not use clear-text IMAP/POP3/SMTP transfers


TIMELINE

It was reported to the curl project on March 22 2026. We
contacted distros@openwall on April 23.

libcurl 8.20.0 was released on April 29 2026, coordinated
with the publication of this advisory.


CREDITS

    Reported-by: Arkadi Vainbrand
    Patched-by: Daniel Stenberg

Thanks a lot!

=========================================================
+ CERT-RENATER        |    tel : 01-53-94-20-44         +
+ 23/25 Rue Daviel    |    fax : 01-53-94-20-41         +
+ 75013 Paris         |   email:cert@support.renater.fr +
=========================================================