`SimpleCookie` regex can make parsing extremely slow for adversarial payloads

[KowalskiThomas]

Bug report

Bug description:

The current version of http.cookies has a potential performance/security regression (seemingly introduced by #113663) and detected through fuzzing, where a bad cookie payload could significantly slow down request processing on a server relying on SimpleCookie (such as bottle here or tornado there). Such a cookie could be easily be crafted by a bad actor, leading to potential denial of service.

This branch on my fork proposes an alternative regular expression that does not seem to have the problem as well as a reproducer. When run (without the regex change), it clearly shows the problem:

$ ./python reproducer_cookie_redos.py
Timing SimpleCookie().load() with increasing payload size
  units   bytes        time
      1      18      0.0001s
      2      36      0.0001s
      3      54      0.0003s
      4      72      0.0010s
      5      90      0.0042s
      6     108      0.0163s
      7     126      0.0648s
      8     144      0.2560s
      9     162      1.0294s
     10     180      4.1919s
     11     198     16.6055s

For reference, the reproducer is

import sys
import time
import http.cookies

_UNIT = 'x="qu\\"qu\\\\"quot<'   # raw: x="qu\"qu\\"quot<

def make_payload(units: int = 11) -> str:
    """Return a Cookie header value that causes ~4^units backtrack steps."""
    return (" " + _UNIT) * units

print("Timing SimpleCookie.load with increasing payload size")
print(f"  {'units':>5}  {'bytes':>6}  {'time':>10}")
for n in range(1, 14):
    payload = make_payload(n)
    start = time.perf_counter()
    http.cookies.SimpleCookie().load(payload)
    elapsed = time.perf_counter() - start
    print(f"  {n:>5}  {len(payload):>6}  {elapsed:>10.4f}s")
    if elapsed > 10:
        print("  (stopping)")
        break

Keep in mind the alternative regex was LLM-generated, and it is complex enough that it is hard for me to validate its correctness -- it does make the reproducer happy though. I do not think this should necessarily be merged as-is, I mainly want to report the potential security issue.

Note I did not report this as a security issue because the original PR went out in August 2025; 3.14 was already in beta and so only the unreleased version of Python is affected. I downloaded and built 3.14 manually to make sure, and 3.14 is not affected by this regression.

The PSRT does not accept reports that only affect pre-release versions of software, as these features are considered "in-development", please open public issues. (source)

CPython versions tested on:

CPython main branch

Operating systems tested on:

Linux

[tim-one]

I agree this is serious, and thanks for reporting it.

• Could you please attach a simple reproducer? We don't need the complications of setting up a client or server - just construct "problem strings" and call SimpleCookie functions directly.
• The LLM-generated regexp in your fork is absurdly complicated. I don't know exactly what we intend to accept, but, for example, JSON-encoded string literals can be recognized efficiently with much simpler regexps. No worse than
  • Double quote.
  • Any number of (backslash followed by a single character, or single character that's not a backslash or double quote)
  • Double quote.
• I agree it's clear that the current regexp can be provoked into exponential time on fails-to-match cases due to ambiguity about which characters could "match next". In the English description above, there's no such ambiguity. Once a backslash is seen, "the other choice" explicitly disallows matching a backslash next, so the engine has to continue backtracking.

[tim-one]

Well, I haven't been able to figure out what we intend to support for cookie values containing double quotes. We accept more than JSON encoding can produce - that always backslash-escapes an internal double quote, which makes it easy to check. Our regexp as written can often accept internal double quotes without escaping, which makes it ambiguous whether a double quote is internal or signals the end of a double-quoted string.

Or maybe I'm misunderstanding it. But can't fix it if I don't understand it 😦

[KowalskiThomas]

Updated the reproducer on my branch to make it way simpler -- initially I wanted it to showcase a "real life" use case with a server/client just to make sure this was an actually realistic scenario, but I think now I have found the tornado and bottle examples anyway, we can probably assume it's realistic.

I'll give the old/new regexes another look later today, I just wanted to report it as soon as possible; the 3.15 release is still pretty far but the sooner it's reported and fixed the better!

[tim-one]

Agreed on all points - and, if possible, I'd like to get it fixed before the upcoming 3.14 patch release. If 3.14.5 goes out as-is, then this becomes a "security issue" for real.

[StanFromIreland]

Agreed on all points - and, if possible, I'd like to get it fixed before the upcoming 3.14 patch release. If 3.14.5 goes out as-is, then this becomes a "security issue" for real.

d7dbde8 wasn't backported to 3.14?

[tim-one]

Ah! Good catch, @StanFromIreland! I really wouldn't know. All I do know is that "it's broken" on the main branch.

To illustrate why I'm baffled about our intent, here on the main branch:

>>> from http import cookies
>>> C = cookies.SimpleCookie()
>>> C.load('key="a""b"')
>>> C
<SimpleCookie: key='a""b'>

JSON encoding will never produce such a string, and standards don't allow for it either. We're obviously trying to cater to some more-or-less common abuse, but I can't figure out exactly what. Python itself parses

"a""b"

as a catenation of two double-quoted strings, evaluating to plain

ab

The cookie code is stripping off the "enclosing" double quotes and leaving the two in the middle alone. It's ambiguous, and the current regexp relies on a minimal match to break ambiguity (which can lead to exponential time to fail to match an input). JSON would encode it as

"a\"\"b"

which is dead easy to deal with. I assume, but don't know, that the PR adding this stuff intended to deal with JSON encodings showing up in cookie values, but coded a flawed regexp that accepts a much broader set of strings.

[picnixz]

JSON encoding will never produce such a string, and standards don't allow for it either. We're obviously trying to cater to some more-or-less common abuse, but I can't figure out exactly what. Python itself parses

Indeed, https://www.rfc-editor.org/rfc/rfc6265.html#section-4.1.1 grammar is:

 set-cookie-header = "Set-Cookie:" SP set-cookie-string
 set-cookie-string = cookie-pair *( ";" SP cookie-av )
 cookie-pair       = cookie-name "=" cookie-value
 cookie-name       = token
 cookie-value      = *cookie-octet / ( DQUOTE *cookie-octet DQUOTE )
 cookie-octet      = %x21 / %x23-2B / %x2D-3A / %x3C-5B / %x5D-7E
                       ; US-ASCII characters excluding CTLs,
                       ; whitespace DQUOTE, comma, semicolon,
                       ; and backslash

However, there were some updates (see #92936 (comment)) and the specs seem to allow a bit more things.

cc @Dreamsorcerer @collinanderson @orsenthil

---

On a personal note, I think SimpleCookie should do one of the following:

• Expect a properly JSON-encoded value to support common uses in the wild.
• Strictly follow Section 4.1.1 and reject nested double quotes.
• Only allow JSON-encoded values with an additional flag (say loads(strict=False)) or something like that. We can't add a feature that allows adversaries to perform DoS.

[KowalskiThomas]

I was thinking earlier today about how this could be fixed; the conclusion I reached was that the last option might be the best suited one, as the default behaviour would be safe, and users that do need unsafe patterns (like in the original issue #92936) could "take the risk", but knowingly do so.