"ThreadSafeCookieStore.add(Uri, Cookie)" reduces the request to its host and path before storing, so the scheme never reaches the code that decides whether to keep a cookie. "get(Uri)" does read it, but only to leave "Secure" cookies out of plaintext requests. A narrower form survives the two storage rules on their own. The step 16 path test is one-way by design, so a plaintext "SID" for "Path=/" is legitimately stored beside a Secure "SID" for "Path=/account", and both match a request under "/account". The store returned matching cookies in hash order, and the client keeps only the first cookie of each name when it builds the request ("RequestBuilderBase.addCookieIfUnset"), so an attacker could decide which one was sent, for example by padding one plaintext response with filler cookies. The ordering described above closes it. The fix does not stop an HTTPS host under the same site from setting a domain cookie for a name the request host never sets itself. Only a "__Host-" cookie name prefix prevents that, and the client does not enforce cookie name prefixes.