{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "code.gitea.io/gitea"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.26.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-58424"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-285",
      "CWE-732",
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-21T20:35:51Z",
    "nvd_published_at": "2026-07-03T21:17:05Z",
    "severity": "HIGH"
  },
  "details": "| Field | Value |\n|-------|-------|\n| **Identifier (researcher-assigned)** | GITEA-2026-004 |\n| **Product** | Gitea (self-hosted Git service) |\n| **Component** | Gitea Actions \u2014 fork pull request approval gate |\n| **Affected versions** | All Gitea releases **`v1.20.0` and later**, including the latest `main` (`1.27.0+dev-289-gb7e95cc48c`). The buggy logic was introduced in commit `edf98a2dc3` \u2014 *\"Require approval to run actions for fork pull request (#22803)\"*, 2023-02-24 \u2014 and has shipped unchanged since. |\n| **Fixed in** | not yet (this disclosure) |\n| **Authentication required** | Yes \u2014 one unprivileged Gitea account capable of forking the target repository (the default ability for every authenticated user) |\n| **User interaction required** | Exactly **once** \u2014 a repository administrator must approve a single benign fork PR\u0027s workflow run from the attacker. After that, *no further interaction is ever required* for any future fork PR from the same attacker on the same repository. |\n| **Discovered by** | Prakhar Porwal \u2014 `prakharporwal2004@gmail.com` |\n| **Live-verified on** | Gitea `main` at commit `b7e95cc48cc0e0d6fe24c89bb83da5b84a74490f`, 2026-05-24 |\n\n---\n\n## 1. Executive summary\n\nGitea Actions enforces an approval gate on workflow runs triggered by fork pull requests, so that an untrusted contributor cannot execute arbitrary workflow YAML on the maintainer\u0027s runner infrastructure without explicit consent. The gate is implemented by `ifNeedApproval()` in `services/actions/notifier_helper.go`. Its final clause skips the gate whenever the triggering user has **any** previously-approved run in the same repository:\n\n```go\n// services/actions/notifier_helper.go:423-433\nif count, err := db.Count[actions_model.ActionRun](ctx, actions_model.FindRunOptions{\n    RepoID:        repo.ID,\n    TriggerUserID: user.ID,\n    Approved:      true,\n}); err != nil {\n    return false, fmt.Errorf(\"CountRuns: %w\", err)\n} else if count \u003e 0 {\n    log.Trace(\"do not need approval because user %d has been approved before\", user.ID)\n    return false, nil\n}\n```\n\nThe check is scoped to `(repo_id, trigger_user_id)` only. It does not consider the pull request, the head commit, the workflow file contents, or any time window. The single approval click on a contributor\u0027s *first* fork PR is therefore interpreted by Gitea as *\"this user is permanently trusted to execute any workflow YAML on this repository\u0027s CI infrastructure forever\"* \u2014 for every future PR, on any branch, against any commit, regardless of what the workflow does.\n\nThis is a structural deviation from the documented intent \u2014 the in-source comment on the bypassing path reads *\"if it\u0027s the first time user \u2026 triggered actions\"*, implying a per-action-trigger check that the code does not actually perform. It is also a deviation from the equivalent behavior on the platform Gitea Actions is modeled after (GitHub Actions), where the first-contributor gate persists until a PR is **merged**, not merely approved-to-run.\n\nI have live-reproduced the bypass end-to-end against a current `main` build. With **zero further interaction** from the maintainer after the one-time approval, an attacker\u0027s second PR\u0027s workflow:\n\n- Was created with `need_approval = 0` and `approved_by = 0` in the `action_run` table (i.e. nobody ever approved it, and yet it was not gated).\n- Was dispatched to the runner immediately.\n- Executed arbitrary shell on the runner, with outbound network access, a populated `GITHUB_TOKEN`, and access to the cloned source.\n\nFull receipts are in \u00a73.\n\n---\n\n## 2. Affected code\n\n### Primary\n\n**`services/actions/notifier_helper.go:401-438`** \u2014 the `ifNeedApproval` function:\n\n```go\nfunc ifNeedApproval(ctx context.Context, run *actions_model.ActionRun,\n                    repo *repo_model.Repository, user *user_model.User) (bool, error) {\n    // 1. don\u0027t need approval if it\u0027s not a fork PR\n    // 2. don\u0027t need approval if the event is `pull_request_target` since the\n    //    workflow will run in the context of base branch\n    if !run.IsForkPullRequest ||\n       run.TriggerEvent == actions_module.GithubEventPullRequestTarget {\n        return false, nil\n    }\n\n    // always need approval if the user is restricted\n    if user.IsRestricted {\n        return true, nil\n    }\n\n    // don\u0027t need approval if the user can write\n    if perm, err := access_model.GetDoerRepoPermission(ctx, repo, user); err != nil {\n        return false, fmt.Errorf(\"GetDoerRepoPermission: %w\", err)\n    } else if perm.CanWrite(unit_model.TypeActions) {\n        return false, nil\n    }\n\n    // ===== VULNERABLE BLOCK ==================================================\n    // don\u0027t need approval if the user has been approved before\n    if count, err := db.Count[actions_model.ActionRun](ctx, actions_model.FindRunOptions{\n        RepoID:        repo.ID,\n        TriggerUserID: user.ID,\n        Approved:      true,\n    }); err != nil {\n        return false, fmt.Errorf(\"CountRuns: %w\", err)\n    } else if count \u003e 0 {\n        return false, nil   // \u003c-- permanent, unscoped bypass\n    }\n    // =========================================================================\n\n    return true, nil\n}\n```\n\nCalled from `handleWorkflows()` (`services/actions/notifier_helper.go:339`) for every workflow run created in response to a fork PR; the return value populates the `NeedApproval` column on the `action_run` row.\n\n### Supporting\n\n- **`models/actions/run_list.go:84-86`** \u2014 the `FindRunOptions.Approved` filter resolves to `approved_by \u003e 0`:\n  ```go\n  if opts.Approved {\n      cond = cond.And(builder.Gt{\"`action_run`.approved_by\": 0})\n  }\n  ```\n- **`services/actions/approve.go:25-27`** \u2014 the only writer of `ApprovedBy`, called when a repo admin clicks Approve on a run:\n  ```go\n  run.NeedApproval = false\n  run.ApprovedBy = doer.ID\n  if err := actions_model.UpdateRun(ctx, run, \"need_approval\", \"approved_by\"); err != nil {\n  ```\n- **`models/actions/run.go:44-45`** \u2014 schema:\n  ```go\n  NeedApproval bool                // may need approval if it\u0027s a fork pull request\n  ApprovedBy   int64 `xorm:\"index\"` // who approved\n  ```\n\nThere is no other writer of `ApprovedBy`, and no resetter for `NeedApproval` once a PR has been approved. The historical row is permanent and unconditional.\n\n---\n\n## 3. Live reproduction \u2014 receipts\n\nThe following was performed end-to-end against `main` on the date noted. Two accounts were used:\n\n- `admin` (uid 1) \u2014 repository owner playing the maintainer\n- `admin2` (uid 3) \u2014 second account playing the attacker\n\nA fork-mode `gitea-runner v1.0.6` was registered with `ubuntu-latest:host` to enable on-host execution.\n\n| Phase | Action | Resulting `action_run` row |\n|-------|--------|---------------------------|\n| 1 | `admin` creates `admin/base-repo` with `.gitea/workflows/ci.yml` (`echo hello` baseline) | \u2014 |\n| 2 | `admin2` forks the repo | \u2014 |\n| 3 | `admin2` opens PR #1 with a one-line README edit (no workflow change) | run #5 created, `need_approval = 1`, status = `Blocked` |\n| 4 | `admin` clicks **Approve and run workflows** on PR #1 | run #5 updates: `need_approval = 0`, `approved_by = 1` (admin), status \u2192 `Success` |\n| 5 | `admin2` opens PR #3 from a **brand-new branch** (`bypass-clean`) whose only change is `.gitea/workflows/ci.yml` rewritten to a malicious payload (loud `echo` + `curl` + `id` + `ls -la`) | **run #6 created, `need_approval = 0`, `approved_by = 0`** \u2014 gate skipped at creation |\n| \u2014 | runner dispatches run #6 within seconds, no maintainer interaction at all | run #6 \u2192 status = `Success` |\n\n### Final `action_run` table contents (queried directly from SQLite)\n\n```\nid  triggered_by_uid  need_approval  approved_by_uid  status_text  ref               sha\n--  ----------------  -------------  ---------------  -----------  ----------------  --------\n5   3                 0              1                Success      refs/pull/1/head  463c9114\n6   3                 0              0                Success      refs/pull/3/head  70db2b9e\n```\n\nRow 6 is the smoking gun: `triggered_by` is `admin2` (the attacker), `approved_by` is **0** (no one ever clicked Approve), `need_approval` is **0** (the gate was never engaged in the first place), and the workflow ran to completion. The row is schema-indistinguishable from a legitimate trusted-user run.\n\n### Actual payload log from run #6 (verbatim from `/api/v1/repos/admin/base-repo/actions/jobs/6/logs`)\n\n```\n2026-05-23T21:38:53Z local-demo-runner(version:v1.0.6) received task 2 of job test, be triggered by event: pull_request\n2026-05-23T21:38:53Z workflow prepared\n2026-05-23T21:38:53Z Run Main pwn\n...\n2026-05-23T21:38:53Z env:\n2026-05-23T21:38:53Z   BASE_TOKEN: ***\n2026-05-23T21:38:53Z ===== BYPASS DEMO - this workflow ran WITHOUT approval =====\n2026-05-23T21:38:53Z running as: uid=501(prakharporwal) gid=20(staff) groups=20(staff),12(everyone),...\n2026-05-23T21:38:53Z hostname:   PRAKHARs-MacBook-Air.local\n2026-05-23T21:38:53Z uname:      Darwin PRAKHARs-MacBook-Air.local 25.5.0 Darwin Kernel Version 25.5.0...\n2026-05-23T21:38:53Z GITHUB_TOKEN length = 40\n2026-05-23T21:38:53Z outbound network test:\n2026-05-23T21:38:53Z   HTTP 200\n2026-05-23T21:38:53Z repo contents:\n2026-05-23T21:38:53Z total 0\n2026-05-23T21:38:53Z drwxr-xr-x  2 prakharporwal  staff   64 24 May 03:08 .\n2026-05-23T21:38:53Z drwxr-xr-x  5 prakharporwal  staff  160 24 May 03:08 ..\n2026-05-23T21:38:53Z ===== END DEMO =====\n2026-05-23T21:38:53Z Job succeeded\n```\n\nConfirmed: arbitrary shell execution on the runner, populated `GITHUB_TOKEN` (40 chars), live outbound HTTPS (HTTP 200 to example.com), all triggered by an unapproved second fork PR.\n\n---\n\n## 4. Root cause analysis\n\nThe logic embodies a misreading of the unit of trust.\n\n| Intended (per comment on line 436) | Actually implemented |\n|-----------------------------------|---------------------|\n| Approval is required *the first time* a user triggers actions. | Approval is required *the very first time* a user triggers actions and **never again**. |\n| The unit of trust is the work being approved (the PR, or the commit). | The unit of trust is the user\u0027s identity, scoped to the repository. |\n\nThe query at line 424 does not include `PullRequestID`, `Ref`, `CommitSHA`, or any time predicate. The `action_run` row\u0027s `Ref` and `CommitSHA` fields are not consulted. Once `approved_by \u003e 0` appears on any historical row for `(repo_id, trigger_user_id)`, the gate is monotonically skipped forever.\n\nConcretely, the divergence is observable across these scenarios:\n\n| Scenario | Intended | Implemented |\n|----------|----------|-------------|\n| Same PR, new commit on the same branch | Re-run uses existing approval (PR-scoped) | Auto-approved (user-scoped) \u2713 |\n| Same PR, force-push that replaces the workflow file | Re-approval requested | Auto-approved \u2717 |\n| Brand-new PR from same user, different workflow | Approval requested | **Auto-approved** \u2717 \u2014 *the vulnerability* |\n| New PR from same user months later | Approval requested | Auto-approved \u2717 |\n| Hundred PRs from same user in parallel | Only the first is the gate check; subsequent depend on policy | Only the very first ever needs approval \u2717 |\n\nFor comparison, GitHub Actions\u0027 first-time-contributor gate persists *until a PR is merged*, not until a PR is approved-to-run; GitHub additionally supports per-PR re-approval as a separate setting. The Gitea code path does neither.\n\nA secondary contributor is the coarse semantics of `FindRunOptions.Approved`: a single boolean (`approved_by \u003e 0`) with no per-PR/per-commit predicate available. The fix therefore needs both a call-site change and a query-options extension.\n\n---\n\n## 5. Impact\n\n| Dimension | Detail |\n|-----------|--------|\n| **Arbitrary code execution on the runner** | Attacker controls `run:` blocks dispatched to the project\u0027s CI compute, with whatever ambient privileges the runner has (shell, network, filesystem). Verified end-to-end above. |\n| **Source code disclosure** | The runner clones the base repository read-only. A malicious workflow can exfiltrate it via any outbound channel \u2014 material confidentiality breach if the repo is private. |\n| **Actions cache poisoning** | Actions cache entries are keyed and shared across branches/refs within a repo. A poisoned cache is restored into trusted (non-fork) runs that subsequently execute on the base branch \u2014 **escaping the fork sandbox transitively**, and at that point with full secret access. |\n| **Artifact poisoning** | Workflow artifacts can be downloaded by other runs, including base-branch deploy workflows. |\n| **Runner host compromise** | If the runner is long-lived (not ephemeral) or shares state across jobs (filesystem leftovers, mounted Docker socket, sudoers entry for the runner user), the attacker can plant persistence. |\n| **Network pivoting** | Many self-hosted runners live inside corporate networks with reach to internal services that would otherwise be unreachable from the public internet. |\n| **Resource abuse** | Cryptomining, denial-of-service of the CI infrastructure, bandwidth abuse. |\n| **No audit signal** | The bypassed run row has `approved_by = 0` and `need_approval = false` \u2014 **schema-indistinguishable** from a legitimate trusted-user run. There is no log line, no webhook event, no UI banner stating that the approval gate was *skipped* (only that it wasn\u0027t needed). |\n| **Scope** | Every repository that accepts fork pull requests **and** has Actions enabled. Public OSS projects are most exposed because anyone can open a PR. Internal corporate repos that accept fork PRs from contractors / interns / outside collaborators are equally exposed once a single such PR has been approved historically. |\n| **Defense-in-depth bypass** | The approval gate is the *only* line of defense between untrusted PR YAML and CI execution on regular `pull_request` events. Remaining mitigations \u2014 per-fork-PR `GITEA_TOKEN` scoping (`models/actions/token_permissions.go:54-57`) and secret omission (`models/secret/secret.go:160-165`) \u2014 reduce blast radius but do not prevent code execution. |\n\n---\n\n## 6. Manual reproduction (web UI only, ~10 minutes)\n\nThis procedure uses only the Gitea web interface \u2014 no `curl`, no `git` CLI, no API tokens. It is intended for the maintainer security team to verify the vulnerability on a fresh instance.\n\n### Prerequisites\n\n1. A Gitea instance with **Actions enabled** (`[actions] ENABLED = true` in `app.ini`).\n2. One Actions runner registered and online with the `ubuntu-latest` label (optional \u2014 see note at the end of this section).\n3. Two user accounts:\n   - **`maintainer`** \u2014 will own the target repository.\n   - **`attacker`** \u2014 any unprivileged second account; registered through normal sign-up; no special privileges required.\n4. Two browser sessions: a normal window for `maintainer`, and a private/incognito window for `attacker`. Do not flip between them in the same window.\n\n### Phase 1 \u2014 `maintainer` creates the target repository\n\n1. Log into Gitea as `maintainer`.\n2. Top-right `+` \u2192 **New Repository**.\n3. Owner = `maintainer`, Name = `gate-bypass-poc`, Visibility = Public, \u2611 **Initialize Repository**, Default Branch = `main`. Click **Create Repository**.\n4. On the repo home, click the **+** icon in the file tree \u2192 **New File**.\n5. In the path field type:\n   ```\n   .gitea/workflows/ci.yml\n   ```\n6. Paste the following into the editor \u2014 **`name:` must be at column 0 with no leading whitespace**:\n   ```yaml\n   name: CI\n   on: [pull_request]\n   jobs:\n     test:\n       runs-on: [ubuntu-latest]\n       steps:\n         - name: hello\n           run: echo \"hello from gate-bypass-poc baseline\"\n   ```\n7. Scroll down \u2192 **Commit directly to `main`** \u2192 **Commit Changes**.\n\n### Phase 2 \u2014 `attacker` forks the repository\n\n1. Switch to the `attacker` window. Log in.\n2. Navigate to `\u2026/maintainer/gate-bypass-poc`.\n3. Click **Fork** (top-right). Accept defaults (owner = `attacker`). Click **Fork Repository**.\n\n### Phase 3 \u2014 `attacker` opens a benign PR (PR #1)\n\n1. On `\u2026/attacker/gate-bypass-poc`, click `README.md` \u2192 pencil icon to edit.\n2. Add any innocuous line (e.g. `Small typo fix.`).\n3. Scroll down \u2192 select **Create a new branch for this commit and start a pull request** \u2192 branch name `benign-typo`. Click **Propose File Change**.\n4. On the pre-filled \"Open a new pull request\" form, leave defaults and click **Create Pull Request**.\n5. You should land on `\u2026/maintainer/gate-bypass-poc/pulls/1`.\n\n### Phase 4 \u2014 `maintainer` approves the first run (the one-time trust event)\n\n1. Switch to the `maintainer` window. Open `\u2026/maintainer/gate-bypass-poc/pulls/1`.\n2. Scroll to the status checks section. You will see the yellow banner:\n   \u003e **Workflow runs from fork pull requests need approval to run** [ **Approve and run workflows** ]\n3. **Before clicking**, open a second tab on `\u2026/maintainer/gate-bypass-poc/actions`. The workflow run \"Small typo fix\" should be displayed with status **Blocked**. This is the gate working *correctly* for a first-time contributor.\n4. Return to the PR tab. Click **Approve and run workflows**. The banner disappears; the run transitions to **Waiting** \u2192 **Running** \u2192 **Success** (or stays at Waiting if no runner is online \u2014 irrelevant for the bypass demonstration).\n\n### Phase 5 \u2014 `attacker` opens a second PR (PR #2) with a malicious workflow change\n\n1. Switch back to the `attacker` window.\n2. On `\u2026/attacker/gate-bypass-poc`, navigate to `.gitea/workflows/ci.yml` via the file tree. Click the pencil icon to edit.\n3. **Replace the entire file** with the following (`name:` flush left, no leading whitespace anywhere):\n   ```yaml\n   name: CI\n   on: [pull_request]\n   jobs:\n     test:\n       runs-on: [ubuntu-latest]\n       steps:\n         - name: pwn\n           env:\n             BASE_TOKEN: ${{ github.token }}\n           run: |\n             echo \"===== BYPASS DEMO - this workflow ran WITHOUT approval =====\"\n             echo \"running as: $(id 2\u003e/dev/null || echo n/a)\"\n             echo \"hostname:   $(hostname 2\u003e/dev/null || echo n/a)\"\n             echo \"uname:      $(uname -a 2\u003e/dev/null || echo n/a)\"\n             echo \"GITHUB_TOKEN length = ${#BASE_TOKEN}\"\n             curl -fsS --max-time 5 https://example.com/ -o /dev/null -w \"egress HTTP %{http_code}\\n\" || echo \"(no network)\"\n             ls -la\n             echo \"===== END DEMO =====\"\n   ```\n4. Scroll down \u2192 select **Create a new branch for this commit and start a pull request** \u2192 branch name `bypass-payload`. Click **Propose File Change**.\n5. On the pre-filled PR form, click **Create Pull Request**. You should land on `\u2026/maintainer/gate-bypass-poc/pulls/2`.\n\n### Phase 6 \u2014 Observe the bypass\n\nThis is the critical observation.\n\n1. As `maintainer`, open `\u2026/maintainer/gate-bypass-poc/pulls/2`. **Scroll to the status checks section.**\n   - **Expected if the gate worked:** the same yellow \"Workflow runs from fork pull requests need approval to run\" banner as in Phase 4.\n   - **Actual:** **no banner**. The check appears straight away as pending / running / green. No approval has been requested. `maintainer` was not notified.\n2. As `maintainer`, open `\u2026/maintainer/gate-bypass-poc/actions`. The new run for \"Update .gitea/workflows/ci.yml\" is displayed with status **Waiting** / **Running** / **Success** \u2014 **never `Blocked`**.\n3. Click into the run \u2192 `test` job \u2192 `pwn` step. You will see the payload output (`id`, hostname, uname, token length, outbound HTTPS code, file listing) \u2014 the attacker\u0027s code executed end-to-end without your consent.\n\n### Note on the runner\n\nIf no runner is online and registered with the `ubuntu-latest` label, **the bypass is still proven** by step 1 of Phase 6 (no banner) and step 2 (status `Waiting` instead of `Blocked`). The runner only matters for visualising the payload\u0027s output. The status transition `Blocked \u2192 Waiting` for an unapproved second PR is itself the security signal \u2014 a gated run would remain `Blocked` indefinitely and the dispatcher would never look for a runner.\n\n### Note on the YAML formatting\n\nIf you copy the workflow YAML out of this document into the Gitea web editor and inadvertently keep any leading whitespace before `name:`, Gitea will reject the file with `yaml: line 2: mapping values are not allowed in this context`. No `action_run` row is created in that case (the workflow detector silently skips unparseable files), and the bypass will *look* like it didn\u0027t fire when in fact the code path was never reached. **`name:` must sit at column 0.**\n\n---\n\n## 7. Verifying the bypass in the database\n\nOpen a database shell on the Gitea host. The `action_run` table contains the smoking gun.\n\n### SQLite (default)\n\n```bash\nsqlite3 /var/lib/gitea/data/gitea.db\n```\n\n```sql\nSELECT\n  ar.id,\n  ar.trigger_user_id,\n  ar.need_approval,\n  ar.approved_by,\n  CASE ar.status\n    WHEN 1 THEN \u0027Success\u0027 WHEN 2 THEN \u0027Failure\u0027 WHEN 3 THEN \u0027Cancelled\u0027\n    WHEN 4 THEN \u0027Skipped\u0027 WHEN 5 THEN \u0027Waiting\u0027 WHEN 6 THEN \u0027Running\u0027\n    WHEN 7 THEN \u0027Blocked\u0027 ELSE CAST(ar.status AS TEXT) END AS status,\n  ar.ref\nFROM action_run ar\nJOIN repository r ON r.id = ar.repo_id\nWHERE r.owner_name = \u0027maintainer\u0027 AND r.name = \u0027gate-bypass-poc\u0027\nORDER BY ar.id;\n```\n\nExpected output after Phase 6:\n\n```\nid  trigger_user_id  need_approval  approved_by  status   ref\n--  ---------------  -------------  -----------  -------  ----------------\nN   \u003cattacker uid\u003e   0              \u003cmaint uid\u003e  Success  refs/pull/1/head\nN+1 \u003cattacker uid\u003e   0              0            Success  refs/pull/2/head\n```\n\nThe N+1 row demonstrates the bypass: same trigger user, **never approved** (`approved_by = 0`), yet `need_approval = 0` and executed successfully. This row is schema-indistinguishable from a normal trusted-user run; an audit pipeline scanning the table cannot tell the bypass apart from a legitimate write-permission user\u0027s run.\n\n### PostgreSQL / MySQL\n\nThe same query, against `database_name`, with `\\c gitea` / `USE gitea;` first.\n\n---\n\n\n## 9. Suggested fixes\n\nThree options, in order of preference.\n\n### Option A (recommended) \u2014 Scope approval to the commit, not the user\n\nExtend `FindRunOptions` with a `CommitSHA` predicate (it already exists as the field at `models/actions/run_list.go:70`) and reframe the gate check as *\"has the current PR head SHA been approved by this user\"*.\n\n```diff\n--- a/services/actions/notifier_helper.go\n+++ b/services/actions/notifier_helper.go\n@@\n-    // don\u0027t need approval if the user has been approved before\n-    if count, err := db.Count[actions_model.ActionRun](ctx, actions_model.FindRunOptions{\n-        RepoID:        repo.ID,\n-        TriggerUserID: user.ID,\n-        Approved:      true,\n-    }); err != nil {\n-        return false, fmt.Errorf(\"CountRuns: %w\", err)\n-    } else if count \u003e 0 {\n-        return false, nil\n-    }\n+    // don\u0027t need approval if a prior run for this same PR-head commit was approved\n+    if run.CommitSHA != \"\" {\n+        if count, err := db.Count[actions_model.ActionRun](ctx, actions_model.FindRunOptions{\n+            RepoID:        repo.ID,\n+            TriggerUserID: user.ID,\n+            CommitSHA:     run.CommitSHA,\n+            Approved:      true,\n+        }); err != nil {\n+            return false, fmt.Errorf(\"CountRuns: %w\", err)\n+        } else if count \u003e 0 {\n+            return false, nil\n+        }\n+    }\n```\n\nThis preserves the legitimate UX intent (\"don\u0027t re-prompt on the same PR after a transient runner failure causes a re-run\") without granting trust to future PRs or new commits on the same branch. Every new commit on the PR \u2014 including a force-push that replaces the workflow file \u2014 would re-trigger the gate, exactly as a security-sensitive deployment expects.\n\n### Option B (stricter) \u2014 Require a merged contribution, like GitHub\n\nReplace the \"approved before\" branch with \"has this user had a PR merged in this repo before\":\n\n```go\nif merged, err := issues_model.HasUserMergedPullRequestInRepo(ctx, repo.ID, user.ID); err != nil {\n    return false, fmt.Errorf(\"HasUserMergedPullRequestInRepo: %w\", err)\n} else if merged {\n    return false, nil\n}\n```\n\nThis matches the typical OSS-maintainer mental model: a contributor whose PR has been *merged* is trusted enough to run CI without further approval. *Approving a workflow run is not merging code*; the current logic conflates the two.\n\n----",
  "id": "GHSA-777r-4v59-6486",
  "modified": "2026-07-21T20:35:51Z",
  "published": "2026-07-21T20:35:51Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/go-gitea/gitea/security/advisories/GHSA-777r-4v59-6486"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-58424"
    },
    {
      "type": "WEB",
      "url": "https://github.com/go-gitea/gitea/pull/38010"
    },
    {
      "type": "WEB",
      "url": "https://github.com/go-gitea/gitea/commit/699fe2ef43b9466ac1b0cb857029f91fd5b0056d"
    },
    {
      "type": "WEB",
      "url": "https://github.com/go-gitea/gitea/commit/e107498f3b6fccff35455ef17430ca68df665297"
    },
    {
      "type": "WEB",
      "url": "https://blog.gitea.com/release-of-1.26.3-and-1.26.4"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/go-gitea/gitea"
    },
    {
      "type": "WEB",
      "url": "https://github.com/go-gitea/gitea/releases/tag/v1.26.4"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:L/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Gitea: Permanent Fork PR Workflow Approval Gate Bypass"
}