Spingarbor

Incorrect authorization exists within the `/v2` experimental interface.

Gogs, an open-source self-hosted Git service, contains an access control bypass issue. Repository collaborators with Write permissions can delete protected branches, including the default branch, by sending a direct POST request. This bypasses the branch protection mechanism, enabling privilege escalation from Write to Admin level. The vulnerability exists in the `DeleteBranchPost` function within the `internal/route/repo/branch.go` file, specifically lines 110-155. The web interface deletion operation does not trigger Git Hooks, which correctly prevent protected branch deletion via SSH push. Attackers must have write permissions to the target repository and access to the Gogs web interface to exploit this issue. The vulnerable code lacks checks for protected and default branches, while the UI layer and Git Hooks correctly implement these checks. The vulnerable API endpoint is '/delete/*' and the vulnerable parameter is the branch name.

Gogs, a self-hosted Git service, has a broken access control issue. Authenticated users with write access to a repository can modify labels belonging to other repositories. This is due to a failure in the `UpdateLabel` function within the Web UI (`internal/route/repo/issue.go`) to verify that the label being modified belongs to the correct repository. The issue resides in the Web UI's label update endpoint, `POST /:username/:reponame/labels/edit`, where the `UpdateLabel` handler function uses a database query that bypasses repository ownership validation. Specifically, the function `database.GetLabelByID(f.ID)` is called with `repoID=0`, which ignores repository restrictions. The vulnerability allows for potential disruption of issue classification, concealment of security issues, and sabotage of workflows. The vulnerable code is located in `internal/route/repo/issue.go:1040-1054`. The API endpoint used for exploitation is `/api/v1/labels/edit`. The vulnerable parameter is `id`.

Devtron is a tool integration platform for Kubernetes. A flaw exists in the Attributes API interface that allows authenticated users to obtain the global API Token signing key by accessing the `/orchestrator/attributes?key=apiTokenSecret` endpoint. Obtaining this key enables attackers to forge JWT tokens for arbitrary user identities offline, potentially granting complete control over the Devtron platform and allowing lateral movement to the underlying Kubernetes cluster. The issue was addressed with commit d2b0d26.

The software does not properly validate project ownership when handling organization project operations. This allows a user with project write access in one organization to potentially modify projects belonging to a different organization. This is an IDOR (Insecure Direct Object Reference) issue.

The notification API does not re-validate repository access permissions when providing notification details. Specifically, after a user’s access to a private repository is revoked, they may still be able to view issue and pull request titles through previously received notifications.

The stopwatch API in Gitea does not re-validate repository access permissions. This means that if a user’s access to a private repository is revoked, they may still be able to view issue titles and repository names through previously started stopwatches. The issue affects the ability to control access to repository information after permissions have been changed.

Gitea does not properly verify authorization when canceling scheduled auto-merges through the web interface. A user with read access to pull requests may be able to cancel auto-merges scheduled by other users. This impacts the authorization process for canceling scheduled auto-merges.

Gitea does not correctly validate repository ownership during the deletion of Git LFS locks. This allows a user with write access to a repository to potentially delete LFS locks that belong to other repositories. The issue involves improper validation when deleting Git LFS locks.

An authenticated user may be able to modify the visibility settings of other users' OpenID identities due to improper ownership validation when toggling OpenID URI visibility.

The software does not correctly check ownership of repositories when managing attachments linked to releases. This can lead to a situation where an attachment from a private repository is incorrectly associated with a release in a public repository, potentially exposing the attachment to unauthorized access.

Gitea does not correctly validate the repository context during attachment deletion. A user who uploaded an attachment to a repository might be able to delete it even after losing access to that repository by submitting the request through a different repository they are authorized to access. This occurs because the system fails to properly confirm the user's permission to delete the attachment within the original repository.

Gitea may send release notification emails for private repositories to users whose access has been revoked. This occurs when a repository is changed from public to private, potentially disclosing release titles, tags, and content to users who previously watched the repository.