curl的作者Danie在他的博客中分享了curl的23.9年的DOS漏洞。1998年10月，curl4.9发布，curl4.9是第一个带有“cookie引擎”的版本，可以接收HTTPcookie、解析、理解并在后续请求中正确返回cookie。当然，当时curl的受众很小，过了几个月curl网站才宣布curll4.9已经被下载了300次。并且当时没有明确的cookie规范，唯一描述cookie如何工作的规范是Netscape的一个非常短的文档，称为cookie_spec。在随后的日子里，IETF（互联网工程任务组）一直在努力创建cookie规范，但大部分都没有成功。因为cookie有点特殊，它们被许多不同的作者、代码库和网站实现，从根本上改变了“自上而下规范”的工作方式。在2011年发布的CookieRFC6265之前，这是真正的cookie规范，解释了什么是cookie以及它应该遵守什么。但这也带来了一些问题，RFC6265提供了服务器如何发送cookie的字段语法，以及客户端接受cookie的完全不同的语法。双重语法导致两个问题：很难阅读规范，因为很容易陷入其中一种语法并假设该语法对所有用例都有效。定义发送cookie的语法没有什么用处，因为客户端才是真正决定如何接收和处理cookie的人。现有的大型cookie解析器（如浏览器）在接受的内容格式上相当自由，没有人关注服务器是否遵循RFC规范中的语法。Cookie随着时间的推移继续缓慢发展，但HTTP规范在过去几十年中已更新多次。更重要的是，HTTP服务器实现实施了更严格的解析策略：如果传入的HTTP请求看起来“非法”或格式错误，HTTP服务器会过早地开始拒绝它们。现在尝试向新的HTTP服务器发送带有控制代码的请求，服务器将简单地拒绝该请求并返回400响应代码。一个长达23年的漏洞2022年6月下旬，curl收到了一份关于curl存在疑似安全问题的报告，这导致curl随后发布了CVE-2022-35252。事实证明，1998年的curlcookie代码接受包含控制代码的cookie。控制代码可以是名称或内容的一部分，如果用户启用“cookie引擎”，curl将存储这些cookie并在后续请求时返回它们。例如：Set-Cookie:name^a=content^b;domain=.example.com^a和^b代表控制码，字节码一和二。由于域可以将cookie标记为另一个主机。因此，cookie将包含在对该域内所有主机的请求中。当curl将这样的cookie发送到HTTP服务器时，它在传出请求中包含一个如下所示的标头字段：Cookie:name^a=content^b并且默认配置的服务器将以400响应。对于接收这些的脚本或应用程序cookies，只要继续发送cookies，进一步的请求就会被拒绝，形成拒绝服务DOS攻击。这些易受攻击的cookie代码从4.9版（curl项目开发的第201天）开始就存在于curl中，直到7.85.0版（curl项目开发的第8930天）才得到修复，中间用了8729天（23.9年）。当然，正如Daniel所解释的：这些cookie代码在发布时是没有问题的，并且在用户使用它们的大部分时间里都没有问题。并且最新版本的curl已经完全符合最新的RFC6265bis草案版本。
