How a 23‑Year‑Old Curl Cookie Bug Evaded Detection Until 2022

curl 4.9 and cookies

In October 1998 Daniel Stenberg released curl 4.9, the first version with a cookie engine that could receive, parse, and correctly return HTTP cookies. Most of the cookie‑handling code was written by Stenberg.

At that time the cookie specification was still vague; the only description was the Netscape‑managed cookie_spec document, which was incomplete and required developers to inspect other clients for missing details.

For a decade the IETF attempted to create a formal cookie RFC without success, leading to many divergent implementations. In 2011 a proper cookie RFC was finally published, with Stenberg contributing his views.

Challenges of the dual cookie syntax

The new specification introduced two separate syntaxes: one for how servers send cookies and another for how clients should accept them, causing confusion and maintenance overhead.

Reading the spec became difficult, as developers could mistakenly follow the wrong syntax.

The server‑side syntax is less important because browsers decide which cookies to accept; the spec has been continuously updated (e.g., 6265bis).

curl was updated to follow the draft RFC 6265bis, but the dual syntax remains an unresolved issue.

curl bug details and fix

In late June 2022 Stenberg received a report that led to CVE‑2022‑35252. The bug stemmed from legacy cookie code (added in 1998) that accepted cookies containing control characters.

Example of such a cookie: Set-cookie: name^a=content^b; domain=.example.com When curl sent this cookie, the request header looked like: cookie: name^a=content^b Modern HTTP servers (Apache httpd, Nginx) reject these requests with a 400 response.

The RFC 6265 section 5.2 states that clients should discard cookies with control characters, but the wording is hard to interpret and does not list the prohibited byte ranges.

Chrome and Firefox already ignore cookies containing any of the following byte values: %01-%08 / %0b-%0c / %0e-%1f / %7f The fix in curl simply rejects any cookie field that contains one or more prohibited byte values, a low‑risk change.

Conclusion

The vulnerable code existed from curl 4.9 until it was finally fixed in version 7.85.0, a span of 8,729 days (23.9 years). The bug was introduced on day 201 after the project's first release and fixed on day 8,930.

Stenberg notes that the code worked fine in typical usage; the problem only surfaced when HTTP servers began rejecting suspicious requests, effectively turning the bug into a denial‑of‑service vector.

This bug joins a short list of defects that persisted for over 8,000 days before being discovered.