CVE-2026-120460 in Jpom
Summary
by MITRE • 11/02/2026
Jpom through 2.11.12 contains a cross-workspace authorization bypass vulnerability that allows authenticated users to manage other workspaces' Docker hosts by supplying foreign Docker asset ids. Attackers with Docker permission in any workspace can control containers, images, volumes and networks, including creating privileged containers with host bind mounts.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 11/02/2026
The Jpom application version 2.11.12 and earlier contains a critical cross-workspace authorization bypass vulnerability that fundamentally undermines the isolation mechanisms designed to separate distinct operational environments within the platform. This flaw allows authenticated users who possess Docker management permissions in one specific workspace to execute commands against Docker hosts associated with entirely different, unrelated workspaces by supplying foreign asset identifiers. The core technical failure lies in the application's insufficient validation of resource ownership during API requests related to container orchestration operations. When a user initiates an action such as starting, stopping, or configuring a Docker host, the backend logic fails to verify that the target workspace ID associated with the requested Docker asset matches the context of the authenticated session and its assigned permissions. Instead, the system relies on the provided identifier without cross-referencing it against strict access control lists or ownership records tied to the user's current workspace scope. This lack of server-side authorization checks enables an attacker to manipulate resource identifiers from other tenants or departments within the same Jpom instance, effectively bypassing logical separation controls that are intended to prevent lateral movement and unauthorized access across organizational boundaries.
The operational impact of this vulnerability is severe due to the high-privilege nature of Docker host management capabilities available through the interface. An attacker who exploits this flaw can gain full control over containers, images, volumes, and networks belonging to other workspaces. This includes the ability to create privileged containers that have access to the underlying host operating system via bind mounts. By leveraging these elevated privileges, an adversary can potentially escape container isolation entirely, gaining root-level access to the host machine where Jpom is deployed. Such a scenario facilitates data exfiltration from sensitive environments, modification or destruction of critical infrastructure configurations, and further lateral movement within the network. The ability to manipulate images also allows for the introduction of malicious software into shared registries or deployment pipelines used by other teams, compromising integrity across multiple projects. This represents a significant breach of confidentiality, integrity, and availability principles, particularly in multi-tenant environments where strict isolation is required for compliance and security purposes.
From a classification perspective, this vulnerability aligns with CWE-284 Improper Access Control, specifically reflecting failures in authorization logic that allow users to access resources belonging to other entities. It also maps directly to MITRE ATT&CK technique T1078 Valid Accounts, as the exploitation requires valid authentication credentials but abuses them to perform unauthorized actions across workspace boundaries. Furthermore, the capability to create privileged containers with host bind mounts relates to container escape techniques often associated with privilege escalation vectors in cloud-native environments. To mitigate this risk, immediate patching of Jpom to a version later than 2.11.12 is essential as it addresses these authorization checks. In addition to upgrading, administrators should enforce strict role-based access control policies that limit Docker host management permissions only to users who explicitly require them for their specific workspace tasks. Implementing network segmentation between workspaces where possible and auditing API logs for anomalous cross-workspace resource accesses can provide additional layers of defense. Regular security assessments focusing on logical access controls are recommended to ensure that future updates maintain robust isolation boundaries between distinct operational units within the platform.