Server-side ReDoS via user-controlled regex in OIDC Access Policy

The OIDC Access Policy implementation evaluates user-supplied regular expressions against JWT claim values using Ruby’s Regexp engine without any timeout or complexity validation. The vulnerable code path is: Regexp.new(value).match?(claim_value) Where: - `value` is fully user-controlled (defined when creating an OIDC API Key Role using the `string_matches` operator) - `claim_value` is derived from JWT claims and can be influenced via GitHub Actions metadata (e.g. branch names) A malicious regular expression with catastrophic backtracking characteristics can be supplied, causing the server to spend an excessive amount of CPU time evaluating a single request. Example pattern: ^(a+)+$ Example input: refs/heads/aaaaaaaaaaaaaaaaaaaaaaaaaaaaaa! This causes Ruby’s regex engine to enter exponential backtracking during evaluation. ## Impact A single crafted request can block a Puma worker thread for an extended period of time due to catastrophic regex backtracking. Since RubyGems.org runs with a very small thread pool, a small number of concurrent requests can exhaust all available workers, resulting in partial or full denial of service. This can disrupt gem publishing operations and CI/CD pipelines that rely on RubyGems.org availability.