# Add an opt-in timeout parameter to re to mitigate catastrophic backtracking **URL:** \ **Category:** Ideas\ **Created:** [June 15, 2026, 5:26am UTC](https://discuss.python.org/t/add-an-opt-in-timeout-parameter-to-re-to-mitigate-catastrophic-backtracking/107766 "2026-06-15T05:26:34Z")\ **Posts on this page:** 1\ **Showing post:** 12
**Author:** ![tstefan](https://avatars.discourse-cdn.com/v4/letter/t/f475e1/32.png) [@tstefan](https://discuss.python.org/u/tstefan)\ **Post date:** [June 16, 2026, 1:04pm UTC](https://discuss.python.org/t/add-an-opt-in-timeout-parameter-to-re-to-mitigate-catastrophic-backtracking/107766/12 "2026-06-16T13:04:06Z")
Of course, Tim’s concerns are fair. > [@pf\_moore](#): > > **you should sanitise any untrusted input that you accept**! That is perfectly correct, so I would 100% agree not to simply use an untrusted, user provided input as a regex-pattern. However, when it is about the data, I would say that regexes are commonly used as a tool to validate untrusted, user provided data. That is ok if the regex-pattern is carefully crafted (as Tim has pointed out in his response to the bug report). One key ingredient are _possessive_ quantifiers as introduced in Python 3.11. However, getting it right seams still be so hard such that many people get it wrong. All complexity issues related to backtracking can be fully avoided, if it was possible to easily deactivate backtracking entirely using a flag. As Tim pointed out [here](https://discuss.python.org/t/don-t-allow-empty-regex-pattern/107633/20), backtracking is not actually required for many applications. My concern is not to massively expand CPython’s regex engine, however it might make sense to provide and promote means that are safer than the status quo. --- _[View the full topic](https://discuss.python.org/t/add-an-opt-in-timeout-parameter-to-re-to-mitigate-catastrophic-backtracking/107766)._