CVE-2026-111605 is a High severity (CVSS 8.1) authorization bypass in Jpom through 2.11.12. Users with SSH file permission in one workspace can act on SSH hosts that belong to other workspaces. We could not confirm a fixed version, so restrict that permission and check the project.
What's affected
The record says Jpom through 2.11.12 is affected. The researcher write-up says it confirmed the issue at the v2.11.12 tag, and that earlier 2.11.x versions are plausibly affected but unconfirmed. We found no fixed release, so check the dromara/Jpom repository.
The weakness is CWE-639, authorization bypass through a user-controlled key. Per the write-up, Jpom separates resources by workspace, but the SSH file controller looks up an SSH asset by its ID alone, and applies no workspace check. A user supplies another workspace's SSH asset ID.
The record lists the endpoints involved: download, upload, read and update file data, delete, rename and new file or folder. Through them, a user can read, change and delete files on SSH hosts of other workspaces. Severity differs by source. The record gives 8.1 (High), and VulnCheck lists 8.6 on a CVSS 4.0 vector. Both are High.
How to check if you're exposed
Check which Jpom version you run, in the web interface or on the server.
docker image ls | grep -i jpom
Version 2.11.12 and earlier are in range per the record. Then review your workspaces and users. The flaw needs an authenticated user who holds SSH file permission in any workspace. List the people who hold it, especially in multi-team installations where workspaces separate teams or customers.
Check SSH host logs for file operations that came from the Jpom server's key at times when no one on the owning team was working. The free in-browser dependency scan at gold.safeguard.sh/scan can match a manifest or lockfile against known CVEs without installing anything.
What to do now
- Check the project for a fixed release and upgrade after you confirm it.
- Remove the SSH file permission from users who do not need it, particularly in installations that share Jpom between teams.
- Use separate Jpom instances for groups that must not see each other's hosts.
- Limit what the SSH account used by Jpom can reach on each host, with a low privilege user and restricted directories.
- Review file change logs on managed hosts and rotate SSH keys if you see activity you cannot explain.
Why it matters
Multi-tenant tools rely on one rule: every lookup is scoped by the tenant. When one overload fetches by key alone, the isolation disappears for the feature that uses it. A permission annotation on the class gives a feeling of control, but the data access still has to apply the scope.
The result reaches beyond Jpom. SSH hosts hold deployment targets, so file read and write on them can affect running services. The record does not mark this CVE as known exploited, and none of the pages we read say it is.
Quick check
What permission does the attacker need?
An authenticated account with SSH file permissions in any workspace, according to the record.
Which versions are confirmed?
Version 2.11.12 is confirmed by the write-up. Earlier 2.11.x versions are plausibly affected but unconfirmed.
Sources
Last reviewed: 18 October 2026.
