Skip to content

bug: bound regex evaluation to prevent ReDoS in regex detection rails #2203

Description

@coderabbitai

Did you check docs and existing issues?

  • I have searched the existing issues of NeMo-Guardrails.
  • I have read all the NeMo-Guardrails docs. Not applicable: this is a source-level hardening follow-up.
  • I have updated the package to the latest version before submitting this issue. Not applicable: this is a source-level hardening follow-up.

Python version (python --version)

Not applicable — static source-level security hardening task.

Operating system/version

Not applicable — static source-level security hardening task.

NeMo-Guardrails version (if you must use a specific version and not the latest)

Current develop branch / follow-up from PR #2185.

Describe the bug

Configured regex patterns are compiled with Python's backtracking re engine and are later evaluated against user input, model output, and retrieval text. Syntax validation at configuration load time does not bound matching time. A pathological configured pattern combined with crafted request text can cause catastrophic backtracking and pin a worker (ReDoS).

Affected areas:

  • nemoguardrails/library/regex/rail_config.py (RegexDetectionOptions.compile_patterns)
  • The runtime matching path(s) that call compiled_patterns against input, output, or retrieval text

Steps To Reproduce

  1. Configure a regex-detection pattern with catastrophic-backtracking behavior, such as a nested quantified expression.
  2. Submit sufficiently long input, output, or retrieval text that almost matches the pattern but fails near the end.
  3. Observe that Python re matching can consume unbounded worker time.

Expected Behavior

Regex detection must reject unsafe configured patterns or bound matching work/time and input size, while preserving valid regex behavior, case-insensitive matching, and clear invalid-pattern validation.

Actual Behavior

Patterns are only syntax-checked at configuration load time. The standard-library re matching path has no timeout, safe-pattern restriction, complexity bound, or input-length limit.

Acceptance Criteria

  • Prevent unbounded regex evaluation on request text using a timeout-capable matcher or a documented safe-pattern subset combined with input-length limits.
  • Preserve case_insensitive behavior and existing invalid-pattern error reporting.
  • Apply the protection to input, output, and retrieval matching paths.
  • Add focused tests covering rejection/timeout/bounding behavior and ordinary valid patterns.

Context

Requested by @Pouyanpi as follow-up hardening outside PR #2185.

Backlinks:

Metadata

Metadata

Assignees

Labels

bugSomething isn't workingstatus: needs triageNew issues that have not yet been reviewed or categorized.

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions