How a 23‑Year‑Old Curl Bug Exposed Cookie Security Flaws

curl author Daniel Stenberg shared on his personal blog a vulnerability that existed for 23.9 years. curl is a widely used command‑line tool for requesting web servers, first released in 1997.

The flaw was introduced 201 days after curl’s initial release and remained unfixed until day 8930.

curl 4.9 and cookies

In October 1998, Stenberg’s team released curl 4.9, the first version with a “cookie engine” capable of receiving, parsing, and returning HTTP cookies. Most of the cookie‑handling code was written by Stenberg himself.

At that time, cookie specifications were still informal, relying on a Netscape‑maintained document (cookie_spec). The early implementation referenced this document and the prevailing browser behavior.

For the next decade, the IETF struggled to create a definitive cookie standard. It wasn’t until 2011 that an official RFC (RFC 6265) was published, documenting the actual usage of cookies. Stenberg participated in its development, though he did not fully agree with all its contents.

Challenges of dual cookie syntax

The new cookie RFC introduced two separate syntaxes: one for how servers send cookies and another for how clients should accept them, leading to confusion and maintenance difficulties.

Reading the specification became hard, as developers could mistakenly focus on the wrong syntax.

The syntax for sending cookies is less critical because clients ultimately decide how to handle them; browsers have flexibility, and the specification continues to evolve (e.g., 6265bis).

curl updated its implementation to stay compatible with the draft RFC 6265bis, but the dual‑syntax issue remains unresolved.

If an incoming HTTP request appears “illegal” or malformed, modern servers (e.g., Apache httpd 2.4.25+, recent Nginx) reject it with a 400 response, especially when control characters are present.

When designing cookies today, the process would differ, with stricter handling of attributes such as the domain scope.

curl bug details and fix

In late June 2022, Stenberg received a report that led to CVE‑2022‑35252. The old cookie code from 1998 accepted cookies containing control characters, storing and retransmitting them.

Example of a problematic cookie:

Set-cookie: name^a=content^b; domain=.example.com

Here ^a and ^b represent control characters. When curl sends such a cookie, the request header looks like: cookie: name^a=content^b Servers like Apache httpd reject these requests with a 400 error. The RFC 6265 section 5.2 states that clients should discard cookies containing control characters, but the wording is obscure.

Chrome and Firefox already ignore incoming cookies with byte values %01‑%08, %0b‑%0c, %0e‑%1f, and %7f (excluding TAB and line‑break characters).

The fix applied by Stenberg is straightforward: reject any cookie field that contains one or more prohibited byte values, a change considered low‑risk.

Conclusion

The vulnerable code existed from curl 4.9 and was finally fixed in version 7.85.0, after 8,729 days (23.9 years). The bug was introduced on day 201 of the project and fixed on day 8930.

Although the code functioned without issue for most users, HTTP servers began rejecting the malformed cookies, turning the bug into a denial‑of‑service scenario with side effects.

This bug may have originated alongside RFC 6265 or when HTTP servers started rejecting such requests, marking it as the fourth known bug that persisted for over 8,000 days.