Why a 23‑Year‑Old curl Cookie Bug Went Unnoticed Until 2022

Background and Timeline

In October 1998 Daniel Stenberg released curl 4.9, the first version with a built‑in cookie engine capable of receiving, parsing, and returning HTTP cookies. The code was written against the early Netscape cookie_spec document, as no formal RFC existed at the time.

Stenberg later helped author the official cookie RFC (RFC 6265) published in 2011, but the early implementation remained in curl for decades.

Dual‑Syntax Cookie Specification

The 2011 RFC introduced two separate syntaxes: one describing how servers set cookies and another describing how clients should accept them. This caused two main problems:

Developers often read only one side of the spec, mistakenly believing it applied to their use case.

Servers and browsers could interpret the spec differently, and the spec continued to evolve (the 6265bis draft).

curl updated its parser to follow RFC 6265bis, yet the dual‑syntax issue persisted.

The Vulnerability (CVE‑2022‑35252)

In June 2022 a security report revealed that curl’s legacy cookie code still accepted cookies containing control characters (bytes 0x01‑0x08, 0x0b‑0x0c, 0x0e‑0x1f, 0x7f). When the “cookie engine” was enabled, curl stored such cookies and later sent them back in requests.

Example of a malicious Set‑Cookie header:

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

Here ^a and ^b represent control‑character bytes. When curl forwards this cookie, the request header looks like: cookie: name^a=content^b Most HTTP servers (e.g., Apache 2.4.25+, recent Nginx) reject such requests with a 400 response, effectively causing a denial‑of‑service when the buggy cookie is sent.

The RFC states that clients should discard cookies containing control characters, but the wording is obscure and many developers overlook it.

Browser Behaviour

Both Chrome and Firefox already ignore incoming cookies that contain any of the following byte ranges (except TAB 0x09 and line‑breaks 0x0a/0x0d):

%01-%08 / %0b-%0c / %0e-%1f / %7f

Fix Implementation

Stenberg’s patch simply rejects any cookie field that includes one or more prohibited byte values. The change is low‑risk because it aligns curl with the behaviour of major browsers and with the RFC’s intent.

Impact and Lessons

The vulnerable code existed from curl 4.9 (released on day 201) and was only fixed in curl 7.85.0 (day 8930), a span of 8 729 days (23.9 years). The bug did not cause major issues while servers accepted the malformed cookies, but once HTTP servers began rejecting them, the bug manifested as a service‑disruption vector.

This case illustrates how legacy code, ambiguous specifications, and long‑standing assumptions can combine to hide critical security flaws for decades.