Gitea Repository Visibility Manipulation via Git Push Options (CWE-284)

Vulnerability Overview Vulnerability Name: Repository Visibility Manipulation via Git Push Options Vulnerability Description: Gitea's post-receive git hook processor handles git push options (key-value pairs transmitted via the flag). Two undocumented push options, and , allow any user with repository owner or admin collaborator permissions to switch the repository's visibility (private/public) and template status as a side effect during a normal git push. This functionality was originally intended only for the "push-to-create" feature (automatically creating a repository on the first push), but these options are processed without restrictions on existing repositories. Crucially, visibility changes bypass all controls, leading to missing trigger mechanisms for appropriate setting changes. CVSS v3.1 Score: 7.1 CWE: CWE-284: Improper Access Control Affected File: Affected Function: Affected Lines: 173-225 Prerequisites: The attacker must possess owner-level or admin collaborator access permissions to the target repository. Impact Data Leakage: Private source code, CI/CD keys stored in plaintext files, and environment configurations become publicly cloneable when the repository is made public. No Audit Trail: suppresses changes; no activity log entries are generated; no webhooks are triggered; no notifications are sent. Supply Chain: Combined with , an attacker can silently rotate the repository's template status, affecting all downstream repositories generated from that template. Scope: Affects all repositories for which the attacker has admin collaborator access—not limited to repositories they own. Remediation Option 1 (Recommended) — Completely remove these options from the post-receive hook Option 2 — Route visibility changes through the full visibility change service to trigger audit events, webhooks, and team synchronization Where triggers repository webhook events and writes activity log entries. Exploit Code Attack Scenarios Scenario A — Insider Threat / Rogue Admin Collaborator An organization grants a contractor admin access to a private repository containing proprietary source code. The contractor makes their repository public, making it accessible to the public for a few minutes—enough time to clone, archive, or index the content—and then makes it private again. This operation leaves an audit trail indistinguishable from normal git pushes. Scenario B — Supply Chain Template Poisoning A repository marked as a template is used in a CI/CD pipeline to generate new project repositories. An admin collaborator silently removes the template designation using , makes changes to the repository content, re-marks it as a template, and waits for downstream consumers to regenerate projects from the new backdoored template. The timestamp is not updated due to , making diff detection more difficult. Step-by-Step Reproduction Prerequisites A Gitea user account with owner or admin collaborator access to a private repository. A git client with push access to the repository. Step 1 — Confirm the target repository is private Step 2 — Clone the repository Step 3 — Make any commit (push options take effect on a real push) Step 4 — Execute the exploit push Step 5 — Verify the repository is now public Step 6 — Restore and cover tracks Revert it to private in the same session, leaving no visible audit trail. The repository activity feed shows only two normal push events. The visibility change is invisible. Verification: Confirm no activity log entries exist.

Goal Reached Thanks to every supporter — we hit 100%!

Gitea Repository Visibility Manipulation via Git Push Options (CWE-284)

More from this source