Repository Contents

Tested Environment

The proof of concept was validated in the following isolated environment:

Successful exploitation produced command output similar to:

Prerequisites

• Python 3.8 or later
• Network access to the target Gitea instance
• A valid Gitea account with repository creation and write permissions, or a target laboratory instance with public registration enabled
• An explicitly authorized test environment

The script uses only Python's standard library and does not require additional packages.

Usage

Example for a local laboratory instance:

The script first attempts web registration, then authenticates with the supplied credentials. This allows the same command to work with either a new account on an instance with open registration or an existing account.

Technical Analysis

The exploitation chain consists of four stages:

1. Attacker-controlled patch submission
   POST /api/v1/repos/{owner}/{repo}/diffpatch applies supplied patch content using git apply --index --recount --cached --binary --ignore-whitespace --whitespace=fix -3 within a temporary clone.

2. Hook path placement
   The temporary repository is created as a bare, shared clone. In a bare repository, the repository root is also $GIT_DIR; consequently, the patch path hooks/post-index-change resolves inside Git's active hooks directory.

3. Executable hook materialization
   The same patch is submitted twice. The second application produces an add/add conflict, causing the three-way fallback to materialize the path on disk with mode 100755, despite the use of --cached. A subsequent index update invokes post-index-change, executing the injected shell code as the Gitea service account.

4. Git-native output retrieval
   The hook identifies the origin repository through objects/info/alternates, stores command output as a Git blob, creates a tree and commit, and updates refs/heads/output-leak. The proof of concept then retrieves the result through Gitea's raw-file API. This technique does not require a direct outbound connection from the target.

Impact

Successful exploitation grants command execution with the privileges of the Gitea service account. Depending on deployment configuration, an attacker may be able to access:

• app.ini and database credentials
• SECRET_KEY, INTERNAL_TOKEN, and LFS-related secrets
• Repositories mounted or readable by the Gitea process
• Process environment variables
• Internal services reachable from the Gitea host or container

The laboratory account was confirmed to have read access to app.ini.

Indicators of Compromise

Defenders should investigate the following artifacts and request patterns:

• Two identical or near-identical requests to /api/v1/repos/*/*/diffpatch in quick succession
• A branch named output-leak
• Commits authored by poc <[email protected]>
• Unexpected executable files named hooks/post-index-change in bare repositories or temporary clone directories
• Suspicious activity below paths such as /data/gitea/tmp/local-repo/upload.git*

These indicators describe the included proof of concept and are not exhaustive; a modified exploit may use different paths, refs, identities, or output channels.

Remediation and Mitigation

1. Upgrade to Gitea 1.27.1 or later. This is the recommended remediation. The fix changes the affected workflow to use a non-bare temporary clone.
2. Restrict the diffpatch API at the reverse proxy until the upgrade is complete, for example by denying access to matching /api/v1/.../diffpatch routes. Validate the rule against legitimate integrations before deployment.
3. Disable public registration by setting DISABLE_REGISTRATION=true if it is not operationally required. This reduces unauthenticated reachability but does not protect against existing users with repository write access.
4. Review logs and repository refs for the indicators above, and rotate credentials or secrets accessible to the Gitea account if compromise is suspected.

For the laboratory container used in this research, teardown can be performed with:

Responsible Use

This material is provided to help defenders reproduce, understand, detect, and remediate the vulnerability. Operators should test only in isolated environments and follow their organization's authorization and disclosure requirements.