Summary
A Gitea push mirror authorization flaw evaluated the repository owner's permissions instead of the requesting user's permissions for local filesystem paths. When local path imports are enabled, a repository administrator with insufficient local-path privileges may direct repository refs into an existing server-side Git repository using the Gitea process's permissions.
A Gitea push mirror authorization flaw evaluated the repository owner's permissions instead of the requesting user's permissions for local filesystem paths. When local path imports are enabled, a repository administrator with insufficient local-path privileges may direct repository refs into an existing server-side Git repository using the Gitea process's permissions.
Affected context
The issue occurs in Gitea instances where [security] IMPORT_LOCAL_PATHS is enabled and the push mirror API accepts local filesystem destinations. Risk depends on a repository administrator being able to configure a mirror while the repository owner has local-path permissions that the requesting administrator does not possess.
The issue occurs in Gitea instances where [security] IMPORT_LOCAL_PATHS is enabled and the push mirror API accepts local filesystem destinations. Risk depends on a repository administrator being able to configure a mirror while the repository owner has local-path permissions that the requesting administrator does not possess.
Exploit preconditions
- Attack surface: Gitea's repository push mirror API
- Required access: Authenticated repository-administrator access, plus the ability to configure push mirrors
- Configuration condition: Local filesystem path imports must be enabled
- Trigger point: Creation or use of a push mirror targeting a local path
- Why exploitation is possible: Authorization is checked against the repository owner rather than the user making the request
- Target condition: The destination must resolve to an existing Git repository accessible to the Gitea process
- Attack surface: Gitea's repository push mirror API
- Required access: Authenticated repository-administrator access, plus the ability to configure push mirrors
- Configuration condition: Local filesystem path imports must be enabled
- Trigger point: Creation or use of a push mirror targeting a local path
- Why exploitation is possible: Authorization is checked against the repository owner rather than the user making the request
- Target condition: The destination must resolve to an existing Git repository accessible to the Gitea process
Why this happens
The underlying bug is an authorization-context mismatch. The push mirror operation used the repository owner's permissions when deciding whether the requesting user could use a local filesystem destination, allowing a user with fewer privileges to inherit authorization from another identity.
This maps to CWE-863: Incorrect Authorization, where access-control decisions do not correctly evaluate the privileges of the actor performing the operation. The insecure pattern is using resource-owner context in place of the authenticated requester's effective permissions.
The underlying bug is an authorization-context mismatch. The push mirror operation used the repository owner's permissions when deciding whether the requesting user could use a local filesystem destination, allowing a user with fewer privileges to inherit authorization from another identity.
This maps to CWE-863: Incorrect Authorization, where access-control decisions do not correctly evaluate the privileges of the actor performing the operation. The insecure pattern is using resource-owner context in place of the authenticated requester's effective permissions.
Potential impact
- Repository references may be written to an unauthorized local Git repository.
- Existing repository data may be modified or overwritten according to Git behavior.
- The Gitea process's filesystem permissions may expose additional write capability.
- Repository integrity, build inputs, or downstream automation may be affected.
- An attacker may create persistence or influence software supply-chain workflows where destination repositories are trusted.
- Repository references may be written to an unauthorized local Git repository.
- Existing repository data may be modified or overwritten according to Git behavior.
- The Gitea process's filesystem permissions may expose additional write capability.
- Repository integrity, build inputs, or downstream automation may be affected.
- An attacker may create persistence or influence software supply-chain workflows where destination repositories are trusted.
General mitigation guidance
Mitigation generally focuses on evaluating authorization against the actual requesting identity for every sensitive operation.
Common defensive patterns include:
- Check local-path permissions using the authenticated requester, not the repository owner or another related principal.
- Keep local filesystem path imports disabled by default unless the operational need is well understood.
- Prefer controlled repository service integrations over arbitrary server-side filesystem destinations.
- Restrict destination paths through allowlists, canonicalization, and containment checks.
- Run the application with least-privilege filesystem access and isolate writable repository storage.
- Apply explicit authorization checks again when the mirror operation executes, rather than relying only on configuration-time checks.
Mitigation generally focuses on evaluating authorization against the actual requesting identity for every sensitive operation.
Common defensive patterns include:
- Check local-path permissions using the authenticated requester, not the repository owner or another related principal.
- Keep local filesystem path imports disabled by default unless the operational need is well understood.
- Prefer controlled repository service integrations over arbitrary server-side filesystem destinations.
- Restrict destination paths through allowlists, canonicalization, and containment checks.
- Run the application with least-privilege filesystem access and isolate writable repository storage.
- Apply explicit authorization checks again when the mirror operation executes, rather than relying only on configuration-time checks.
How teams detect issues like this
Organizations can look for this class of issue through:
- Static analysis and code review checks for authorization decisions based on resource owners instead of the authenticated actor.
- Tests that compare permissions for repository owners, administrators, collaborators, and unrelated users.
- API policy checks covering push-mirror creation, local-path destinations, and configuration changes.
- Audit-log review for newly created or modified mirrors targeting local filesystem paths.
- Monitoring for unexpected writes by the Gitea process to repositories outside approved storage locations.
Automated code review and authorization-testing tools may help identify inconsistent principal handling.
Organizations can look for this class of issue through:
- Static analysis and code review checks for authorization decisions based on resource owners instead of the authenticated actor.
- Tests that compare permissions for repository owners, administrators, collaborators, and unrelated users.
- API policy checks covering push-mirror creation, local-path destinations, and configuration changes.
- Audit-log review for newly created or modified mirrors targeting local filesystem paths.
- Monitoring for unexpected writes by the Gitea process to repositories outside approved storage locations.
Automated code review and authorization-testing tools may help identify inconsistent principal handling.
Sources
| Source | Link |
|---|---|
| blog. | blog.gitea.com/ |
| github. | github.com/ |
| github. | github.com/ |
| github. | github.com/ |
| github. | github.com/ |
