CVE-2026-91993 in Jpom
Summary
by MITRE • 09/15/2026
Jpom through 2.11.12 fails to validate workspace ownership when resolving repositoryId on the /build/branch-list endpoint, allowing authenticated users to access repositories from other workspaces. Attackers can submit repository identifiers from different workspaces to enumerate repository existence, determine repository type, and execute git ls-remote commands using other workspaces' stored credentials.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 09/15/2026
The vulnerability identified in Jpom versions through 2.11.12 represents a critical failure in access control mechanisms within the application's build management subsystem. Specifically, the flaw resides in the handling of repository identifiers on the /build/branch-list endpoint. When an authenticated user requests branch information for a specific project or workspace, the backend logic is responsible for verifying that the requesting user has legitimate ownership or appropriate permissions for the specified workspace before proceeding with data retrieval operations. In this vulnerable implementation, the system fails to perform adequate validation of workspace ownership when resolving the repositoryId parameter provided by the client. This oversight allows an authenticated attacker to manipulate the request payload and supply a repository identifier belonging to a different workspace than the one they are authorized to access. By bypassing these authorization checks, the application processes requests intended for isolated environments as if they were part of the current user's context, leading to unauthorized data exposure across organizational boundaries within the CI/CD pipeline infrastructure.
The operational impact of this vulnerability is significant due to the sensitive nature of the information accessible through the compromised endpoint. An attacker can leverage this flaw to enumerate repository existence by submitting various repository identifiers and observing response codes or content differences that indicate whether a target repository exists in another workspace. Beyond mere enumeration, the attacker can determine the type of version control system associated with each repository, which aids in further reconnaissance efforts against the organization's infrastructure. More critically, because Jpom utilizes stored credentials to interact with remote repositories for operations such as fetching branch lists, this vulnerability enables an attacker to execute git ls-remote commands using the credentials configured for other workspaces. This effectively allows the extraction of sensitive metadata from private or restricted projects without direct authentication to those specific resources, potentially revealing internal project structures, codebase organization, and development workflows that should remain confidential.
From a technical classification perspective, this vulnerability aligns with CWE-284 Improper Access Control, as it involves a failure to enforce proper restrictions on authorized actions for unauthorized actors. The ability to access resources belonging to other users or contexts without permission is also characteristic of CWE-639 Authorization Bypass Through User-Controlled Key, where the repository identifier acts as an unvalidated key that grants access to protected data. In terms of offensive security frameworks, this behavior maps directly to ATT&CK technique T1087 Account Discovery and potentially T1528 Steal Application Access Token if the stored credentials are leveraged for further lateral movement or unauthorized API calls. The vulnerability exploits a logical flaw in how session context is maintained during cross-workspace resource resolution, highlighting the importance of strict isolation boundaries in multi-tenant CI/CD platforms where different teams or projects may share the same instance but require distinct security perimeters.
Mitigation strategies must focus on enforcing rigorous identity verification at every step of request processing within the application logic. The primary remediation involves implementing robust authorization checks that validate the relationship between the authenticated user's session and the workspace associated with the requested repositoryId before any backend operations are initiated. Developers should ensure that access control lists or role-based permissions are consulted to confirm that the current user has explicit read access to the target workspace prior to resolving git credentials or querying remote repositories. Additionally, input validation should be applied not only for syntax but also for semantic correctness regarding resource ownership. For organizations currently running vulnerable versions of Jpom, upgrading to a patched version is essential. In the interim, network-level controls such as strict firewall rules limiting access to CI/CD management interfaces and enabling comprehensive audit logging can help detect anomalous patterns indicative of workspace enumeration attempts until the software update is deployed.