The vulnerability is a privilege escalation in Gitea's LFS handling, originating from incorrect user identity assignment for deploy keys. The analysis began by examining the provided security advisory and release notes, which pointed to a fix in version 1.27.0 related to LFS cross-repo object access. The key commit c7ae28d7a51a07c0973b973de890ce6be5f405d7 was identified through the pull request mentioned in the release notes.
The commit's diff revealed that the core of the vulnerability was patched in services/lfs/server.go within the BatchHandler and UploadHandler functions. The patch removed the call to git_model.LFSObjectAccessible, which was responsible for the flawed cross-repository access check. This check was vulnerable because the user identity (ctx.Doer) it relied on was incorrect.
The root cause was traced back to routers/private/serv.go in the ServCommand function, as detailed in the vulnerability description. By fetching the file content, it was confirmed that this function incorrectly assigns the repository owner's UserID when a deploy key is used for authentication. This incorrect UserID is then embedded in an LFS JWT.
When an attacker uses this JWT, the LFS handlers (BatchHandler, UploadHandler) would treat the request as if it came from the repository owner, granting access to all LFS objects owned by that user across different repositories. The exploit PoC demonstrates this by using a deploy key for one repository to access an LFS object from another private repository owned by the same user.
Therefore, the vulnerable functions are private.ServCommand (which creates the condition) and lfs.BatchHandler/lfs.UploadHandler (which exploit the condition to bypass authorization). These functions would appear in a runtime profile during exploitation.