Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessAuthenticate to low-privilege workspace
-
DeliveryEnumerate or guess foreign SSH asset id
-
ExploitCall SSH file endpoint with foreign id
-
ExecutionBypass cross-workspace authorization check
-
ImpactRead, modify or delete files on other workspace hosts
Vulnerability Assessment
| Weakness |
CWE
OWASP Top 10:2025
A01:2025 - Broken Access Control
ASVS 5.0
V8 - Authorization Object-level authorization, IDOR prevention
|
| Exploitation Conditions | 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. |
| Impact | 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. |
| Exploit ScenarioDerived | 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. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Oct 16, 2026
Cross-workspace authorization bypass in Jpom through 2.11.12 (CWE-639, IDOR) lets any authenticated user who holds SSH file permissions in one workspace read, modify, or delete files on SSH hosts that belong to a different workspace. The flaw resides in SshFileController, where the caller-supplied SSH asset id is used to resolve the target host without verifying that the asset actually belongs to the caller's workspace, so the reachable endpoints (download, upload, read_file_data.json, update_file_data.json, delete.json, rename.json, new_file_folder.json) operate on foreign assets. Exploitation requires a multi-workspace deployment with at least one SSH host asset outside the attacker's workspace and knowledge or enumeration of that host's asset id; no public exploit code is confirmed at time of analysis, though a public technical write-up (linked from the CVE record) explains the technique, and the issue is not listed in CISA KEV, so there is no evidence of active exploitation. Assigned CVSS 4.0 base 8.6 (with our 3.1 assessment at AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N) reflects high confidentiality and integrity impact while the CVSS 4.0 vector shows no availability impact.
RemediationAI
No vendor-released fixed version was identified in the available data at time of analysis; the flaw is documented as affecting Jpom through 2.11.12, and the referenced code is the vulnerable v2.11.12 SshFileController, so track the upstream project (https://github.com/dromara/Jpom) and the VulnCheck advisory (https://www.vulncheck.com/advisories/jpom-through-2.11.12-cross-workspace-authorization-bypass-via-sshfilecontroller) for a patched release and upgrade as soon as one is published. Until then, apply compensating controls rather than relying on generic hardening: remove or restrict the SSH-related file permissions for non-administrative users so that only fully trusted operators hold them, since the bypass still requires SSH file permissions in at least one workspace (trade-off: reduced self-service file management for regular users); where the permission model cannot be narrowed, deny the affected paths (SshFileController's download, upload, read_file_data.json, update_file_data.json, delete.json, rename.json and new_file_folder.json endpoints) to non-admin roles at the reverse proxy or gateway (trade-off: breaks the SSH file-manager UI entirely for those accounts); run separate Jpom instances per tenant/team instead of a shared multi-workspace instance so no foreign assets exist to target (trade-off: higher operational and licensing overhead); scope the SSH credentials Jpom stores to least privilege - read-only or chrooted accounts where write access is not needed - so a successful bypass cannot modify or delete data (trade-off: some legitimate file operations stop working); and review audit logs for requests to SSH file endpoints whose asset ids fall outside the caller's own workspace, treating any such hit as a compromise indicator. Monitoring is preferable to trying to block by parameter value, because asset ids are typically sequential integers and are not feasible to filter reliably at the perimeter.
Affected VersionsENISA
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 1 package in euvd
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
Jpom (dromara/Jpom) is a Java/Spring-based DevOps and server-management platform whose web console organizes managed servers into isolated workspaces, each holding its own SSH host "assets" identified by numeric ids. SshFileController in modules/server/src/main/java/org/dromara/jpom/controller/ssh/SshFileController.java (lines 44-65 in the tagged v2.11.12 source) exposes file-management operations for those SSH hosts. The root cause is CWE-639 (Authorization Bypass Through User-Controlled Key): the asset id supplied by the caller is treated as a trusted locator and handed directly to the SSH asset/service layer, without an ownership check confirming that the resolved asset belongs to a workspace the caller is a member of. This is a classic IDOR in a multi-tenant design, where workspace boundaries are enforced in the UI and in most controllers but not in this one, so the same session that is legitimate for workspace A can be pointed at the SSH credentials and file tree of workspace B. The CVSS 4.0 vector (VC:H/VI:H/VA:N, SC:N/SI:N/SA:N, PR:L, AT:N) confirms the impact is confined to the target application's data, requires only low-privileged authenticated access, and yields no availability loss - consistent with read/write/delete operations on remote files rather than service disruption. The CPE cpe:2.3:a:dromara:jpom:*:*:*:*:*:*:*:* is version-agnostic, while the description and the fixed-code reference pin affected builds to 2.11.12 and earlier.
Know when Jpom gets its next vulnerability
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N
Network-reachable endpoints with low-privilege authenticated access (PR:L), no user interaction; full read and modify of foreign files gives C:H/I:H, availability unrated to match the supplied VA:N.
Primary rating from Vendor (VulnCheck).
CVSS VectorVendor: VulnCheck
DescriptionCVE.org
Jpom through 2.11.12 contains an authorization bypass vulnerability in SshFileController that allows authenticated workspace users to access SSH hosts belonging to other workspaces by supplying foreign SSH asset ids. Attackers with SSH file permissions in any workspace can call download, upload, read_file_data.json, update_file_data.json, delete.json, rename.json and new_file_folder.json endpoints to read, modify and delete files on other workspaces' SSH hosts.
Executive ViewAI
Organizations running Jpom 2.11.12 or earlier in a multi-workspace configuration are exposed to CVE-2026-111605, a cross-workspace authorization bypass that lets an account holding SSH file permissions in one workspace read, modify, or delete files on SSH hosts assigned to a different workspace. Leadership should care because this breaks the internal segregation model that teams rely on when workspaces are used to separate business units, projects, or customers, turning routine SSH file management into a path for unauthorized data access and destructive change. No vendor-released patch is available at time of analysis, and no public exploit code has been identified at time of analysis, though a public technical write-up describing the technique is referenced from the CVE record.
No vendor-released patch identified at time of analysis. Interim mitigations: remove or minimize SSH file permissions for all accounts that do not require them; reduce the number of workspaces and SSH host assets to eliminate foreign-asset targets; enforce strict network segmentation and IP allowlisting on the Jpom management interface and API; disable or block the affected SSH file endpoints at a reverse proxy if business operations permit; enable verbose audit logging and alerting on SSH asset access where the asset id does not match the caller's workspace; verify and restore file integrity on managed SSH hosts against a known-good baseline; and rotate SSH credentials for all hosts reachable through Jpom.
Threat Intelligence Overview
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Attack Technique
Authentication bypass attacks exploit flaws in the verification mechanisms that control access to systems and applications.
EUVD-2026-103027
GHSA-cr5j-j45g-7pmc
NVD
CVE.org
EPSS
VulDB
Exploit-DB