<?xml version="1.0" encoding="UTF-8"?>
<cvrfdoc xmlns="http://www.icasi.org/CVRF/schema/cvrf/1.1" xmlns:cvrf="http://www.icasi.org/CVRF/schema/cvrf/1.1">
	<DocumentTitle xml:lang="en">An update for curl is now available for openEuler-24.03-LTS-SP3</DocumentTitle>
	<DocumentType>Security Advisory</DocumentType>
	<DocumentPublisher Type="Vendor">
		<ContactDetails>openeuler-security@openeuler.org</ContactDetails>
		<IssuingAuthority>openEuler security committee</IssuingAuthority>
	</DocumentPublisher>
	<DocumentTracking>
		<Identification>
			<ID>openEuler-SA-2026-2453</ID>
		</Identification>
		<Status>Final</Status>
		<Version>1.0</Version>
		<RevisionHistory>
			<Revision>
				<Number>1.0</Number>
				<Date>2026-05-22</Date>
				<Description>Initial</Description>
			</Revision>
		</RevisionHistory>
		<InitialReleaseDate>2026-05-22</InitialReleaseDate>
		<CurrentReleaseDate>2026-05-22</CurrentReleaseDate>
		<Generator>
			<Engine>openEuler SA Tool V1.0</Engine>
			<Date>2026-05-22</Date>
		</Generator>
	</DocumentTracking>
	<DocumentNotes>
		<Note Title="Synopsis" Type="General" Ordinal="1" xml:lang="en">curl security update</Note>
		<Note Title="Summary" Type="General" Ordinal="2" xml:lang="en">An update for curl is now available for openEuler-24.03-LTS-SP3</Note>
		<Note Title="Description" Type="General" Ordinal="3" xml:lang="en">cURL is a computer software project providing a library (libcurl) and command-line tool (curl) for transferring data using various protocols.

Security Fix(es):

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

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&apos;s and user2&apos;s credentials when it is in fact
still using the connection authenticated for user1...(CVE-2026-5545)

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 &apos;share&apos; 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-5773)

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

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

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

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-2026-7168)</Note>
		<Note Title="Topic" Type="General" Ordinal="4" xml:lang="en">An update for curl is now available for openEuler-24.03-LTS-SP3.

