Summary
CodeQL flagged 2 high-severity "Polynomial regular expression used on uncontrolled data" alerts, surfaced on PR #2680 but unrelated to that PR's diff (confirmed via git diff main — neither file is touched there). Filing separately per repo convention rather than expanding that PR's scope.
Locations
packages/objectql/src/validation/record-validator.ts:231 (usage) — pattern defined at line 46:
const EMAIL_RE = /^[^\s@]+@[^\s@]+\.[^\s@]+$/;
packages/objectql/src/validation/rule-validator.ts:577 (usage) — same pattern defined at line 533.
CodeQL's finding: the regex "can run slow on strings starting with !@!. and with many repetitions of !." — classic polynomial backtracking from two adjacent unbounded [^...]+ quantifiers with overlapping character classes around a required literal.
Why it matters
Both files validate the email field type used by validateRecord/rule-based validation — i.e. user-supplied record field values run through this pattern. A field value crafted to trigger catastrophic-ish backtracking (long repeated !. sequences) could cause a slow validation call, tying up the event loop — a DoS vector on any write path (REST create/update, import, seed) that validates an email-typed field.
Suggested fix
Replace with a bounded, non-backtracking email pattern, e.g. anchoring the local/domain parts with length caps or using a single-pass character class without adjacent unbounded quantifiers around the same delimiter, such as:
const EMAIL_RE = /^[^\s@]{1,64}@[^\s@]{1,255}\.[^\s@]{1,24}$/;
(bound the repetition so worst-case backtracking is O(n) instead of polynomial), or adopt a well-vetted linear-time email regex. Apply the same fix to both files (they currently duplicate the pattern) — worth checking whether they can share one definition instead of two copies drifting independently.
Refs
Summary
CodeQL flagged 2 high-severity "Polynomial regular expression used on uncontrolled data" alerts, surfaced on PR #2680 but unrelated to that PR's diff (confirmed via
git diff main— neither file is touched there). Filing separately per repo convention rather than expanding that PR's scope.Locations
packages/objectql/src/validation/record-validator.ts:231(usage) — pattern defined at line 46:const EMAIL_RE = /^[^\s@]+@[^\s@]+\.[^\s@]+$/;packages/objectql/src/validation/rule-validator.ts:577(usage) — same pattern defined at line 533.CodeQL's finding: the regex "can run slow on strings starting with
!@!.and with many repetitions of!." — classic polynomial backtracking from two adjacent unbounded[^...]+quantifiers with overlapping character classes around a required literal.Why it matters
Both files validate the
emailfield type used byvalidateRecord/rule-based validation — i.e. user-supplied record field values run through this pattern. A field value crafted to trigger catastrophic-ish backtracking (long repeated!.sequences) could cause a slow validation call, tying up the event loop — a DoS vector on any write path (REST create/update, import, seed) that validates anemail-typed field.Suggested fix
Replace with a bounded, non-backtracking email pattern, e.g. anchoring the local/domain parts with length caps or using a single-pass character class without adjacent unbounded quantifiers around the same delimiter, such as:
(bound the repetition so worst-case backtracking is O(n) instead of polynomial), or adopt a well-vetted linear-time email regex. Apply the same fix to both files (they currently duplicate the pattern) — worth checking whether they can share one definition instead of two copies drifting independently.
Refs