Notifications
Clear all
Topic starter
01/08/2026 10:45 pm
TL;DR: Inefficient regular expressions with nested quantifiers or overlapping alternation can trigger catastrophic backtracking, leading to denial of service in Python projects and already contributing to CVE-2020-8492 and related bugs, according to Semgrep. The practical lesson is that regex review belongs in secure development and SAST workflows, not as a post-incident cleanup step.
NHIMG editorial — based on content published by Semgrep: get this check now in Bento
By the numbers:
- 90% of IT leaders say properly managing NHIs is essential for a successful zero-trust implementation.
- Only 5.7% of organisations have full visibility into their service accounts.
- 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.
Questions worth separating out
Q: What breaks when a regular expression is vulnerable to catastrophic backtracking?
A: The application can stop responding because the regex engine consumes excessive CPU trying many matching paths for a single input.
Q: Why do regex bugs matter in identity and access workflows?
A: Identity workflows often depend on parsing, validation, and policy evaluation logic that accepts user input or token contents.
Q: How do security teams know a regex is actually risky?
A: Look for structural warning signs such as nested repetition, overlapping alternation, or a trailing token that forces repeated backtracking.
Practitioner guidance
- Inventory regexes on trusted input paths Map every regular expression that touches authentication, authorisation, token parsing, or request validation and rank them by exposure to untrusted input.
- Block ambiguous regex structures in review Reject nested quantifiers and overlapping alternation unless there is a documented, tested reason they cannot be rewritten.
- Add regex-focused SAST rules Use Semgrep or equivalent static analysis to detect structural ReDoS patterns early in the pipeline and route findings to secure engineering review.
What's in the full article
Semgrep's full post covers the operational detail this post intentionally leaves for the source:
- The exact Bento check logic used to detect inefficient regular expressions in Python projects.
- Examples of the specific vulnerable patterns found in urllib, poetry, grpc, colorama, bottle, and requests-kerberos.
- The engineering workflow Semgrep used to run the check across several thousand open source Python projects.
- Background on the Python bpo-39503 and CVE-2020-8492 findings that the pattern uncovered.
👉 Read Semgrep's analysis of ReDoS bugs in Python regular expressions →
Python regex backtracking: what security teams need to check?
Explore further
01/08/2026 10:54 pm
ReDoS is a governance problem when regexes sit on trust boundaries. The article shows that a tiny pattern flaw can create an availability incident, which means secure development teams should treat regexes as security-relevant code. In identity-heavy systems, these patterns often sit in authentication, token parsing, and policy logic, so a failure here can block access as effectively as an outage. Practitioners should review regex risk as part of application and identity governance, not as a formatting issue.
A few things that frame the scale:
- 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface, according to Ultimate Guide to NHIs.
- 71% of NHIs are not rotated within recommended time frames, increasing the risk of compromise over time.
A question worth separating out:
Q: Who should own ReDoS prevention in a development programme?
A: Application security, secure engineering, and the team that owns the affected service should share ownership. The key is to treat regex review as a release gate for exposed code paths, because availability failures caused by pattern matching are a product risk, not just a developer mistake.
👉 Read our full editorial: ReDoS risk in Python regexes exposes availability gaps
