CVE-2026-111638 is a high severity (CVSS 7.7) missing authorization flaw in sshportal through 1.19.5. A signed in non-admin user can run the management shell command key show and read decrypted backend private SSH keys. The record names no fixed version, so restrict who can reach the shell and rotate keys.
What's affected
sshportal 1.19.5 and earlier, per the record and the VulnCheck advisory. The weakness is in the management shell's key show command, which does not check that the caller is an administrator before returning key material. I could not confirm a fixed release from the pages I fetched, so check the project's releases and issue tracker before you rely on one.
The exposure is largest where sshportal fronts many backend hosts and ordinary users have accounts on the bastion. Those users are the people the flaw lets read keys they were never meant to see.
Scoring note: the record's 7.7 is a CVSS 3.1 base score. VulnCheck's advisory also lists 8.3 under CVSS 4.0. Both describe the same flaw, and the two versions weigh the factors differently.
How to check if you're exposed
Confirm the version of the bastion you run. If you deploy from a container image or a release binary, read the tag or run the binary's version output.
Then list who has accounts. Any account that is not an administrator can use the affected command on a vulnerable build. Review your key inventory too, because the record says attackers can ask for predictable key names such as default or host.
Check backend host logs for SSH logins that did not pass through the bastion. The record says stolen keys let someone connect directly, bypassing ACLs and session recording, so the bastion's own logs will not show those sessions.
What to do now
- Identify every sshportal instance and its version.
- Treat all backend private keys managed by a vulnerable instance as exposed to every non-admin user.
- Rotate those keys on the backend hosts and replace them in sshportal.
- Restrict backend SSH so it accepts connections only from the bastion's address.
- Reduce non-admin accounts to those that need them while you wait for a fix.
- Watch the project's releases for a patch and upgrade when one is confirmed.
- Scan your dependencies with the free in-browser scan and look the CVE up in the Gold directory to see where else it appears.
Do not stop at one host. Write down every place the affected software runs, including test servers, forgotten containers and copies bundled inside other products. Then rank them by exposure: anything reachable from the internet comes first, internal systems next. A short inventory now saves hours when the next advisory lands.
Why it matters
This is CWE-862, missing authorization. The command checks that you are logged in but not that you are allowed to read the key. The result is a privilege escalation across a trust boundary: a low-privilege account turns into direct access to every host the key opens.
The impact goes past one key. A bastion exists so access is mediated, logged and recorded. A leaked private key lets someone skip all three. The record does not list the flaw in the CISA KEV catalog.
Quick check
Does an attacker need admin rights?
No. The record says an authenticated non-admin user is enough.
Is rotating keys enough?
It removes the stolen credential, but the flaw stays until a patched build is running. Rotate and restrict access together.
Sources
Last reviewed: 18 October 2026.
