`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

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.