GHSA-3FWP-P5RJ-2PXF

Vulnerability from github – Published: 2026-06-16 23:41 – Updated: 2026-06-16 23:41
VLAI?
Summary
Gitea: Missing repository-unit authorization on issue-template API endpoints
Details

Summary

Three Gitea API endpoints — GET /repos/{owner}/{repo}/issue_templates, GET /repos/{owner}/{repo}/issue_config and GET /repos/{owner}/{repo}/issue_config/validate — read files from the repository's Code default branch (.gitea/ISSUE_TEMPLATE/* and issue_config.yaml) and return their contents, but are registered without the reqRepoReader(unit.TypeCode) authorization middleware that every sibling Code-tree endpoint in the same route group carries.

A user who has access to a private repository through any single repository unit (for example an organization team granted only the Issues unit, with no Code access) can therefore read the issue-template and issue-config files of that repository's Code tree, which their permission set should not expose.


Root cause

The three endpoints lack the unit guard

routers/api/v1/api.go:1433-1437:

m.Get("/issue_templates", context.ReferencesGitRepo(), repo.GetIssueTemplates)
m.Get("/issue_config", context.ReferencesGitRepo(), repo.GetIssueConfig)
m.Get("/issue_config/validate", context.ReferencesGitRepo(), repo.ValidateIssueConfig)
m.Get("/languages", reqRepoReader(unit.TypeCode), repo.GetLanguages)
m.Get("/licenses", reqRepoReader(unit.TypeCode), repo.GetLicenses)

