CVE-2026-89430: Gitea push mirror SSRF and forced writes to internal Git hosts
Gitea validated a push mirror's remote address against the [migrations] allow and block lists only when the mirror was created. Each synchronization passed the stored address directly to git push, so a name that later resolved to a blocked or internal address was still reached. A user with administrator access to a repository, which includes repositories they create themselves, could aim push mirror synchronization at internal Git services and force-push the repository's contents to them.
Affected Software
Event History
Frequently Asked Questions
Who can exploit this issue?
An attacker needs administrator access to a repository. This includes users who can create their own repositories and therefore have administrator access to them.
What access does the vulnerable instance need for exploitation to have impact?
The Gitea server must be able to reach the targeted internal Git service. The issue can then be used to direct push mirror synchronization to that service and force-push repository contents.
Are the migration allow and block lists sufficient protection?
No. They were checked when a push mirror was created, but not during later synchronizations. A previously allowed hostname that later resolves to a blocked or internal address can still be reached during synchronization.
How could an administrator identify potentially affected mirrors?
Review existing push mirrors, particularly those using hostnames whose DNS resolution may have changed after mirror creation. Mirrors targeting names that now resolve to internal or blocked addresses are relevant.