Summary
A workflow approval bypass in Gitea Actions can allow jobs from a first-time fork pull request to run without the required maintainer approval. The issue occurs when a user with Actions write access cancels a run awaiting approval and reruns it while Actions and a matching runner are available.
A workflow approval bypass in Gitea Actions can allow jobs from a first-time fork pull request to run without the required maintainer approval. The issue occurs when a user with Actions write access cancels a run awaiting approval and reruns it while Actions and a matching runner are available.
Affected context
This vulnerability affects Gitea repositories where:
- Actions are enabled.
- Workflow runs from first-time fork pull request contributors require maintainer approval.
- A matching repository runner is registered.
- A user with Actions write access can cancel and rerun workflow runs.
The risk arises when a pending approval state is not preserved when a completed or cancelled run is rerun.
This vulnerability affects Gitea repositories where:
- Actions are enabled.
- Workflow runs from first-time fork pull request contributors require maintainer approval.
- A matching repository runner is registered.
- A user with Actions write access can cancel and rerun workflow runs.
The risk arises when a pending approval state is not preserved when a completed or cancelled run is rerun.
Exploit preconditions
- Attack surface: Gitea Actions workflow rerun handling.
- Required access: Ability to cancel and rerun workflow runs, generally associated with Actions write access.
- Trigger point: Rerunning a cancelled workflow run that was awaiting approval for fork-originated code.
- Required deployment conditions: Actions must be enabled and a compatible runner must be available.
- Why exploitation is possible: The rerun path can create jobs in a waiting state without enforcing the approval requirement recorded for the run.
- Attack surface: Gitea Actions workflow rerun handling.
- Required access: Ability to cancel and rerun workflow runs, generally associated with Actions write access.
- Trigger point: Rerunning a cancelled workflow run that was awaiting approval for fork-originated code.
- Required deployment conditions: Actions must be enabled and a compatible runner must be available.
- Why exploitation is possible: The rerun path can create jobs in a waiting state without enforcing the approval requirement recorded for the run.
Why this happens
The underlying bug is an authorization-state inconsistency in workflow rerun processing.
The system checked whether a run was finished before creating jobs for a new attempt but did not reapply the pending fork approval requirement. As a result, job creation treated the workflow as eligible to run even though the run still indicated that maintainer approval was required.
This maps to CWE-285: Improper Authorization, because a security-sensitive approval decision was not consistently enforced across an alternate execution path.
The underlying bug is an authorization-state inconsistency in workflow rerun processing.
The system checked whether a run was finished before creating jobs for a new attempt but did not reapply the pending fork approval requirement. As a result, job creation treated the workflow as eligible to run even though the run still indicated that maintainer approval was required.
This maps to CWE-285: Improper Authorization, because a security-sensitive approval decision was not consistently enforced across an alternate execution path.
Potential impact
- Fork-controlled workflow code may run on repository-managed runners.
- Jobs may access runner-provided credentials, tokens, or environment data.
- Repository resources or connected services could be modified without the intended approval.
- Sensitive build artifacts or source data could be exposed.
- Compromise may extend to other systems reachable from the runner, depending on its permissions.
- Fork-controlled workflow code may run on repository-managed runners.
- Jobs may access runner-provided credentials, tokens, or environment data.
- Repository resources or connected services could be modified without the intended approval.
- Sensitive build artifacts or source data could be exposed.
- Compromise may extend to other systems reachable from the runner, depending on its permissions.
General mitigation guidance
Mitigation generally focuses on preserving authorization decisions across every workflow lifecycle and rerun path.
Common defensive patterns include:
- Re-evaluating fork approval requirements whenever jobs are created or rerun.
- Treating pending approval as a mandatory execution gate rather than only run metadata.
- Applying consistent authorization checks to cancellation, retry, and rerun transitions.
- Using least-privilege permissions for repository runners and workflow tokens.
- Separating untrusted pull request workloads from privileged runners and sensitive environments.
- Limiting secrets and external credentials available to workflows originating from untrusted forks.
Mitigation generally focuses on preserving authorization decisions across every workflow lifecycle and rerun path.
Common defensive patterns include:
- Re-evaluating fork approval requirements whenever jobs are created or rerun.
- Treating pending approval as a mandatory execution gate rather than only run metadata.
- Applying consistent authorization checks to cancellation, retry, and rerun transitions.
- Using least-privilege permissions for repository runners and workflow tokens.
- Separating untrusted pull request workloads from privileged runners and sensitive environments.
- Limiting secrets and external credentials available to workflows originating from untrusted forks.
How teams detect issues like this
Organizations can look for this class of issue through:
- Static and architectural review of workflow state-transition and authorization logic.
- Code review checks covering rerun, retry, cancellation, and job-creation paths.
- Tests that verify approval requirements remain enforced after every supported workflow transition.
- Audit monitoring for fork-originated jobs that execute without a corresponding approval event.
- Policy checks preventing untrusted workflows from using privileged runners or protected secrets.
Automated security review tools may help identify inconsistent authorization checks, but workflow-state testing remains important because the defect depends on the interaction between multiple lifecycle paths.
Organizations can look for this class of issue through:
- Static and architectural review of workflow state-transition and authorization logic.
- Code review checks covering rerun, retry, cancellation, and job-creation paths.
- Tests that verify approval requirements remain enforced after every supported workflow transition.
- Audit monitoring for fork-originated jobs that execute without a corresponding approval event.
- Policy checks preventing untrusted workflows from using privileged runners or protected secrets.
Automated security review tools may help identify inconsistent authorization checks, but workflow-state testing remains important because the defect depends on the interaction between multiple lifecycle paths.
Sources
| Source | Link |
|---|---|
| blog. | blog.gitea.com/ |
| github. | github.com/ |
| github. | github.com/ |
| github. | github.com/ |
