CVE-2026-119533 in Gitea
Summary
by MITRE • 11/01/2026
Repository and organization project boards listed the pull requests that reference each issue on the board without checking whether the viewer can read them. When a private pull request mentions an issue on a board the viewer can open, the board revealed the private repository's path and the pull request's number, title and state, to anonymous visitors in the case of a public board. The pull request body, diff and files were not exposed. Boards now skip linked pull requests in repositories where the viewer cannot read pull requests.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 11/01/2026
This vulnerability represents an authorization bypass within GitHub’s project management interface, specifically affecting how repository and organization-level boards display information about associated work items. The core technical flaw lies in a failure to perform adequate access control checks when rendering linked entities on board views. When a user creates or edits a project board that includes issues from various repositories, the system aggregates metadata regarding pull requests that reference those issues. In this flawed implementation, the application logic retrieves and displays details about these pull requests without verifying whether the current viewer possesses sufficient permissions to access the underlying repository content. This oversight allows information leakage where sensitive data is exposed to users who should not have visibility into it based on their role or authentication status within the organization.
The operational impact of this vulnerability centers on the unauthorized disclosure of private repository metadata and pull request details. Specifically, when a private pull request references an issue that is visible on a public project board, the board interface reveals the path to the private repository along with specific attributes of the pull request, including its number, title, and current state. This exposure occurs even for anonymous visitors if the board itself is configured as public, although it also affects authenticated users who lack read access to the source code or issues within that private repository. While the vulnerability does not result in the direct exfiltration of sensitive code changes, such as pull request bodies, diffs, or file contents, the disclosure of structural metadata can still be detrimental. Attackers can use this information for reconnaissance purposes, gaining insight into internal development workflows, identifying active projects, and mapping out the organizational structure without needing explicit access to the source code repositories themselves.
From a classification perspective, this issue aligns with CWE-200, which defines exposure of sensitive information to an unauthorized actor, as well as CWE-862, representing missing authorization checks in critical logic paths. In terms of adversary tactics, this behavior facilitates reconnaissance activities consistent with the MITRE ATT&CK technique T1593, specifically gathering victim identity and infrastructure details through active scanning or passive observation of public-facing assets. The vulnerability highlights a common pitfall in web application development where UI components are rendered based on aggregate data sets without applying granular permission filters to each individual element within that set. This leads to situations where the visibility rules for one entity, such as an issue, incorrectly apply to related entities like pull requests, which may reside in repositories with stricter access controls.
Mitigation strategies implemented by the platform involve enforcing strict authorization checks at the point of data retrieval and rendering. The fix ensures that when a board displays linked pull requests associated with visible issues, the system verifies whether the viewer has read permissions for each specific repository containing those pull requests. If the user lacks the necessary access rights to view the contents of a private repository, the corresponding pull request information is omitted from the board display entirely. This approach restores the principle of least privilege by ensuring that users only see data they are explicitly authorized to access. For organizations relying on public project boards for transparency or collaboration, it is crucial to audit existing configurations and ensure that sensitive internal work items do not inadvertently link to private repositories in ways that could expose metadata through these board interfaces. Regular security reviews of permission models across integrated tools can help prevent similar authorization bypasses in other collaborative platforms.