For pull request events, Gitea reads workflow definitions from the pull request head and posts a synthetic skipped status when workflow branch or path filters exclude execution. A fork pull request author can supply a workflow matching a required status context but deliberately prevent it from running. Because skipped statuses count as success, branch protection or organization‑required workflow checks can appear satisfied without the mandated workflow executing; no runner or maintainer approval is required for this path. The likely attack vector is a forked pull request created by a malicious contributor who supplies a custom workflow file designed to be filtered out, yet declares a required status context, thereby tricking the system into marking the PR as passing all required checks.

Affected systems are hosted Gitea installations running any version prior to the patch released in Gitea 1.27.3. The vendor product identified is Gitea, and the fix is included in version 1.27.3 and later. All earlier releases that implement the same workflow status handling are potentially affected, especially those with active fork‑pull‑request activity.

The risk is moderate, with a CVSS score of 6.5, an EPSS score of less than 1% indicating a very low probability of exploitation, and it is not listed in the CISA KEV catalog. Once a fork PR contains a deliberately skipped workflow and the system interprets the skipped status as success, an attacker can merge code that has bypassed the required workflow checks. The exploitation requires only the ability to create a PR from a forked repository that hosts the malicious workflow file; no additional adversary privileges are needed beyond standard pull‑request creation privileges.