openEuler Security has rated this update as having a security impact of high. A Common Vunlnerability Scoring System(CVSS)base score,which gives a detailed severity rating, is available for each vulnerability from the CVElink(s) in the References section.</Note>
		<Note Title="Severity" Type="General" Ordinal="5" xml:lang="en">High</Note>
		<Note Title="Affected Component" Type="General" Ordinal="6" xml:lang="en">curl</Note>
	</DocumentNotes>
	<DocumentReferences>
		<Reference Type="Self">
			<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-2453</URL>
		</Reference>
		<Reference Type="openEuler CVE">
			<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2026-4873</URL>
			<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2026-5545</URL>
			<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2026-5773</URL>
			<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2026-6253</URL>
			<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2026-6276</URL>
			<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2026-6429</URL>
			<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2026-7168</URL>
		</Reference>
		<Reference Type="Other">
			<URL>https://nvd.nist.gov/vuln/detail/CVE-2026-4873</URL>
			<URL>https://nvd.nist.gov/vuln/detail/CVE-2026-5545</URL>
			<URL>https://nvd.nist.gov/vuln/detail/CVE-2026-5773</URL>
			<URL>https://nvd.nist.gov/vuln/detail/CVE-2026-6253</URL>
			<URL>https://nvd.nist.gov/vuln/detail/CVE-2026-6276</URL>
			<URL>https://nvd.nist.gov/vuln/detail/CVE-2026-6429</URL>
			<URL>https://nvd.nist.gov/vuln/detail/CVE-2026-7168</URL>
		</Reference>
	</DocumentReferences>
	<ProductTree xmlns="http://www.icasi.org/CVRF/schema/prod/1.1">
		<Branch Type="Product Name" Name="openEuler">
			<FullProductName ProductID="openEuler-24.03-LTS-SP3" CPE="cpe:/a:openEuler:openEuler:24.03-LTS-SP3">openEuler-24.03-LTS-SP3</FullProductName>
		</Branch>
		<Branch Type="Package Arch" Name="aarch64">
			<FullProductName ProductID="curl-8.4.0-29" CPE="cpe:/a:openEuler:openEuler:24.03-LTS-SP3">curl-8.4.0-29.oe2403sp3.aarch64.rpm</FullProductName>
			<FullProductName ProductID="curl-debuginfo-8.4.0-29" CPE="cpe:/a:openEuler:openEuler:24.03-LTS-SP3">curl-debuginfo-8.4.0-29.oe2403sp3.aarch64.rpm</FullProductName>
			<FullProductName ProductID="curl-debugsource-8.4.0-29" CPE="cpe:/a:openEuler:openEuler:24.03-LTS-SP3">curl-debugsource-8.4.0-29.oe2403sp3.aarch64.rpm</FullProductName>
			<FullProductName ProductID="libcurl-8.4.0-29" CPE="cpe:/a:openEuler:openEuler:24.03-LTS-SP3">libcurl-8.4.0-29.oe2403sp3.aarch64.rpm</FullProductName>
			<FullProductName ProductID="libcurl-devel-8.4.0-29" CPE="cpe:/a:openEuler:openEuler:24.03-LTS-SP3">libcurl-devel-8.4.0-29.oe2403sp3.aarch64.rpm</FullProductName>
		</Branch>
		<Branch Type="Package Arch" Name="src">
			<FullProductName ProductID="curl-8.4.0-29" CPE="cpe:/a:openEuler:openEuler:24.03-LTS-SP3">curl-8.4.0-29.oe2403sp3.src.rpm</FullProductName>
		</Branch>
		<Branch Type="Package Arch" Name="x86_64">
			<FullProductName ProductID="curl-8.4.0-29" CPE="cpe:/a:openEuler:openEuler:24.03-LTS-SP3">curl-8.4.0-29.oe2403sp3.x86_64.rpm</FullProductName>
			<FullProductName ProductID="curl-debuginfo-8.4.0-29" CPE="cpe:/a:openEuler:openEuler:24.03-LTS-SP3">curl-debuginfo-8.4.0-29.oe2403sp3.x86_64.rpm</FullProductName>
			<FullProductName ProductID="curl-debugsource-8.4.0-29" CPE="cpe:/a:openEuler:openEuler:24.03-LTS-SP3">curl-debugsource-8.4.0-29.oe2403sp3.x86_64.rpm</FullProductName>
			<FullProductName ProductID="libcurl-8.4.0-29" CPE="cpe:/a:openEuler:openEuler:24.03-LTS-SP3">libcurl-8.4.0-29.oe2403sp3.x86_64.rpm</FullProductName>
			<FullProductName ProductID="libcurl-devel-8.4.0-29" CPE="cpe:/a:openEuler:openEuler:24.03-LTS-SP3">libcurl-devel-8.4.0-29.oe2403sp3.x86_64.rpm</FullProductName>
		</Branch>
		<Branch Type="Package Arch" Name="noarch">
			<FullProductName ProductID="curl-help-8.4.0-29" CPE="cpe:/a:openEuler:openEuler:24.03-LTS-SP3">curl-help-8.4.0-29.oe2403sp3.noarch.rpm</FullProductName>
		</Branch>
	</ProductTree>
	<Vulnerability Ordinal="1" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
		<Notes>
			<Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">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.</Note>
		</Notes>
		<ReleaseDate>2026-05-22</ReleaseDate>
		<CVE>CVE-2026-4873</CVE>
		<ProductStatuses>
			<Status Type="Fixed">
				<ProductID>openEuler-24.03-LTS-SP3</ProductID>
			</Status>
		</ProductStatuses>
		<Threats>
			<Threat Type="Impact">
				<Description>Medium</Description>
			</Threat>
		</Threats>
		<CVSSScoreSets>
			<ScoreSet>
				<BaseScore>5.9</BaseScore>
				<Vector>AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N</Vector>
			</ScoreSet>
		</CVSSScoreSets>
		<Remediations>
			<Remediation Type="Vendor Fix">
				<Description>curl security update</Description>
				<DATE>2026-05-22</DATE>
				<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-2453</URL>
			</Remediation>
		</Remediations>
	</Vulnerability>
	<Vulnerability Ordinal="2" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
		<Notes>
			<Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">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&apos;s and user2&apos;s credentials when it is in fact
