#18107: fix(security): prevent ReDoS in session filter patterns (CWE-1333)

## Summary Adds validation for regex patterns in session filters to prevent **accidental ReDoS (Regular Expression Denial of Service)** scenarios (CWE-1333). A user might write a pattern like `(a+)+` or `(.*)+` in their sessionFilter config without realizing it causes catastrophic backtracking. Crafted or even normal input matching these patterns can freeze the Node.js event loop, and debugging "why is my system hanging" when the cause is regex performance is not obvious. This validation catches dangerous patterns early with a clear warning, rather than silent CPU exhaustion. ## Changes - Add `src/utils/safe-regex.ts` with pattern validation utilities: - `isSafeRegexPattern()` — detects nested quantifiers like `(a+)+`, `((a+))+`, `(a{2,10})+`, etc. - `safePatternMatch()` — tries literal match first, validates regex before execution - Update `src/infra/exec-approval-forwarder.ts` to use safe matching - Update `src/discord/monitor/exec-approvals.ts` to use safe matching with logger - Add 22 comprehensive tests ## Behavior - Safe patterns: work as before (regex matching) - Dangerous patterns: rejected with warning, falls back to literal string match only - Invalid regex: handled gracefully, returns false ## Testing ``` pnpm exec vitest run src/utils/safe-regex.test.ts # 22/22 passing pnpm exec vitest run src/infra/exec-approval-forwarder # 6/6 passing pnpm exec vitest run src/discord/monitor/exec-approvals # 43/43 passing pnpm lint # 0 errors ``` ## References - **CWE-1333:** https://cwe.mitre.org/data/definitions/1333.html - **OWASP ReDoS:** https://owasp.org/www-community/attacks/Regular_expression_Denial_of_Service_-_ReDoS <!-- greptile_comment --> <h3>Greptile Summary</h3> Adds a `safePatternMatch` utility to prevent ReDoS (CWE-1333) in session filter regex matching, replacing inline try/catch regex logic in two call sites. The approach is sound: literal match first, then static pattern analysis to reject known-dangerous patterns, then an input length limit as defense-in-depth. - The static analysis detection regex has a bypass for patterns with 3+ levels of group nesting (e.g., `(((a+)))+`), though the input length limit mitigates the practical impact. - Integration in both `exec-approval-forwarder.ts` and `exec-approvals.ts` is clean, with correct logger wiring and preserved behavioral semantics. - Test suite is comprehensive with 22 tests covering dangerous patterns, safe patterns, literal matching, input length limits, and error handling. <h3>Confidence Score: 3/5</h3> - This PR is safe to merge with the noted static analysis gap mitigated by the input length limit - The core defense-in-depth strategy is solid and the integration is clean. Score reflects the detection bypass for triple-nested groups, though the 1000-char input length limit bounds the practical risk. The behavioral change is backward-compatible. - `src/utils/safe-regex.ts` — the `nestedGroupsRe` regex only handles exactly two levels of nesting and can be bypassed by patterns like `(((a+)))+` _{Last reviewed commit: e78765b} <!-- greptile_other_comments_section --> <!-- /greptile_comment -->