context.ReferencesGitRepo() only opens the git repository — it performs no permission check. Every other endpoint in this group that reads Code-tree content is guarded with reqRepoReader(unit.TypeCode): /languages, /licenses, /contents/*, /file-contents, and /{ball_type:tarball|zipball|bundle}/* (api.go:1418-1445). The three issue-template endpoints are the only Code-tree readers in the group missing that guard.

The enclosing group runs repoAssignment() (api.go:1446), whose access check is satisfied by HasAnyUnitAccessOrPublicAccess — i.e. access to any unit of the repository is sufficient to pass. Without a per-unit reqRepoReader, the handlers run for a caller who has no Code permission.

The handlers return Code-tree file contents

routers/api/v1/repo/repo.go:

func GetIssueTemplates(ctx *context.APIContext) {                       // :1179
    ret := issue.ParseTemplatesFromDefaultBranch(ctx.Repo.Repository, ctx.Repo.GitRepo)
    ...
    ctx.JSON(http.StatusOK, ret.IssueTemplates)
}

func GetIssueConfig(ctx *context.APIContext) {                          // :1209
    issueConfig, _ := issue.GetTemplateConfigFromDefaultBranch(ctx.Repo.Repository, ctx.Repo.GitRepo)
    ctx.JSON(http.StatusOK, issueConfig)
}

ParseTemplatesFromDefaultBranch / GetTemplateConfigFromDefaultBranch read .gitea/ISSUE_TEMPLATE/* and issue_config.yaml from the default (Code) branch and return them in the JSON response.


Proof of Concept

victim-org/private-repo is a private repository. The attacker is a member of an organization team granted access to that repository through a non-Code unit only (e.g. the Issues unit) — a supported Gitea permission configuration.

GET /api/v1/repos/victim-org/private-repo/issue_templates HTTP/1.1
Host: TARGET
Authorization: token <attacker token>

The response is 200 OK with the parsed contents of the repository's .gitea/ISSUE_TEMPLATE/* files. The same applies to /issue_config. Because the caller lacks the Code unit, every other Code-tree endpoint (/contents, /languages, …) correctly returns 404/403 for the same token — only these three return data.


Impact

A repository collaborator whose granted permissions exclude the Code unit can read the issue-template and issue-config files from the Code default branch of a private repository. The exposure is limited to those specific configuration files (not arbitrary Code-tree content), which is why this is rated low impact. It is nonetheless a unit-level authorization bypass: the endpoints disclose Code-unit content to callers the permission model is meant to exclude.


Suggested fix

Add the same unit guard the sibling endpoints use, in routers/api/v1/api.go:

m.Get("/issue_templates", reqRepoReader(unit.TypeCode), context.ReferencesGitRepo(), repo.GetIssueTemplates)
m.Get("/issue_config", reqRepoReader(unit.TypeCode), context.ReferencesGitRepo(), repo.GetIssueConfig)
m.Get("/issue_config/validate", reqRepoReader(unit.TypeCode), context.ReferencesGitRepo(), repo.ValidateIssueConfig)

(If issue templates are intended to be visible to Issues-unit users for issue creation, reqRepoReader(unit.TypeIssues) is the appropriate guard — but the current absence of any unit guard is the bug.)


References

  • CWE-862 Missing Authorization
  • CWE-284 Improper Access Control
  • OWASP A01:2021 Broken Access Control
Show details on source website

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 1.26.1"
      },
      "package": {
        "ecosystem": "Go",
        "name": "code.gitea.io/gitea"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.26.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-27783"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-862"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-06-16T23:41:42Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "## Summary\n\nThree Gitea API endpoints \u2014 `GET /repos/{owner}/{repo}/issue_templates`,\n`GET /repos/{owner}/{repo}/issue_config` and `GET /repos/{owner}/{repo}/issue_config/validate`\n\u2014 read files from the repository\u0027s **Code** default branch (`.gitea/ISSUE_TEMPLATE/*`\nand `issue_config.yaml`) and return their contents, but are registered **without**\nthe `reqRepoReader(unit.TypeCode)` authorization middleware that every sibling\nCode-tree endpoint in the same route group carries.\n\nA user who has access to a private repository through *any single repository unit*\n(for example an organization team granted only the **Issues** unit, with no Code\naccess) can therefore read the issue-template and issue-config files of that\nrepository\u0027s Code tree, which their permission set should not expose.\n\n---\n\n## Root cause\n\n### The three endpoints lack the unit guard\n\n`routers/api/v1/api.go:1433-1437`:\n\n    m.Get(\"/issue_templates\", context.ReferencesGitRepo(), repo.GetIssueTemplates)\n    m.Get(\"/issue_config\", context.ReferencesGitRepo(), repo.GetIssueConfig)\n    m.Get(\"/issue_config/validate\", context.ReferencesGitRepo(), repo.ValidateIssueConfig)\n    m.Get(\"/languages\", reqRepoReader(unit.TypeCode), repo.GetLanguages)\n    m.Get(\"/licenses\", reqRepoReader(unit.TypeCode), repo.GetLicenses)\n\n`context.ReferencesGitRepo()` only opens the git repository \u2014 it performs no\npermission check. Every other endpoint in this group that reads Code-tree content\nis guarded with `reqRepoReader(unit.TypeCode)`: `/languages`, `/licenses`,\n`/contents/*`, `/file-contents`, and `/{ball_type:tarball|zipball|bundle}/*`\n(api.go:1418-1445). The three issue-template endpoints are the only Code-tree\nreaders in the group missing that guard.\n\nThe enclosing group runs `repoAssignment()` (api.go:1446), whose access check is\nsatisfied by `HasAnyUnitAccessOrPublicAccess` \u2014 i.e. access to **any** unit of the\nrepository is sufficient to pass. Without a per-unit `reqRepoReader`, the handlers\nrun for a caller who has no Code permission.\n\n### The handlers return Code-tree file contents\n\n`routers/api/v1/repo/repo.go`:\n\n    func GetIssueTemplates(ctx *context.APIContext) {                       // :1179\n        ret := issue.ParseTemplatesFromDefaultBranch(ctx.Repo.Repository, ctx.Repo.GitRepo)\n        ...\n        ctx.JSON(http.StatusOK, ret.IssueTemplates)\n    }\n\n    func GetIssueConfig(ctx *context.APIContext) {                          // :1209\n        issueConfig, _ := issue.GetTemplateConfigFromDefaultBranch(ctx.Repo.Repository, ctx.Repo.GitRepo)\n        ctx.JSON(http.StatusOK, issueConfig)\n    }\n\n`ParseTemplatesFromDefaultBranch` / `GetTemplateConfigFromDefaultBranch` read\n`.gitea/ISSUE_TEMPLATE/*` and `issue_config.yaml` from the default (Code) branch\nand return them in the JSON response.\n\n---\n\n## Proof of Concept\n\n`victim-org/private-repo` is a private repository. The attacker is a member of an\norganization team granted access to that repository through a non-Code unit only\n(e.g. the Issues unit) \u2014 a supported Gitea permission configuration.\n\n    GET /api/v1/repos/victim-org/private-repo/issue_templates HTTP/1.1\n    Host: TARGET\n    Authorization: token \u003cattacker token\u003e\n\nThe response is `200 OK` with the parsed contents of the repository\u0027s\n`.gitea/ISSUE_TEMPLATE/*` files. The same applies to `/issue_config`. Because the\ncaller lacks the Code unit, every other Code-tree endpoint\n(`/contents`, `/languages`, \u2026) correctly returns `404`/`403` for the same token \u2014\nonly these three return data.\n\n---\n\n## Impact\n\nA repository collaborator whose granted permissions exclude the Code unit can read\nthe issue-template and issue-config files from the Code default branch of a private\nrepository. The exposure is limited to those specific configuration files (not\narbitrary Code-tree content), which is why this is rated low impact. It is\nnonetheless a unit-level authorization bypass: the endpoints disclose Code-unit\ncontent to callers the permission model is meant to exclude.\n\n---\n\n## Suggested fix\n\nAdd the same unit guard the sibling endpoints use, in `routers/api/v1/api.go`:\n\n    m.Get(\"/issue_templates\", reqRepoReader(unit.TypeCode), context.ReferencesGitRepo(), repo.GetIssueTemplates)\n    m.Get(\"/issue_config\", reqRepoReader(unit.TypeCode), context.ReferencesGitRepo(), repo.GetIssueConfig)\n    m.Get(\"/issue_config/validate\", reqRepoReader(unit.TypeCode), context.ReferencesGitRepo(), repo.ValidateIssueConfig)\n\n(If issue templates are intended to be visible to Issues-unit users for issue\ncreation, `reqRepoReader(unit.TypeIssues)` is the appropriate guard \u2014 but the\ncurrent absence of any unit guard is the bug.)\n\n---\n\n## References\n\n- CWE-862 Missing Authorization\n- CWE-284 Improper Access Control\n- OWASP A01:2021 Broken Access Control",
  "id": "GHSA-3fwp-p5rj-2pxf",
  "modified": "2026-06-16T23:41:42Z",
  "published": "2026-06-16T23:41:42Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/go-gitea/gitea/security/advisories/GHSA-3fwp-p5rj-2pxf"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/go-gitea/gitea"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Gitea: Missing repository-unit authorization on issue-template API endpoints"
}


Log in or create an account to share your comment.




Tags
Taxonomy of the tags.


Loading…

Loading…

Loading…

Sightings

Author Source Type Date

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…