Adrian-Doyensec

An issue exists when registration is enabled and the `[oauth2 client].ACCOUNT LINKING` setting is configured as `auto`. The link-account sign-up form identifies existing accounts to link based on the username or email provided in the form rather than the identity verified by the OAuth2 provider. This allows an attacker with a valid account on a configured OAuth2 provider to submit another user's name, link their external identity to that account, and gain unauthorized access without a password, potentially including administrative privileges. This link remains active for subsequent logins.

An insufficient authorization issue exists in the LFS server where the system uses the `UserID` embedded in an LFS JWT to make cross-repository authorization decisions via the `LFSObjectAccessible()` function. When a deploy key is used for authentication, the system incorrectly sets the `UserID` to the repository owner's ID instead of an identity representing the deploy key. This allows an attacker with a write deploy key for any single repository owned by a victim to obtain a JWT that impersonates the victim. Consequently, the attacker can exfiltrate LFS objects from any private repository the victim owns, provided the attacker knows the SHA-256 OID of the target object. If the victim is a site administrator, all LFS objects on the Gitea instance may be accessible. The issue is reachable via the SSH `git-lfs-authenticate` command and the HTTP LFS batch API endpoint `/info/lfs/objects/batch` when `LFS START SERVER` is enabled.

The software caches a branch-specific write-permission result across multiple refs during a single pre-receive hook session. This behavior allows a user with a per-branch maintainer-edit grant to reuse that permission for other refs, leading to an escalation of privileges to full repository write access.