Summary: curl/libcurl doesn't consider IPv6 address zone index when doing connection reuse. if connection exists to specific IPv6 address (and other conditions for connection reuse are fulfilled) it will be reused for connections regardless of the zone index. Steps To Reproduce: Set up a fake server: echo -ne 'HTTP/1.1 200 OK\r\nContent-Length: 6\r\n\r\nHello\n' | nc -6 -v -l -p 9999 curl "http://[ipv6addr]:9999/x" "http://[ipv6addr%25lo]:9999/y" Both connections arrive to the test server: ``` Listening on :: 9999 Connection received on somehost someport GET /x HTTP/1.1 Host: [ipv6addr]:9999 User-Agent: curl/7.83.0-DEV Accept: / GET /y HTTP/1.1 Host: [ipv6addr]:9999 User-Agent: curl/7.83.0-DEV Accept: / ``` Clearly the 2nd connection should fail as the address is not available at interface lo. (Lone connection to http://[ipv6addr%25lo]:9999/ fails with curl: (7) Couldn't connect to server) This vulnerability isn't exploitable with public IPv6 addresses on linux systems (it seems kernel strips out zone index for public addresses). It is exploitable with macOS however, and possibly other non-linux OSes. Impact Reuse of wrong connection leading to potential disclosure of confidential...