still using the connection authenticated for user1...</Note>
		</Notes>
		<ReleaseDate>2026-05-22</ReleaseDate>
		<CVE>CVE-2026-5545</CVE>
		<ProductStatuses>
			<Status Type="Fixed">
				<ProductID>openEuler-24.03-LTS-SP3</ProductID>
			</Status>
		</ProductStatuses>
		<Threats>
			<Threat Type="Impact">
				<Description>Medium</Description>
			</Threat>
		</Threats>
		<CVSSScoreSets>
			<ScoreSet>
				<BaseScore>6.5</BaseScore>
				<Vector>AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:H/A:N</Vector>
			</ScoreSet>
		</CVSSScoreSets>
		<Remediations>
			<Remediation Type="Vendor Fix">
				<Description>curl security update</Description>
				<DATE>2026-05-22</DATE>
				<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-2453</URL>
			</Remediation>
		</Remediations>
	</Vulnerability>
	<Vulnerability Ordinal="3" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
		<Notes>
			<Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">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 &apos;share&apos; 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.</Note>
		</Notes>
		<ReleaseDate>2026-05-22</ReleaseDate>
		<CVE>CVE-2026-5773</CVE>
		<ProductStatuses>
			<Status Type="Fixed">
				<ProductID>openEuler-24.03-LTS-SP3</ProductID>
			</Status>
		</ProductStatuses>
		<Threats>
			<Threat Type="Impact">
				<Description>High</Description>
			</Threat>
		</Threats>
		<CVSSScoreSets>
			<ScoreSet>
				<BaseScore>7.5</BaseScore>
				<Vector>AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N</Vector>
			</ScoreSet>
		</CVSSScoreSets>
		<Remediations>
			<Remediation Type="Vendor Fix">
				<Description>curl security update</Description>
				<DATE>2026-05-22</DATE>
				<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-2453</URL>
			</Remediation>
		</Remediations>
	</Vulnerability>
	<Vulnerability Ordinal="4" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
		<Notes>
			<Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">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</Note>
		</Notes>
		<ReleaseDate>2026-05-22</ReleaseDate>
		<CVE>CVE-2026-6253</CVE>
		<ProductStatuses>
			<Status Type="Fixed">
				<ProductID>openEuler-24.03-LTS-SP3</ProductID>
			</Status>
		</ProductStatuses>
		<Threats>
			<Threat Type="Impact">
				<Description>Medium</Description>
			</Threat>
		</Threats>
		<CVSSScoreSets>
			<ScoreSet>
				<BaseScore>5.9</BaseScore>
				<Vector>AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H</Vector>
			</ScoreSet>
		</CVSSScoreSets>
		<Remediations>
			<Remediation Type="Vendor Fix">
				<Description>curl security update</Description>
				<DATE>2026-05-22</DATE>
				<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-2453</URL>
			</Remediation>
		</Remediations>
	</Vulnerability>
	<Vulnerability Ordinal="5" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
		<Notes>
			<Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">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.</Note>
		</Notes>
		<ReleaseDate>2026-05-22</ReleaseDate>
		<CVE>CVE-2026-6276</CVE>
		<ProductStatuses>
			<Status Type="Fixed">
				<ProductID>openEuler-24.03-LTS-SP3</ProductID>
			</Status>
		</ProductStatuses>
		<Threats>
			<Threat Type="Impact">
				<Description>High</Description>
			</Threat>
		</Threats>
		<CVSSScoreSets>
			<ScoreSet>
				<BaseScore>7.5</BaseScore>
				<Vector>AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H</Vector>
			</ScoreSet>
		</CVSSScoreSets>
		<Remediations>
			<Remediation Type="Vendor Fix">
				<Description>curl security update</Description>
				<DATE>2026-05-22</DATE>
				<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-2453</URL>
			</Remediation>
		</Remediations>
	</Vulnerability>
	<Vulnerability Ordinal="6" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
		<Notes>
			<Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">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.</Note>
		</Notes>
		<ReleaseDate>2026-05-22</ReleaseDate>
		<CVE>CVE-2026-6429</CVE>
		<ProductStatuses>
			<Status Type="Fixed">
				<ProductID>openEuler-24.03-LTS-SP3</ProductID>
			</Status>
		</ProductStatuses>
		<Threats>
			<Threat Type="Impact">
				<Description>Medium</Description>
			</Threat>
		</Threats>
		<CVSSScoreSets>
			<ScoreSet>
				<BaseScore>5.3</BaseScore>
				<Vector>AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:N/A:N</Vector>
			</ScoreSet>
		</CVSSScoreSets>
		<Remediations>
			<Remediation Type="Vendor Fix">
				<Description>curl security update</Description>
				<DATE>2026-05-22</DATE>
				<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-2453</URL>
			</Remediation>
		</Remediations>
	</Vulnerability>
	<Vulnerability Ordinal="7" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
		<Notes>
			<Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">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`.</Note>
		</Notes>
		<ReleaseDate>2026-05-22</ReleaseDate>
		<CVE>CVE-2026-7168</CVE>
		<ProductStatuses>
			<Status Type="Fixed">
				<ProductID>openEuler-24.03-LTS-SP3</ProductID>
			</Status>
		</ProductStatuses>
		<Threats>
			<Threat Type="Impact">
				<Description>Medium</Description>
			</Threat>
		</Threats>
		<CVSSScoreSets>
			<ScoreSet>
				<BaseScore>5.3</BaseScore>
				<Vector>AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N</Vector>
			</ScoreSet>
		</CVSSScoreSets>
		<Remediations>
			<Remediation Type="Vendor Fix">
				<Description>curl security update</Description>
				<DATE>2026-05-22</DATE>
				<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-2453</URL>
			</Remediation>
		</Remediations>
	</Vulnerability>
</cvrfdoc>