Cassianstarck

**Name of the Vulnerable Software and Affected Versions** Gitea version 1.26.2 **Description** RSS and Atom feed handlers fail to enforce token-scope or public-only restrictions when using API-token Basic authentication. This allows a personal access token that is restricted to public-only access or lacks the `repository` scope to access private content, provided the account owning the token has legitimate read access to the repository. This is a token-confinement bypass that exposes private commit metadata (SHA, full message, author name, and email), private release names, notes, descriptions, private tag names, and the token owner's private activity stream. **API Endpoints:** - `/{owner}/{repo}.rss` and `/{owner}/{repo}.atom` - `/{owner}/{repo}/rss/branch/*` and `/{owner}/{repo}/atom/branch/*` - `/{owner}/{repo}/releases.rss` and `/{owner}/{repo}/releases.atom` - `/{owner}/{repo}/tags.rss` and `/{owner}/{repo}/tags.atom` - `/{user}.rss` and `/{user}.atom` **Recommendations** For Gitea version 1.26.2, implement a token-scope check in the `ShowBranchFeed`, `ShowRepoFeed`, `ShowFileFeed`, and `ShowReleaseFeed` handlers to ensure tokens are not public-only and possess the required scopes. Additionally, restrict the `includePrivate` logic in the user feed handler to prevent confined tokens from accessing private activity streams.

**Name of the Vulnerable Software and Affected Versions** Gitea version 1.26.2 **Description** A confidentiality breach exists where an attacker-controlled fork pull-request workflow can gain read access to a third private repository. This occurs because the `GetActionsUserRepoPermission()` function in `models/perm/access/repo permission.go` fails to implement a fork pull-request guard in the collaborative-owner logic branch. While other access paths correctly deny access to fork pull-requests, this specific branch allows a task token to obtain `maxPerm` (code-read) if the target repository B trusts the owner of the base repository A as a collaborative owner, provided that repository A is private. Technical details include: - **API Endpoints:** `/userb/repoB.git/info/refs?service=git-upload-pack` (used during git-HTTP cloning). - **Vulnerable Parameters or Variables:** `task.IsForkPullRequest` is not checked in the collaborative-owner branch. - **Function Names:** `GetActionsUserRepoPermission()` **Recommendations** Update Gitea to a version where the `GetActionsUserRepoPermission()` function is patched to include the `!task.IsForkPullRequest` guard within the collaborative-owner check to ensure fork pull-requests are denied cross-repo access.

**Name of the Vulnerable Software and Affected Versions** Gitea versions prior to 1.26.4 **Description** An authenticated user can use a specific API endpoint as a cross-repository label-ID existence and enumeration oracle. This occurs because the system performs a global, unscoped lookup of labels by ID and fails to verify if the label belongs to the repository or organization specified in the request. While no label names, colors, or owning repositories are disclosed, and no unauthorized writes occur, an attacker can determine if a label ID exists anywhere on the instance based on the HTTP response status: a 204 No Content response indicates the label ID exists, while a 422 response indicates it does not. This allows for the enumeration of the instance-wide label population, including labels in private repositories and organizations the user cannot access. **API Endpoint:** `DELETE /repos/{owner}/{repo}/issues/{index}/labels/{id}` **Vulnerable Parameter:** `id` **Recommendations** At the moment, there is no information about a newer version that contains a fix for this vulnerability.