GHSA-FJ8V-HJWV-QM88
Vulnerability from github – Published: 2026-07-21 20:40 – Updated: 2026-07-21 20:40Summary
GetActionsUserRepoPermission (models/perm/access/repo_permission.go) decides whether an Actions
task token may access a target repo. Its cross-repo branches each enforce a fork-PR discriminator —
except the collaborative-owner branch, which is missing the !task.IsForkPullRequest guard that
its sibling has. As a result, when a private repo B lists owner A as a collaborative owner, an
attacker-controlled fork pull-request workflow whose base repo is owned by A is granted code-read
on B — i.e. the fork's YAML can clone a third private repository it has no rights to.
Details
// models/perm/access/repo_permission.go (v1.26.2), in GetActionsUserRepoPermission
if checkSameOwnerCrossRepoAccess(ctx, taskRepo, repo, task.IsForkPullRequest) { // passes isForkPR -> denies forks
return maxPerm, nil
}
...
if taskRepo.IsPrivate { // <-- NO IsForkPullRequest check here
actionsUnit := repo.MustGetUnit(ctx, unit.TypeActions)
if actionsUnit.ActionsConfig().IsCollaborativeOwner(taskRepo.OwnerID) {
return maxPerm, nil // grants code-read to target repo B
}
}
The sibling same-owner path correctly denies fork PRs:
func checkSameOwnerCrossRepoAccess(ctx, taskRepo, targetRepo, isForkPR bool) bool {
if isForkPR {
return false // Fork PRs are never allowed cross-repo access to other private repositories.
}
...
}
taskRepo = the repo whose workflow is running (the PR's base repo A); repo = the target being
cloned (B). IsCollaborativeOwner(taskRepo.OwnerID) asks "does target B's Actions config trust A's
owner for cross-repo read?" When B trusts ownerA, the branch returns maxPerm (code-read) even when
task.IsForkPullRequest is true — i.e. when the executing YAML is the fork's, not A's.
Every sibling enforces the fork-PR discriminator; except for this branch:
checkSameOwnerCrossRepoAccess denies forks; ComputeTaskTokenPermissions
(models/actions/token_permissions.go) only clamps the token ceiling to read-only for fork/cross-repo
(its own comment notes the access decision is in GetActionsUserRepoPermission, so it does not
neutralize the gap — it just makes the leak read-only); secrets (models/secret/secret.go) and the
approval gate (services/actions/notifier_helper.go) both correctly key on IsForkPullRequest.
Reachability — the runner clones target repo B over git-HTTP with the task token:
routers/web/repo/githttp.go → GetDoerRepoPermission(ctx, repoB, ActionsUser) →
GetActionsUserRepoPermission(ctx, repoB, actionsUser, taskID) with IsForkPullRequest == true →
collaborative-owner branch returns code-read → p.CanAccess(Read, code) passes → private clone of B
succeeds. (CheckRepoScopedToken in githttp is a no-op for the Actions token.)
PoC
Setup: private base repo A (usera/repoA), private third repo
B (userb/repoB) with a planted SECRET.txt, B's Actions config trusting usera as a collaborative
owner, and a genuine running fork-PR task token (token_hash computed with Gitea's own HashToken)
presented as HTTP Basic. Requesting GET /userb/repoB.git/info/refs?service=git-upload-pack:
| Condition (same fork-PR token) | HTTP | Meaning |
|---|---|---|
| anonymous (no token) | 401 | auth required |
| token, A public, B trusts A | 404 | branch gated on taskRepo.IsPrivate ⇒ A public skips it |
| token, A private, B has no collab-owner config | 404 | no trust ⇒ denied |
| token, A private, B trusts A (collab-owner) | 200 | git clone of private B succeeds |
| config removed / restored | 404 / 200 | deterministic |
In the 200 case, git clone of private repo B succeeded and yielded its SECRET.txt — the full source
of a third private repo the fork-PR author has no rights to.
Impact
Read-only confidentiality breach: discloses the full source of a third private repository (B) to an untrusted external fork-PR author. Read-only, not write/RCE.
Preconditions (honest):
1. B is deliberately configured with a collaborative owner — but that is exactly the feature's intended
use, so realistic for any deployment using it.
2. The fork PR's base repo A is itself private (the branch is gated on taskRepo.IsPrivate). Forking a
private A already requires read on A, so this is a normal internal-contributor situation, not a
weakening — the escalation is "read A (granted) → read a different private repo B (never granted)."
3. The fork-PR workflow must actually run — most realistically via an attacker who had one earlier PR
approved (the "approved before" path in ifNeedApproval), after which fork PRs auto-run.
Suggested remediation
Add the same fork-PR guard the sibling path has (one line):
if taskRepo.IsPrivate && !task.IsForkPullRequest {
actionsUnit := repo.MustGetUnit(ctx, unit.TypeActions)
if actionsUnit.ActionsConfig().IsCollaborativeOwner(taskRepo.OwnerID) {
return maxPerm, nil
}
}
This flips Vuln_ForkPR_LeaksThirdPrivateRepo to PASS, keeps Control_NonFork_Allowed PASS
(legitimate collaborative-owner sharing still works), and leaves the existing
TestGetActionsUserRepoPermission suite all green.
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "gitea.dev"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.27.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-58416"
],
"database_specific": {
"cwe_ids": [
"CWE-280",
"CWE-863"
],
"github_reviewed": true,
"github_reviewed_at": "2026-07-21T20:40:03Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "### Summary\n\n`GetActionsUserRepoPermission` (`models/perm/access/repo_permission.go`) decides whether an Actions\ntask token may access a target repo. Its cross-repo branches each enforce a fork-PR discriminator \u2014\n**except the collaborative-owner branch**, which is missing the `!task.IsForkPullRequest` guard that\nits sibling has. As a result, when a private repo **B** lists owner **A** as a collaborative owner, an\n**attacker-controlled fork pull-request** workflow whose base repo is owned by A is granted code-read\non B \u2014 i.e. the fork\u0027s YAML can clone a third private repository it has no rights to.\n\n### Details\n\n```go\n// models/perm/access/repo_permission.go (v1.26.2), in GetActionsUserRepoPermission\nif checkSameOwnerCrossRepoAccess(ctx, taskRepo, repo, task.IsForkPullRequest) { // passes isForkPR -\u003e denies forks\n return maxPerm, nil\n}\n...\nif taskRepo.IsPrivate { // \u003c-- NO IsForkPullRequest check here\n actionsUnit := repo.MustGetUnit(ctx, unit.TypeActions)\n if actionsUnit.ActionsConfig().IsCollaborativeOwner(taskRepo.OwnerID) {\n return maxPerm, nil // grants code-read to target repo B\n }\n}\n```\n\nThe sibling same-owner path correctly denies fork PRs:\n\n```go\nfunc checkSameOwnerCrossRepoAccess(ctx, taskRepo, targetRepo, isForkPR bool) bool {\n if isForkPR {\n return false // Fork PRs are never allowed cross-repo access to other private repositories.\n }\n ...\n}\n```\n\n`taskRepo` = the repo whose workflow is running (the PR\u0027s base repo A); `repo` = the target being\ncloned (B). `IsCollaborativeOwner(taskRepo.OwnerID)` asks \"does target B\u0027s Actions config trust A\u0027s\nowner for cross-repo read?\" When B trusts ownerA, the branch returns `maxPerm` (code-read) **even when\n`task.IsForkPullRequest` is true** \u2014 i.e. when the executing YAML is the fork\u0027s, not A\u0027s.\n\nEvery sibling enforces the fork-PR discriminator; except for this branch:\n`checkSameOwnerCrossRepoAccess` denies forks; `ComputeTaskTokenPermissions`\n(`models/actions/token_permissions.go`) only clamps the token *ceiling* to read-only for fork/cross-repo\n(its own comment notes the access *decision* is in `GetActionsUserRepoPermission`, so it does not\nneutralize the gap \u2014 it just makes the leak read-only); secrets (`models/secret/secret.go`) and the\napproval gate (`services/actions/notifier_helper.go`) both correctly key on `IsForkPullRequest`.\n\n**Reachability** \u2014 the runner clones target repo B over git-HTTP with the task token:\n`routers/web/repo/githttp.go` \u2192 `GetDoerRepoPermission(ctx, repoB, ActionsUser)` \u2192\n`GetActionsUserRepoPermission(ctx, repoB, actionsUser, taskID)` with `IsForkPullRequest == true` \u2192\ncollaborative-owner branch returns code-read \u2192 `p.CanAccess(Read, code)` passes \u2192 private clone of B\nsucceeds. (`CheckRepoScopedToken` in githttp is a no-op for the Actions token.)\n\n### PoC\n\nSetup: private base repo A (`usera/repoA`), private third repo\nB (`userb/repoB`) with a planted `SECRET.txt`, B\u0027s Actions config trusting `usera` as a collaborative\nowner, and a genuine running fork-PR task token (`token_hash` computed with Gitea\u0027s own `HashToken`)\npresented as HTTP Basic. Requesting `GET /userb/repoB.git/info/refs?service=git-upload-pack`:\n\n| Condition (same fork-PR token) | HTTP | Meaning |\n|---|---|---|\n| anonymous (no token) | 401 | auth required |\n| token, A **public**, B trusts A | 404 | branch gated on `taskRepo.IsPrivate` \u21d2 A public skips it |\n| token, A private, B has **no** collab-owner config | 404 | no trust \u21d2 denied |\n| **token, A private, B trusts A (collab-owner)** | **200** | **`git clone` of private B succeeds** |\n| config removed / restored | 404 / 200 | deterministic |\n\nIn the 200 case, `git clone` of private repo B succeeded and yielded its `SECRET.txt` \u2014 the full source\nof a third private repo the fork-PR author has no rights to.\n\n### Impact\n\nRead-only confidentiality breach: discloses the full source of a *third* private repository (B) to an\nuntrusted external fork-PR author. Read-only, not write/RCE.\n\nPreconditions (honest):\n1. B is deliberately configured with a collaborative owner \u2014 but that is exactly the feature\u0027s intended\n use, so realistic for any deployment using it.\n2. The fork PR\u0027s base repo A is itself private (the branch is gated on `taskRepo.IsPrivate`). Forking a\n private A already requires read on A, so this is a normal internal-contributor situation, not a\n weakening \u2014 the escalation is \"read A (granted) \u2192 read a *different* private repo B (never granted).\"\n3. The fork-PR workflow must actually run \u2014 most realistically via an attacker who had one earlier PR\n approved (the \"approved before\" path in `ifNeedApproval`), after which fork PRs auto-run.\n\n### Suggested remediation\n\nAdd the same fork-PR guard the sibling path has (one line):\n\n```go\nif taskRepo.IsPrivate \u0026\u0026 !task.IsForkPullRequest {\n actionsUnit := repo.MustGetUnit(ctx, unit.TypeActions)\n if actionsUnit.ActionsConfig().IsCollaborativeOwner(taskRepo.OwnerID) {\n return maxPerm, nil\n }\n}\n```\n\nThis flips `Vuln_ForkPR_LeaksThirdPrivateRepo` to PASS, keeps `Control_NonFork_Allowed` PASS\n(legitimate collaborative-owner sharing still works), and leaves the existing\n`TestGetActionsUserRepoPermission` suite all green.",
"id": "GHSA-fj8v-hjwv-qm88",
"modified": "2026-07-21T20:40:03Z",
"published": "2026-07-21T20:40:03Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/go-gitea/gitea/security/advisories/GHSA-fj8v-hjwv-qm88"
},
{
"type": "WEB",
"url": "https://github.com/go-gitea/gitea/pull/38214"
},
{
"type": "WEB",
"url": "https://github.com/go-gitea/gitea/commit/1d43b736b5a16c5f80cfdcd9a9448a9c983ddaa0"
},
{
"type": "PACKAGE",
"url": "https://github.com/go-gitea/gitea"
},
{
"type": "WEB",
"url": "https://github.com/go-gitea/gitea/releases/tag/v1.27.0"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:N/A:N",
"type": "CVSS_V3"
}
],
"summary": "Gitea: Fork-PR Actions task can read a third private repository via the collaborative-owner branch (missing fork-PR guard)"
}
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.