Jpom EUVD-2026-115220

Requires a valid Jpom account that holds Docker permission in at least one workspace on a multi-workspace (multi-tenant) server; the attacker then supplies a Docker asset id belonging to a different workspace to the Docker container, image, network, or swarm controllers, which prior to the patch resolved the host via dockerInfoService.getByKey(id) without checking workspace ownership. The key limiting factors are that the attacker must be authenticated (PR:L, not anonymous) and must have Docker permission somewhere, and that the deployment must manage more than one workspace with at least one Docker host registered in another workspace - a single-workspace or non-Docker deployment is not affected. Full impact (privileged container with host bind mount) further depends on the targeted workspace having a reachable Docker host configured.

This is a credible, promptly-actionable issue rather than an inflated high-CVSS score, but it is not an emergency. The vendor CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H) is internally consistent with the description: a network-reachable, low-complexity flaw that requires an authenticated account (PR:L) with Docker permission in any single workspace, yielding high confidentiality, integrity and availability impact because the attacker gains full control of other workspaces' Docker hosts. The vuln.today decision label is 'this_week', which aligns with a serious-but-not-wormable authorization bypass that still requires a valid low-privileged account. No EPSS score, no CISA KEV listing, and no confirmed working exploit code were supplied, so there is no evidence of active exploitation; the realistic risk is an insider or a compromised low-privilege workspace user pivoting across tenant boundaries. The patch commit is published and the root cause is clearly visible in source (unscoped getByKey(id) calls), which lowers the barrier to developing a reliable exploit, so the gap between 'patch available' and 'likely exploit' is narrow. Net: treat as a real priority for multi-tenant Jpom deployments within the vendor's this_week window, not a drop-everything event.

A user who legitimately holds only Docker permission in one workspace of a shared Jpom server enumerates or guesses the Docker asset id belonging to another workspace and submits it to the Docker container/image/network controllers, which (before the fix) looked up the host by id without validating workspace ownership. Because exploitation is network-based, low-complexity and needs only an existing low-privileged account, the attacker can create a privileged container with a host bind mount on the victim workspace's Docker host and thereby reach the underlying host filesystem. No confirmed working exploit code is published, but a VulnCheck advisory and a GitHub issue describe the flaw and the fix commit reveals the exact vulnerable code paths.