Gitea fork workflow approval bypass through review events
Default status is the baseline for the product, each version can override it (e.g. patched versions marked unaffected).
| Vendor | Product | Default status | Versions | ||||||
|---|---|---|---|---|---|---|---|---|---|
| Gitea | Gitea | unaffected |
|
No data.
No data.
| Vendor | Product | Versions | ||||||||
|---|---|---|---|---|---|---|---|---|---|---|
| Gitea | Gitea |
|
No CVSS v4.0
No CVSS v3.0
No CVSS v2
This CVE is not in the KEV list.
Exploit prediction score: < 1% (0.490% probability within 30 days)
| Type | Values Removed | Values Added |
|---|---|---|
| First Time appeared |
Gitea
Gitea gitea |
|
| Vendors & Products |
Gitea
Gitea gitea |
| Type | Values Removed | Values Added |
|---|---|---|
| Metrics |
cvssV3_1
|
| Type | Values Removed | Values Added |
|---|---|---|
| Description | Gitea's pull request review notifier does not attach the pull request to the Actions notification, so the fork workflow approval gate does not recognize the run as originating from a fork. Review comment and review approval or rejection events can consequently load workflow code from the fork head and run it on the base repository's runners without the required maintainer approval. This allows execution of fork-controlled workflow code across the intended approval boundary. | |
| Title | Gitea fork workflow approval bypass through review events | |
| Weaknesses | CWE-863 | |
| References |
|