The vulnerability arises because Gitea validates a push mirror's remote address only when the mirror is created. During each synchronization, the stored address is passed directly to "git push", so a name that later resolves to a blocked or internal address is still reached. An administrator who can configure mirrors can target internal Git services and force‑push their repository contents to them. This effectively allows the attacker to write arbitrary data and can lead to remote code execution on the internal service. The flaw demonstrates input validation and SSRF weaknesses, corresponding to CWE‑367 and CWE‑918.

All Gitea releases prior to 28.0.0 are affected. The issue was fixed in the 28.0.0 release, as indicated by the referenced blog post and release notes. Administrators using earlier Gitea versions should verify their mirror configurations accordingly.

The EPSS score of 0.00118 indicates a very low but nonzero probability of exploitation and the vulnerability is not listed in the CISA KEV catalog, suggesting no publicly known exploitation yet. However, the flaw requires only a user with administrative rights on a repository, a role typically granted to trusted developers. Once that permission is held, the attack path is straightforward: create or modify a mirror to point at an internal Git server, and trigger a synchronization. The ability to force‑push to internal hosts presents a high potential for data tampering and the execution of malicious code. The CVSS score of 8.1 indicates a high level of risk.