How a 23.9‑Year‑Old Curl Bug Exposed Critical Cookie Security Flaws

curl author Daniel Stenberg shared on his personal blog a vulnerability that had persisted for 23.9 years. curl, a widely used command‑line tool for making HTTP requests, was first released in 1997.

The flaw was introduced on the 201st day after curl’s initial release and remained unfixed until the 8 930th day, nearly 24 years later.

curl 4.9 and the Cookie Engine

In October 1998, Stenberg’s team released curl 4.9, the first version with a built‑in 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 immature; the only reference was the Netscape‑maintained “cookie_spec” document, which was incomplete and required developers to examine other clients for missing details.

Stenberg implemented cookie handling by consulting that document and the prevailing browser behavior of the era.

For the next decade, the IETF attempted to create a formal cookie specification but repeatedly failed, leading to a fragmented ecosystem where many implementations diverged.

Only in 2011 was RFC 6265 finally published, providing a de‑facto standard for cookie usage. Stenberg participated in its development, though he did not fully agree with every aspect.

Challenges of 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 making the spec hard to read.

Readers could mistakenly focus on the wrong syntax, misinterpreting role descriptions.

The server‑side syntax is less critical because clients ultimately decide which cookies to accept; browsers have leeway, and the spec continues to evolve (e.g., the 6265bis draft).

curl was updated over time to stay compatible with RFC 6265bis, but the dual‑syntax issue remains unresolved.

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

curl Bug Details and Fix

At the end of June 2022, Stenberg received a report suspecting a security issue, leading to the disclosure of CVE‑2022‑35252.

The legacy cookie code from 1998 accepted cookies containing control characters (bytes 0x01‑0x08, 0x0b‑0x0c, 0x0e‑0x1f, 0x7f). When the cookie engine was enabled, curl stored such cookies and sent them back in subsequent requests.

Example of a problematic Set‑Cookie header:

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

Here ^a and ^b represent control characters. When curl forwards this cookie, the request includes: cookie: name^a=content^b Most HTTP servers reject this with a 400 error, effectively causing a denial‑of‑service.

RFC 6265 §5.2 states that clients should discard cookies with control characters, but the wording is obscure and the spec does not explicitly define “control characters”.

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

The fix applied to curl is straightforward: reject any cookie field that contains one or more disallowed byte values. Stenberg considers this change low‑risk.

Conclusion

The vulnerable code existed from curl 4.9 and was finally fixed in curl 7.85.0, a span of 8 729 days (23.9 years). The bug was introduced early in the project’s lifecycle but only manifested when HTTP servers began rejecting malformed requests, turning a harmless implementation detail into a potential denial‑of‑service vector.