CVE-2026-110324 in Gitea
Summary
by MITRE • 10/18/2026
The visibility check of Gitea user profiles was applied to GET requests only, while `POST /{username}` (follow and unfollow) required only a signed-in user. Any authenticated user could therefore obtain the full name, location, website and description of a user with a private profile from the response. The issue was fixed in 28.1.0 and disclosed with 28.2.0.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 10/18/2026
The vulnerability described constitutes an information disclosure flaw within Gitea’s user profile visibility logic, specifically affecting how access control is enforced across different HTTP methods for the same resource endpoint. In secure web application design, authorization checks must be consistent regardless of the request method used to interact with a protected resource. However, in this instance, the system applied strict visibility restrictions only to GET requests when retrieving user profile data, while POST requests targeting the follow and unfollow functionality at the path `/{username}` bypassed these same privacy constraints. This architectural inconsistency allowed any authenticated user to indirectly access sensitive personal information belonging to users who had explicitly configured their profiles as private.
Technically, the flaw arises from a failure in implementing uniform authorization policies across related operations on the same resource. While the GET endpoint correctly checked whether the requesting user was authorized to view the profile data of the target user based on privacy settings, the POST endpoint responsible for managing follow relationships did not perform an equivalent check before processing the request or returning its response. As a result, when an authenticated user attempted to follow or unfollow another user with a private profile, the server processed the action but also returned metadata associated with that user in the HTTP response body. This included sensitive fields such as full name, location, website URL, and personal description, which should have been withheld from unauthorized viewers according to the target user’s privacy preferences.
The operational impact of this vulnerability is significant for organizations relying on Gitea for private repository management or internal collaboration where employee identity information must remain confidential. An attacker with a valid account in the same instance could enumerate users and harvest their personal details without triggering standard security alerts associated with direct profile viewing attempts. This capability facilitates social engineering attacks, targeted phishing campaigns, or reconnaissance activities that aid further exploitation of other vulnerabilities within the platform. The ability to gather such intelligence undermines trust in the system’s privacy controls and exposes individuals to potential harassment or identity theft depending on the sensitivity of the disclosed data.
This issue aligns with CWE-200: Information Exposure, as it involves the unintended leakage of sensitive information through an API endpoint that was not properly secured against unauthorized access. Additionally, from a threat modeling perspective consistent with MITRE ATT&CK frameworks, this behavior supports reconnaissance activities categorized under T1592: Gather Victim Host Information or more broadly within initial access and discovery phases where attackers collect user profiles to build targeted attack vectors. The vulnerability highlights the importance of ensuring that all API endpoints handling sensitive resources enforce identical authorization checks regardless of whether they are used for data retrieval or state-changing operations like following users.
Mitigation strategies primarily involve applying the patch released in version 28.1.0, which corrects the authorization logic to ensure that privacy settings are respected across both GET and POST methods when interacting with user profiles. Organizations running affected versions should upgrade immediately to prevent further exposure of private profile data. In addition to upgrading, administrators can implement web application firewall rules or custom middleware checks to validate that any response containing personal identifiable information is only returned if the requesting user has explicit permission to view it. Regular security audits focusing on authorization consistency across different HTTP methods for shared resources are recommended to detect similar architectural flaws before they can be exploited by malicious actors seeking to gather intelligence within internal networks.