CVE-2026-109844 in Giteainfo

Summary

by MITRE • 10/18/2026

`GET /api/v1/user/subscriptions` returned the metadata of every repository a user was watching without checking that the user still had access to it. A user who watched a private repository while having access, and later lost it, for example through a team permission downgrade, could still read its name, description, clone URLs, owner and counters. The issue was fixed in 1.27.0 and 28.0.0 and disclosed with 28.2.0.

If you want to get best quality of vulnerability data, you may have to visit VulDB.

Analysis

by VulDB Data Team • 10/19/2026

The vulnerability identified involves an authorization bypass within the API endpoint GET /api/v1/user/subscriptions, which is designed to return metadata for repositories that a user has explicitly chosen to watch or monitor. The core technical flaw lies in the server-side logic failing to perform real-time access control verification against the current state of repository permissions before returning sensitive data. Instead of validating whether the authenticated user retains active read access at the moment of the request, the system relies on historical subscription records that may no longer reflect valid permission sets. This architectural oversight allows a user who previously had legitimate access to a private repository and subsequently lost it due to factors such as team membership removal or direct permission downgrades to still retrieve detailed metadata about that repository through this endpoint.

The operational impact of this flaw is significant, particularly regarding the confidentiality of proprietary information within private repositories. Although the vulnerability does not grant access to source code files directly via this specific API call, it exposes critical intelligence including the repository name, description, clone URLs, owner identity, and various counters such as star or fork counts. For organizations relying on strict isolation between teams or projects, this leakage can facilitate reconnaissance activities by adversaries who have compromised a user account with diminished privileges but retain historical subscription links. The exposure of clone URLs is particularly concerning as it provides direct pathways to the repository infrastructure, potentially aiding in further exploitation attempts if other vulnerabilities exist within the deployment environment.

From an industry standards perspective, this vulnerability aligns closely with CWE-284 Improper Access Control and CWE-601 URL Redirection to Untrusted Site or similar misconfigurations where access decisions are not dynamically validated against current entitlements. In terms of attack vectors, it relates to ATT&CK technique T1539 Steal Web Session Cookie if the subscription data is used for session hijacking contexts, but more accurately fits within information gathering phases such as T1087 Account Discovery or T1602 Data from Configuration Repositories where an attacker uses legitimate credentials to extract sensitive metadata. The failure represents a classic case of inconsistent authorization checks across different API endpoints and resource states.

Mitigation strategies must focus on implementing strict, real-time access control verification for all data retrieval operations involving private resources. Developers should ensure that every request to fetch repository metadata performs a secondary check against the current permission matrix associated with the authenticated user's account context before returning any results. This includes verifying team memberships and direct access rights at the time of query execution rather than relying on cached or historical subscription states. Additionally, implementing comprehensive logging and monitoring for unusual patterns in subscription data retrieval can help detect potential exploitation attempts early. The issue was addressed in versions 1.27.0 and 28.0.0 with full disclosure occurring in version 28.2.0, emphasizing the importance of timely patching to prevent exposure during the window between vulnerability discovery and remediation deployment.

Responsible

Gitea

Reservation

10/14/2026

Disclosure

10/18/2026

Moderation

accepted

EPSS

0.00000

KEV

no

Activities

medium

Sources

Do you need the next level of professionalism?

Upgrade your account now!