Description

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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "4.3",
  "pubDate": "2026-09-15T12:17:54.640Z",
  "pubdate": "2026-09-15T12:17:54.640Z",
  "executiveSummary": "Jpom through version 2.11.12 suffers from a critical broken access control vulnerability within its workspace management logic. The issue resides in the /build/branch-list endpoint, where the application fails to perform authorization checks to verify if an authenticated user possesses the appropriate permissions for a requested repositoryId belonging to a different workspace.\nThis vulnerability allows an authenticated attacker to perform unauthorized cross-workspace operations. By manipulating the repository identifier, an attacker can enumerate repository existence, fingerprint repository types, and abuse stored credentials associated with foreign workspaces to execute git ls-remote commands. The risk is significant, as it enables lateral information disclosure and unauthorized interaction with external version control systems configured by other users or administrators within the Jpom instance. Successful exploitation requires an authenticated session, but no elevated administrative privileges are necessary, effectively lowering the barrier for internal threat actors or compromised accounts to expand their footprint.",
  "technicalDetails": "The vulnerability is categorized as an Insecure Direct Object Reference (IDOR) or a broken access control flaw located in the build management module of Jpom, specifically within the /build/branch-list endpoint. The root cause is the lack of server-side validation concerning workspace ownership when processing incoming requests containing a repositoryId parameter.\nUnder normal operating conditions, Jpom is designed to enforce workspace isolation, ensuring that users can only interact with repositories explicitly associated with their assigned workspace. However, the implementation of the /build/branch-list endpoint fails to validate that the provided repositoryId corresponds to the workspace context of the authenticated user session. Because the application logic trusts the user-supplied input without verifying ownership, it retrieves the configuration, credentials, and metadata associated with the target repository regardless of its actual workspace residency.\nThe attack flow proceeds as follows: First, an authenticated attacker identifies a valid repositoryId associated with a different workspace, perhaps through previous information disclosure or incremental guessing. Second, the attacker sends a crafted request to the /build/branch-list endpoint, injecting the unauthorized repositoryId as a parameter. Third, the backend server processes the request, locates the repository configuration globally rather than scoping it to the user's workspace, and proceeds to execute Git-related operations, specifically 'git ls-remote'.\nThe impact of this behavior is twofold. Primarily, it facilitates unauthorized resource enumeration and reconnaissance, allowing the attacker to confirm the existence and type of repositories they should not have access to. Secondarily, because Jpom caches or manages credentials for these repositories, the attacker can force the system to perform 'git ls-remote' operations using the victim's credentials. This allows the attacker to reach external Git providers (such as GitHub, GitLab, or private Gitea instances) using the hijacked credentials, potentially leading to the disclosure of branch names, commit hashes, or further unauthorized interaction with the underlying version control infrastructure. The vulnerability affects all Jpom instances running versions up to and including 2.11.12, requiring immediate remediation to enforce proper session-to-workspace binding at the controller level."
}