{"schema_version":"1.7.2","id":"OESA-2026-2477","modified":"2026-05-29T13:33:45Z","published":"2026-05-29T13:33:45Z","upstream":["CVE-2026-4873","CVE-2026-5545","CVE-2026-5773","CVE-2026-6253","CVE-2026-6276","CVE-2026-6429","CVE-2026-7168"],"summary":"curl security update","details":"cURL is a computer software project providing a library (libcurl) and command-line tool (curl) for transferring data using various protocols.\r\n\r\nSecurity Fix(es):\n\nA vulnerability exists where a connection requiring TLS incorrectly reuses an\nexisting unencrypted connection from the same connection pool. If an initial\ntransfer is made in clear-text (via IMAP, SMTP, or POP3), a subsequent request\nto that same host bypasses the TLS requirement and instead transmit data\nunencrypted.(CVE-2026-4873)\n\nlibcurl might in some circumstances reuse the wrong connection when asked to\ndo an authenticated HTTP(S) request after a Negotiate-authenticated one, when\nboth use the same host.\n\nlibcurl features a pool of recent connections so that subsequent requests can\nreuse an existing connection to avoid overhead.\n\nWhen reusing a connection a range of criteria must be met. Due to a logical\nerror in the code, a request that was issued by an application could\nwrongfully reuse an existing connection to the same server that was\nauthenticated using different credentials.\n\nAn application that first uses Negotiate authentication to a server with\n`user1:password1` and then does another operation to the same server asking\nfor any authentication method but for `user2:password2` (while the previous\nconnection is still alive) - the second request gets confused and wrongly\nreuses the same connection and sends the new request over that connection\nthinking it uses a mix of user1's and user2's credentials when it is in fact\nstill using the connection authenticated for user1...(CVE-2026-5545)\n\nlibcurl might in some circumstances reuse the wrong connection for SMB(S)\ntransfers.\n\nlibcurl features a pool of recent connections so that subsequent requests can\nreuse an existing connection to avoid overhead.\n\nWhen reusing a connection a range of criteria must be met. Due to a logical\nerror in the code, a network transfer operation that was requested by an\napplication could wrongfully reuse an existing SMB connection to the same\nserver that was using a different 'share' than the new subsequent transfer\nshould.\n\nThis could in unlucky situations lead to the download of the wrong file or the\nupload of a file to the wrong place. When this happens, the same credentials\nare used and the server name is the same.(CVE-2026-5773)\n\ncurl might erroneously pass on credentials for a first proxy to a second\nproxy.\n\nThis can happen when the following conditions are true:\n\n1. curl is setup to use specific different proxies for different URL schemes\n2. the first proxy needs credentials\n3. the second proxy uses no credentials\n4. while using the first proxy (using say `http://`), curl is asked to follow\n   a redirect to a URL using another scheme (say `https://`), accessed using a\n   second, different, proxy(CVE-2026-6253)\n\nUsing libcurl, when a custom `Host:` header is first set for an HTTP request\nand a second request is subsequently done using the same *easy handle* but\nwithout the custom `Host:` header set, the second request would use stale\ninformation and pass on cookies meant for the first host in the second\nrequest. Leak them.(CVE-2026-6276)\n\nWhen asked to both use a `.netrc` file for credentials and to follow HTTP\nredirects, libcurl could leak the password used for the first host to the\nfollowed-to host under certain circumstances.(CVE-2026-6429)\n\nSuccessfully using libcurl to do a transfer over a specific HTTP proxy\n(`proxyA`) with **Digest** authentication and then changing the proxy host to\na second one (`proxyB`) for a second transfer, reusing the same handle, makes\nlibcurl wrongly pass on the `Proxy-Authorization:` header field meant for\n`proxyA`, to `proxyB`.(CVE-2026-7168)","affected":[{"package":{"ecosystem":"openEuler:24.03-LTS-SP1","name":"curl","purl":"pkg:rpm/openEuler/curl&distro=openEuler-24.03-LTS-SP1"},"ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"8.4.0-30.oe2403sp1"}]}],"ecosystem_specific":{"aarch64":["curl-8.4.0-30.oe2403sp1.aarch64.rpm","curl-debuginfo-8.4.0-30.oe2403sp1.aarch64.rpm","curl-debugsource-8.4.0-30.oe2403sp1.aarch64.rpm","libcurl-8.4.0-30.oe2403sp1.aarch64.rpm","libcurl-devel-8.4.0-30.oe2403sp1.aarch64.rpm"],"noarch":["curl-help-8.4.0-30.oe2403sp1.noarch.rpm"],"src":["curl-8.4.0-30.oe2403sp1.src.rpm"],"x86_64":["curl-8.4.0-30.oe2403sp1.x86_64.rpm","curl-debuginfo-8.4.0-30.oe2403sp1.x86_64.rpm","curl-debugsource-8.4.0-30.oe2403sp1.x86_64.rpm","libcurl-8.4.0-30.oe2403sp1.x86_64.rpm","libcurl-devel-8.4.0-30.oe2403sp1.x86_64.rpm"]}}],"references":[{"type":"ADVISORY","url":"https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-2477"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-4873"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-5545"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-5773"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-6253"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-6276"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-6429"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-7168"}],"database_specific":{"severity":"High"}}