Ohxorud-Dev

An issue exists in the cross-repository blob mount process where the target package is validated against the `public-only` restriction of a token, but the source blob is only checked against the full account permissions of the token owner. An attacker using a `public-only` token with `write:package` scope can mount a blob from a private package into a public package namespace, provided the token owner has read access to the private package and write access to the public one. This allows private blobs, such as container layers, to be accessed and downloaded by any user via the public package.

Gitea allows a token with `public-only,write:repository` restrictions to update a private pull request head branch. This occurs because the system validates the token's public-only restriction against the public base repository route but fails to re-apply this restriction to the private head repository during the update process. Consequently, an attacker with such a token can cause Gitea to push commits from a public base repository into a private head branch, bypassing the intended access limitations. Technical details include: - **API Endpoint:** `POST /api/v1/repos/{public-owner}/{public-repo}/pulls/{index}/update` - **Vulnerable Function:** `UpdatePullRequest()` If Gitea Actions is enabled on the private head repository, this unauthorized push can also trigger the execution of private repository `push` workflows.

A privilege escalation issue exists in the API endpoint `POST /users/{username}/tokens` used for creating Personal Access Tokens. The endpoint is protected by the `reqBasicOrRevProxyAuth` middleware, which is designed to require password-based authentication to prevent a compromised token from being used to generate new ones. However, if a token is provided in the `Authorization: Basic <token>:x-oauth-basic` format, the system incorrectly sets the `AuthedMethod` to `basic` and `IsBasicAuth` to `true`, bypassing the middleware guard. Once the guard is bypassed, the `CreateAccessToken` function fails to enforce a scope ceiling, meaning it does not verify if the requested scopes are a subset of the caller's current scopes. Consequently, an attacker possessing a restricted token (such as one with only `write:user` permissions) can create a new token with the `all` scope, granting full administrative access to the account without knowing the user's password.

In the Git Smart HTTP path, the system fails to enforce repository-scoped access-token permissions when tokens are provided via Bearer authentication. While the `CheckRepoScopedToken()` function is designed to validate scopes, it returns early if the request is not using HTTP Basic authentication. Consequently, a Personal Access Token (PAT) or OAuth2 token sent as `Authorization: Bearer <token>` bypasses scope checks entirely. This allows a token with limited permissions (for example, only `read:notification`) to perform operations such as cloning or fetching private repositories without the `read:repository` scope, or pushing to repositories without the `write:repository` scope, provided the token owner has the necessary repository RBAC permissions. The issue affects the `CheckRepoScopedToken()` function and impacts Git Smart HTTP routes.