CVE-2026-89182 in Gitea
Summary
by MITRE • 10/07/2026
With `[repository] FORCE_PRIVATE = true`, Gitea creates new repositories as private, but the post-receive hook still applied the `repo.private=false` push option to an empty repository created by push. Any user who can create repositories could make their new repository public in violation of the instance policy. The default configuration is not affected.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 10/07/2026
The vulnerability described involves a misconfiguration or logic error within Gitea, specifically related to how it handles repository creation policies and post-receive hooks when FORCE_PRIVATE is set to true. This setting is intended to enforce that all newly created repositories are private by default, aligning with organizational security policies aimed at preventing accidental exposure of sensitive codebases. However, the flaw arises because the post-receive hook continues to apply a push option that explicitly sets repo.private=false for empty repositories being pushed into existence.
This discrepancy allows any user who has permission to create new repositories on the instance to bypass the intended private-by-default policy. By pushing an initial commit or content to a newly created repository, the attacker can trigger the post-receive hook which overrides the FORCE_PRIVATE setting and marks the repository as public. This effectively circumvents administrative controls designed to maintain confidentiality of source code until it is explicitly approved for broader access.
From a technical standpoint, this represents a failure in enforcing security policies at the application level despite configuration-level safeguards being present. The root cause lies in how Gitea processes push events against empty repositories during their initial creation phase. Instead of respecting the global FORCE_PRIVATE directive throughout all stages of repository initialization and modification via hooks, it applies conflicting logic that prioritizes certain push options over administrative settings.
The operational impact of this vulnerability is significant for organizations relying on Gitea to manage proprietary or sensitive software projects. Unauthorized exposure of code can lead to intellectual property theft, competitive disadvantage, regulatory non-compliance if such data includes personally identifiable information or other regulated content, and potential exploitation by malicious actors who gain access to internal systems through exposed repositories.
In terms of industry standards, this issue aligns with CWE-284: Improper Access Control, as it involves a failure to properly restrict actions based on user privileges or organizational policy. Additionally, from an ATT&CK perspective, while not directly mapping to a specific tactic like initial access or execution, the ability to escalate visibility of resources could be considered part of resource development activities where adversaries seek out valuable assets within compromised environments.
Mitigation strategies should focus first on updating Gitea to versions that address this logic flaw in handling repository privacy settings during push operations involving empty repositories. Administrators must ensure they are running patched releases provided by the official Gitea project team responsible for resolving such inconsistencies between configuration directives and actual behavior enforced through hooks.
Until patches can be applied, temporary workarounds might include restricting who has permission to create new repositories or disabling post-receive hooks entirely if feasible within your deployment context without impacting other critical workflows dependent upon them. Regular audits of repository visibility statuses across the platform should also help detect any instances where this vulnerability may have already been exploited before full remediation occurs.
Furthermore, implementing additional layers of control such as network segmentation limiting direct internet-facing exposure of Gitea servers or employing web application firewalls configured to monitor unusual patterns in API calls associated with repo creation and modification could provide supplementary protection against exploitation attempts leveraging this flaw.