Jpom EUVD-2026-103027

Requires an authenticated Jpom account in any workspace that holds SSH file permissions (CVSS PR:L), plus a multi-workspace deployment containing SSH host assets in workspaces other than the attacker's. The attacker must know or enumerate the SSH asset id of a foreign workspace, which is supplied as the user-controlled key to the SshFileController endpoints; no special non-default configuration or user interaction is needed beyond standard multi-workspace use. Limiting factors: the account and SSH-file permission requirement (not remote-unauthenticated), reliance on multiple workspaces existing, and affected versions being 2.11.12 or earlier.

This is a genuine authorization flaw (CWE-639, IDOR) in Jpom's SshFileController affecting versions through 2.11.12, reported by VulnCheck with a public technical write-up. The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:N) scoring 8.6 is internally consistent with the description: network-reachable HTTP endpoints, low attack complexity, and a low-privilege authenticated workspace user as the only barrier. The key mitigating signal is PR:L - exploitation requires a valid, authenticated account with SSH file permissions in at least one workspace, so this is an insider/multi-tenant trust-boundary issue rather than a remote-unauthenticated breach. No EPSS probability score was provided in the input and the CVE is NOT on the CISA KEV list, so there is no evidence of active exploitation; a detailed public proof-of-concept write-up (hackmd) with exact endpoint names and source-line references does exist, which materially lowers the barrier to weaponization. Net assessment: a real, high-severity priority for any organization running Jpom with multiple workspaces and shared/untrusted workspace users, but the authentication requirement and the product's limited deployment footprint make widespread opportunistic exploitation less likely than the raw 8.6 score alone would imply. Note the VA:N/A:N impact rating is debatable given the description explicitly includes file deletion, which can affect availability - verify integrity-vs-availability scoring against the hosted files' role.

An attacker holds a legitimate low-privilege account in one Jpom workspace with SSH file permissions. By supplying an SSH asset id belonging to a different workspace to endpoints such as download, upload, read_file_data.json, update_file_data.json, delete.json, rename.json or new_file_folder.json, they bypass the workspace authorization check and read, modify, or delete files on SSH hosts owned by other workspaces. A public proof-of-concept write-up detailing the vulnerable endpoints and code path exists, lowering the effort required.