[issue41712] REDoS in purge

New submission from yeting li : I find this regex "(\d+\.\d+\.\d+)(\w+\d+)?$" may be stucked by input. The vulnerable regex is located in https://github.com/python/cpython/blob/54a66ade2067c373d31003ad260e1b7d14c81564/Tools/msi/purge.py#L15 The ReDOS vulnerability of the regex is

[issue41715] REDoS inc_analyzer

New submission from yeting li : Hi, I find this regex "^([a-zA-Z]|_\w*[a-zA-Z]\w*|[a-zA-Z]\w*)$" may be stucked by input. The vulnerable regex is located in https://github.com/python/cpython/blob/54a66ade2067c373d31003ad260e1b7d14c81564/Tools/c-analyzer/c_analyzer/common/info.py#L12

[issue41715] REDoS in c_analyzer

Change by yeting li : -- title: REDoS inc_analyzer -> REDoS in c_analyzer ___ Python tracker <https://bugs.python.org/issue41715> ___ ___ Python-bugs-list mai

[issue41715] REDoS in c_analyzer

Change by yeting li : -- components: +Library (Lib) type: -> security versions: +Python 3.10 ___ Python tracker <https://bugs.python.org/issue41715> ___ _

[issue41715] REDoS in c_analyzer

yeting li added the comment: I'm sorry there was a typo just now. replace _\w*[a-zA-Z]\w* with (_\d*)+([a-zA-Z]([_\d])*)+ -- ___ Python tracker <https://bugs.python.org/issue41

[issue41715] REDoS in c_analyzer

yeting li added the comment: You can use the dk.brics.automaton library to verify whether two regexes are equivalent. -- ___ Python tracker <https://bugs.python.org/issue41

[issue41715] REDoS in c_analyzer

yeting li added the comment: I think we can replace \w*[a-zA-Z]\w* with (_\d*)+([a-zA-Z]([_\d])*)+ This is an equivalent fix and the fixed regex is safe. Does that sound right to you? -- ___ Python tracker <https://bugs.python.org/issue41

[issue41921] REDoS in parseentities

New submission from yeting li : Hi, I find this regex '' may be stucked by input. The vulnerable regex is located in https://github.com/python/cpython/blob/8d21aa21f2cbc6d50aab3f420bb23be1d081dac4/Tools/scripts/parseentities.py#L18 The ReDOS vulnerability of the regex is mainly due to the sub

[issue43075] ReDoS in request

New submission from yeting li : Hi, I find this regex '(?:^|,)[ \t]*([^ \t]+)[ \t]+' may be stucked by input. The vulnerable regex is located in https://github.com/python/cpython/blob/5c5a938573ce665f00e362c7766912d9b3f3b44e/Lib/urllib/request.py#L946 The ReDOS vulnerability of the regex

[issue43075] ReDoS in request

Change by yeting li : -- keywords: +patch pull_requests: +23205 stage: needs patch -> patch review pull_request: https://github.com/python/cpython/pull/24391 ___ Python tracker <https://bugs.python.org/issu

[issue43075] ReDoS in request

yeting li added the comment: Thank you for your quick reply! I agree. Catastrophic backtracking is typically regarded as a regex with exponential worst-case matching time. Besides regexes with exponential worst-case time complexity, ReDoS also includes ones with other super-linear (e.g

[issue43075] ReDoS in urllib.request

yeting li added the comment: Sorry for the delay. I analyzed the performance of the current version '(?:^|,)[ \t]*([^ \t]+)[ \t]+' and the fixed version '(?:^|,)[ \t]*([^ \t,]+)[ \t]+'. I ran the following HTTP header ten times: header = '' + ',' * (10 ** 5) The current version takes about

[issue43075] ReDoS in urllib.request

yeting li added the comment: For a regex has polynomial worst-case complexity, limiting the maximum input length is indeed a very effective method. As shown below, as the input length becomes smaller, the matching time becomes significantly smaller. header = '' + ',' * (10 ** 4)1.617s