Jpom Authorization Flaw Lets Users Steal Files Across Workspaces

Jpom versions through 2.11.12 contain an authorization bypass vulnerability that allows authenticated users to access SSH hosts belonging to other workspaces. According to the National Vulnerability Database, the flaw enables users with SSH file permissions to manipulate files on other workspaces' SSH hosts by supplying foreign asset identifiers.

What happened

The vulnerability, tracked as CVE-2026-111605, resides in the SshFileController component of the Jpom platform. According to the NVD record, the issue is classified as a high-severity flaw with a CVSS score of 8.6. It is described as an authorization bypass vulnerability that allows authenticated workspace users to access SSH hosts belonging to other workspaces.

An attacker who has obtained valid credentials for any workspace can exploit this weakness. By supplying foreign SSH asset IDs in API requests, the user can target resources in other workspaces. The NVD description notes that the flaw applies to Jpom releases up to and including version 2.11.12.

Why it matters

Workspace isolation is a fundamental security control in multi-tenant management platforms. When that boundary fails, a single compromised account can expose the entire infrastructure managed by the application. According to the source material, the weakness allows for full file operations, including reading, modifying, and deleting data on remote hosts.

This type of authorization bypass undermines trust in the platform's access controls. Security teams must assume that any user with SSH file permissions can potentially pivot to other workspaces. The ability to rename, create, or delete folders on foreign hosts expands the attack surface beyond simple data theft to include disruption of remote services.

Our take on the response

• Verify the installed version of Jpom against the affected range (through 2.11.12).
• Audit SSH asset access logs for requests originating from users who do not own the target assets.
• Review API endpoint activity for the specific file manipulation functions listed in the NVD record.
• Ensure that workspace permissions are strictly enforced and that no legacy accounts have elevated SSH rights.

What defenders should look for

Teams usually detect this activity by monitoring for anomalous API requests to file management endpoints. Check whether users are accessing SSH assets that do not belong to their designated workspace. Look for sequences of read, write, or delete operations on foreign hosts that deviate from normal user behavior. Investigate logs for requests containing SSH asset IDs that match other workspaces. Containment moves often involve temporarily restricting SSH file permissions or isolating the affected user accounts while the platform is updated.

What to do and how to stay safe: Jpom

• Inventory all Jpom instances and confirm their version numbers to determine if they fall within the affected range.
• Monitor server logs for API calls to SshFileController endpoints, specifically checking for mismatched user and asset IDs.
• Restrict SSH file permissions to the principle of least privilege until a vendor update is available.
• Review access patterns for any authenticated users who have recently interacted with multiple workspace environments.

Step-by-step guide: Vulnerability Management Myths That Waste Your Time and Budget

General security guidance from the NetSec Tribune newsroom. It is not confirmed advice from the organisations named in this story.

Frequently asked questions

Which versions of Jpom are affected by CVE-2026-111605?

The vulnerability affects Jpom versions through 2.11.12, according to the NVD record.

What is the severity rating of this vulnerability?

The NVD rates the flaw as HIGH with a CVSS score of 8.6.

What actions can an attacker take using this flaw?

Attackers can read, modify, delete, rename, and create files on SSH hosts belonging to other workspaces.