CVE-2026-107226: AsyncHttpClient: Cookies received over plaintext HTTP can plant, overwrite or delete Secure cookies set over HTTPS

The cookie store ignores the scheme a Set-Cookie arrived on. draft-ietf-httpbis-rfc6265bis-22 (approved to obsolete RFC 6265, in the RFC Editor queue) Section 5.7 requires a user agent to ignore a cookie with the Secure attribute unless it arrived over a secure connection (step 13), and to ignore a non-Secure cookie from an insecure connection when it would overlay a Secure cookie the store already holds (step 16). Neither rule is implemented. The only Secure handling is on retrieval, where a Secure cookie is not sent over plaintext.

So anyone who can answer a plaintext request to a site can set, replace or delete the site’s Secure cookies, and the next HTTPS request carries the attacker’s value back inside TLS:

http://example.com   ->  Set-Cookie: SID=attacker-value; Secure; Path=/
https://example.com  ->  Cookie: SID=attacker-value

This does not need an attacker on the network path. A plaintext host under the same site reaches the HTTPS one by setting a domain cookie:

http://insecure.example.com  ->  Set-Cookie: SID=attacker-value; Secure; Domain=example.com; Path=/
https://bank.example.com     ->  Cookie: SID=attacker-value

A plaintext Set-Cookie of the same name, domain and path overwrites a Secure cookie, and one with Max-Age=0 deletes it. Depending on what the application does with the cookie, this is session fixation into the HTTPS session, an overwritten CSRF token, or the removal of a cookie the site relies on. Unlike GHSA-qjr7-w8pj-pmv9, which can only add a cookie, this replaces or deletes one, hence Integrity: High; the harm lands on the HTTPS site, hence Scope: Changed.