Gitea expands a workflow’s static matrix into its full cartesian product without imposing a size limit when a run is created, before the fork pull request approval gate is enforced. A contributor who can open a pull request from a fork can supply a workflow file with a small matrix that expands to a very large number of jobs, consuming all server RAM and potentially terminating the Gitea process; no runner or external action is required for the attack.

The issue impacts the Gitea platform, specifically versions before the 28.0.0 release, because those releases lack the 256‑combination hard cap on static matrices. Any Gitea instance that allows pull requests from forks to modify or create workflow files is at risk.

The vulnerability is highly exploitable for any system permitting forked pull requests containing workflow files. An attacker can trigger a denial‑of‑service with minimal effort, causing service disruption for all repositories served by the instance. The public CVSS score is absent and EPSS data is unavailable; however, the severity is evident from the memory exhaustion impact. The vulnerability is not catalogued in the CISA KEV, but the potential for widespread service interruption demands prompt remediation. The attack vector is inferred to be a forked pull request that is accepted without proper matrix‑size validation.