Summary
Jpom contains an authorization bypass in its SSH file management controller that allows an authenticated workspace user to reference SSH assets belonging to another workspace. When the user has SSH file permissions in their own workspace, supplying a foreign asset identifier may enable unauthorized file access, modification, or deletion on the other workspace's host.
Jpom contains an authorization bypass in its SSH file management controller that allows an authenticated workspace user to reference SSH assets belonging to another workspace. When the user has SSH file permissions in their own workspace, supplying a foreign asset identifier may enable unauthorized file access, modification, or deletion on the other workspace's host.
Affected context
The issue occurs in Jpom deployments where SSH file operations rely on a user-supplied asset identifier without sufficiently verifying that the referenced SSH host belongs to the user's workspace. Affected operations include file download, upload, reading, updating, deletion, renaming, and directory creation. Exploitability depends on the attacker being an authenticated workspace user with access to applicable SSH file-management endpoints.
The issue occurs in Jpom deployments where SSH file operations rely on a user-supplied asset identifier without sufficiently verifying that the referenced SSH host belongs to the user's workspace. Affected operations include file download, upload, reading, updating, deletion, renaming, and directory creation. Exploitability depends on the attacker being an authenticated workspace user with access to applicable SSH file-management endpoints.
Exploit preconditions
- Attack surface: Jpom SSH file-management API endpoints
- Required access: An authenticated account with SSH file permissions in at least one workspace
- Trigger point: Supplying an SSH asset identifier associated with another workspace to file operation endpoints
- Why exploitation is possible: Authorization checks may validate the user's general file-management permission without binding the requested asset to the user's authorized workspace
- Attack surface: Jpom SSH file-management API endpoints
- Required access: An authenticated account with SSH file permissions in at least one workspace
- Trigger point: Supplying an SSH asset identifier associated with another workspace to file operation endpoints
- Why exploitation is possible: Authorization checks may validate the user's general file-management permission without binding the requested asset to the user's authorized workspace
Why this happens
The vulnerability is an object-level authorization failure mapped to CWE-639: Authorization Bypass Through User-Controlled Key. The application accepts a client-controlled SSH asset identifier and uses it to select a host, but does not consistently enforce ownership or workspace membership for that object. This creates an insecure direct object reference pattern in which possession of a valid identifier can cross an authorization boundary.
The vulnerability is an object-level authorization failure mapped to CWE-639: Authorization Bypass Through User-Controlled Key. The application accepts a client-controlled SSH asset identifier and uses it to select a host, but does not consistently enforce ownership or workspace membership for that object. This creates an insecure direct object reference pattern in which possession of a valid identifier can cross an authorization boundary.
Potential impact
- Unauthorized users may read files from SSH hosts assigned to other workspaces
- Attackers could upload or modify files on hosts outside their authorized workspace
- Sensitive configuration, credentials, or application data may be exposed
- Files or directories could be deleted, renamed, or replaced
- Compromised files could support operational disruption or further host compromise
- Unauthorized users may read files from SSH hosts assigned to other workspaces
- Attackers could upload or modify files on hosts outside their authorized workspace
- Sensitive configuration, credentials, or application data may be exposed
- Files or directories could be deleted, renamed, or replaced
- Compromised files could support operational disruption or further host compromise
General mitigation guidance
Mitigation should focus on enforcing server-side, object-level authorization for every SSH file operation.
Common defensive patterns include:
- Resolve the requested SSH asset on the server and verify workspace ownership before performing any action
- Derive authorization context from the authenticated session rather than trusting workspace or asset identifiers supplied by the client
- Apply consistent authorization checks across download, upload, read, update, delete, rename, and directory-creation operations
- Use deny-by-default policies and least-privilege service credentials for SSH access
- Reduce the sensitivity of stored SSH credentials and isolate workspaces where practical
- Return generic authorization failures without exposing whether foreign asset identifiers exist
Mitigation should focus on enforcing server-side, object-level authorization for every SSH file operation.
Common defensive patterns include:
- Resolve the requested SSH asset on the server and verify workspace ownership before performing any action
- Derive authorization context from the authenticated session rather than trusting workspace or asset identifiers supplied by the client
- Apply consistent authorization checks across download, upload, read, update, delete, rename, and directory-creation operations
- Use deny-by-default policies and least-privilege service credentials for SSH access
- Reduce the sensitivity of stored SSH credentials and isolate workspaces where practical
- Return generic authorization failures without exposing whether foreign asset identifiers exist
How teams detect issues like this
Organizations can look for this class of issue through:
- Static analysis rules that identify database or service lookups using client-controlled object identifiers without nearby authorization checks
- Code review signals such as workspace or tenant checks performed only at the UI layer or only on selected endpoints
- API tests that attempt to reuse valid object identifiers across users, projects, or workspaces
- Access-log monitoring for repeated requests involving asset identifiers outside the caller's normal workspace
- Policy enforcement requiring centralized object-level authorization middleware for multi-tenant APIs
Automated security testing and code review tools may help identify inconsistent authorization coverage.
Organizations can look for this class of issue through:
- Static analysis rules that identify database or service lookups using client-controlled object identifiers without nearby authorization checks
- Code review signals such as workspace or tenant checks performed only at the UI layer or only on selected endpoints
- API tests that attempt to reuse valid object identifiers across users, projects, or workspaces
- Access-log monitoring for repeated requests involving asset identifiers outside the caller's normal workspace
- Policy enforcement requiring centralized object-level authorization middleware for multi-tenant APIs
Automated security testing and code review tools may help identify inconsistent authorization coverage.
