Описание
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.
A flaw was found in curl. When libcurl performs a transfer to an HTTP origin using Digest authentication and then reuses the same connection handle for a subsequent transfer to a different origin, it may incorrectly send the authentication header intended for the first origin to the second. This could lead to unintended information disclosure, potentially allowing an attacker to gain unauthorized access to sensitive data.
Отчет
This Moderate-severity flaw in libcurl can lead to information disclosure when an application reuses a libcurl handle for transfers to different HTTP origins while using Digest authentication. The vulnerability arises from libcurl incorrectly sending the authentication header intended for the initial origin to a subsequent, different origin. This could expose sensitive authentication data to an unintended recipient, potentially compromising user credentials or session information. The only observed impact from this flaw is an integrity impact.
- libcurl only — the curl CLI is not affected
- Requires an application to reuse an easy handle across different HTTP origins while Digest auth state is attached — a specific programming pattern
- Credentials themselves are not leaked; only the authenticated state ("Authorization: ..." HTTP header)
- Fixed in curl 8.21.0; affected range: 7.10.6 – 8.20.0
Меры по смягчению последствий
Mitigation for this issue is either not available or the currently available options do not meet the Red Hat Product Security criteria comprising ease of use and deployment, applicability to widespread installation base or stability. Correct usage of the library: Create a fresh handle for a different origin, or explicitly clear authentication-related state before reuse:
Fixed in libcurl 8.21.0; affected range: 7.10.6 – 8.20.0
Затронутые пакеты
| Платформа | Пакет | Состояние | Рекомендация | Релиз |
|---|---|---|---|---|
| Red Hat Enterprise Linux 10 | curl | Affected | ||
| Red Hat Enterprise Linux 6 | curl | Out of support scope | ||
| Red Hat Enterprise Linux 7 | curl | Out of support scope | ||
| Red Hat Enterprise Linux 8 | curl | Affected | ||
| Red Hat Enterprise Linux 9 | curl | Affected | ||
| Red Hat OpenShift Container Platform 4 | rhcos | Fix deferred | ||
| Red Hat OpenShift Dev Spaces | devspaces/code-rhel9 | Not affected | ||
| Red Hat Trusted Profile Analyzer | rhtpa/rhtpa-trustification-service-rhel9 | Not affected | ||
| Red Hat Hardened Images | curl-main-8.21.0-0.1.hum1 | Fixed | RHSA-2026:29017 | 24.06.2026 |
| Red Hat Hardened Images | rust-main-1.96.1-1.hum1 | Fixed | RHSA-2026:34975 | 02.07.2026 |
Показывать по
Дополнительная информация
Статус:
EPSS
6.5 Medium
CVSS3
Связанные уязвимости
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`.
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`.
Successfully using libcurl to do a transfer to a specific HTTP origin ...
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`.
EPSS
6.5 Medium
CVSS3