CVE-2026-111638 in sshportal
Summary
by MITRE • 10/16/2026
sshportal through 1.19.5 contains a missing authorization vulnerability in the management shell 'key show' command that allows authenticated non-admin users to obtain decrypted backend private SSH keys. Attackers can request predictable key names like 'default' or 'host' to retrieve private keys and connect directly to backend hosts, bypassing ACLs and session recording.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 10/16/2026
The vulnerability identified in sshportal versions through 1.19.5 represents a critical failure in access control mechanisms within the management shell interface. Specifically, this flaw resides in the 'key show' command functionality, which is intended to display public SSH keys associated with backend hosts for administrative purposes. However, due to insufficient authorization checks, authenticated users who do not possess administrator privileges are able to execute this command and retrieve sensitive cryptographic material. This misconfiguration allows non-administrative actors to bypass the intended role-based access control policies that should restrict such operations exclusively to privileged accounts responsible for infrastructure management.
From a technical perspective, the core issue is a missing authorization check rather than an input validation error or buffer overflow. The application fails to verify whether the requesting user has the necessary permissions before processing the request to decrypt and return private SSH keys. This oversight enables attackers who have obtained valid credentials through phishing, credential stuffing, or other means of authentication bypass to interact with the management shell as if they were system administrators. By leveraging predictable key names such as 'default' or 'host', which are commonly used defaults in many sshportal deployments, an attacker can systematically request and retrieve private keys without needing prior knowledge of specific host configurations beyond these standard identifiers.
The operational impact of this vulnerability is severe, fundamentally compromising the security model provided by sshportal. Private SSH keys serve as long-term authentication credentials for accessing backend servers. Once obtained, these keys allow attackers to establish direct shell access to any backend host associated with the compromised key pair. This direct access effectively circumvents all layers of protection implemented within the proxy environment, including Access Control Lists that restrict which users can connect to specific hosts and session recording features designed for audit trails and forensic analysis. Consequently, an attacker gains persistent, undetected foothold inside the internal network infrastructure, potentially leading to lateral movement, data exfiltration, or further compromise of critical systems.
This vulnerability aligns with CWE-269, which describes Improper Privilege Management, as it involves a failure to enforce proper authorization levels for sensitive operations. Furthermore, from an adversary perspective, this technique corresponds to the ATT&CK tactic of Initial Access via Valid Accounts and specifically relates to techniques involving credential harvesting or abuse of existing valid credentials to gain unauthorized access. The ability to retrieve private keys also touches upon CWE-321, Use of a Key Past its Expiration Date, in contexts where key rotation is not enforced, though the primary classification remains an authorization bypass.
Mitigation strategies must prioritize immediate remediation through software updates and strict configuration reviews. Organizations running sshportal should upgrade to version 1.19.6 or later, where this authorization flaw has been addressed by developers implementing proper role-based access controls for all management shell commands. In the interim, if upgrading is not immediately feasible, administrators should restrict network access to the sshportal management interface exclusively to trusted IP addresses and ensure that only highly privileged personnel have accounts with administrative rights. Additionally, enforcing strong password policies and multi-factor authentication can reduce the risk of initial credential compromise. Regular audits of user permissions and disabling unnecessary features in the management shell further harden the environment against exploitation by non-administrative users seeking to escalate privileges or extract sensitive cryptographic material.