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

How it was found

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.