CVE-2026-91773 in soft-serve
Summary
by MITRE • 09/15/2026
Soft Serve versions 0.7.1 through 0.11.6 fail to scope Git LFS lock queries by repository, allowing authenticated users to read lock metadata from repositories they cannot access. Attackers with write access to any repository can enumerate lock IDs globally to recover locked file paths, usernames, and lock timestamps from private repositories.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 09/15/2026
The vulnerability in Soft Serve versions 0.7.1 through 0.11.6 represents a critical failure in access control logic within the Git Large File Storage (LFS) locking mechanism. This flaw stems from an insufficient scoping of database queries used to retrieve lock metadata, specifically failing to enforce repository-level boundaries when processing requests for lock information. In a properly secured system, any query retrieving data related to locks must be strictly filtered by the identifier of the specific repository in question, ensuring that users can only interact with resources they have explicit permission to access. However, due to this architectural oversight, the application executes global queries against the underlying database without validating whether the requesting user possesses read or write permissions for the target repository. This design defect effectively bypasses standard authentication and authorization checks at the data retrieval layer, creating a significant security gap that undermines the confidentiality guarantees expected in private version control environments.
The operational impact of this vulnerability is severe, particularly for organizations relying on Soft Serve to manage sensitive intellectual property through private repositories. An attacker who has obtained authenticated access with write privileges to even a single public or accessible repository can exploit this flaw to enumerate lock identifiers across all other repositories hosted by the instance. By leveraging these globally visible lock IDs, the attacker can subsequently query specific details associated with those locks, including the file paths of locked files, the usernames of individuals who have placed locks on them, and precise timestamps indicating when those actions occurred. This capability allows for sophisticated reconnaissance activities where an adversary maps out the structure and activity levels of private projects without direct access to their contents. The exposure of lock metadata can reveal development workflows, identify key contributors through username enumeration, and potentially aid in social engineering attacks by providing context about ongoing work or file structures within restricted environments.
From a classification perspective, this vulnerability aligns with CWE-284 Improper Access Control, as the system fails to restrict information access for unauthorized actors. It also relates closely to CWE-601 URL Redirection and other related flaws where input validation is insufficient, though in this case, it specifically manifests as an authorization bypass via improper query scoping. In terms of the MITRE ATT&CK framework, this behavior facilitates Reconnaissance techniques such as Account Enumeration (T1589) and potentially Information Gathering from internal sources if combined with other exploits. The ability to gather metadata about private repositories constitutes a significant breach of confidentiality principles, allowing attackers to build a detailed profile of an organization's development activities based solely on lock state information rather than file content itself.
Mitigation for this issue requires immediate patching to the latest stable version of Soft Serve where the repository scoping logic has been corrected in the Git LFS service layer. Administrators should verify that all queries related to lock metadata include strict filtering by repository ID and user permission levels before returning results. In environments where upgrading is not immediately feasible, network-level controls such as Web Application Firewalls (WAF) can be configured to monitor for anomalous patterns of access requests targeting LFS endpoints from users who do not have corresponding permissions on the referenced repositories. Additionally, implementing strict logging and monitoring alerts for unusual enumeration activities against lock APIs can help detect exploitation attempts in real-time. Regular security audits focusing on authorization logic across all API endpoints are recommended to ensure that similar scoping errors do not exist elsewhere in the application stack.