Skip to content

A fork pull request author can satisfy a required Actions status check without any workflow running, because a filtered out workflow taken from the pull request HEAD posts a `skipped` commit status that counts as success

Moderate
bircni published GHSA-5xp7-r6cr-39ff Aug 29, 2026

Package

gomod gitea.dev (Go)

Affected versions

<= 1.27.2

Patched versions

1.27.3

Description

Summary

Gitea writes a synthetic skipped commit status for a workflow that matched an event but was excluded by its own branches: or paths: filter, so that a required status check tied to that workflow does not block indefinitely. For a pull_request event the workflow definition is read from the pull request head commit, which for a fork pull request is controlled by the pull request author. The author can define a workflow whose name matches a required status check context and give it a filter that never matches, causing Gitea to write a skipped status under that context on the base repository. Because skipped counts as success when statuses are combined, the required check evaluates as passed.

Details

This path deliberately creates no workflow run, so the fork approval gate, which guards run creation, does not apply. No write access, runner or approval is required. The required context string is publicly visible as the check name on any pull request.

Impact

Bypass of branch-protection required status checks and of organization-mandated required workflows. Code can reach a protected branch with mandated checks shown as passing although nothing ran; where auto-merge is scheduled it can merge unattended. Any authenticated user who can fork and open a pull request is a potential actor.

Affected versions

Gitea <= 1.27.2.

Patches

Fixed in Gitea 1.27.3 (#39005, #39018).

Workarounds

None that preserve the protection. Upgrade to 1.27.3.

Severity

Moderate

CVSS overall score

This score calculates overall vulnerability severity from 0 to 10 and is based on the Common Vulnerability Scoring System (CVSS).
/ 10

CVSS v3 base metrics

Attack vector
Network
Attack complexity
Low
Privileges required
Low
User interaction
None
Scope
Unchanged
Confidentiality
None
Integrity
High
Availability
None

CVSS v3 base metrics

Attack vector: More severe the more the remote (logically and physically) an attacker can be in order to exploit the vulnerability.
Attack complexity: More severe for the least complex attacks.
Privileges required: More severe if no privileges are required.
User interaction: More severe when no user interaction is required.
Scope: More severe when a scope change occurs, e.g. one vulnerable component impacts resources in components beyond its security scope.
Confidentiality: More severe when loss of data confidentiality is highest, measuring the level of data access available to an unauthorized user.
Integrity: More severe when loss of data integrity is the highest, measuring the consequence of data modification possible by an unauthorized user.
Availability: More severe when the loss of impacted component availability is highest.
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:N

CVE ID

CVE-2026-66874

Weaknesses

Improper Access Control

The product does not restrict or incorrectly restricts access to a resource from an unauthorized actor. Learn more on MITRE.

Insufficient Verification of Data Authenticity

The product does not sufficiently verify the origin or authenticity of data, in a way that causes it to accept invalid data. Learn more on MITRE.

Protection Mechanism Failure

The product does not use or incorrectly uses a protection mechanism that provides sufficient defense against directed attacks against the product. Learn more on MITRE.

Reliance on Untrusted Inputs in a Security Decision

The product uses a protection mechanism that relies on the existence or values of an input, but the input can be modified by an untrusted actor in a way that bypasses the protection mechanism. Learn more on MITRE.

Credits