CVE-2026-90767 in Froxlor
Summary
by MITRE • 09/13/2026
Froxlor before 2.3.12 fails to properly validate multi-line SSH public keys in the SshKeys::add() endpoint, allowing customers to inject arbitrary lines into authorized_keys files. Attackers can inject malicious SSH key entries with option directives to gain persistent unauthorized access that survives key deletion and SSH access revocation.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 09/13/2026
The vulnerability identified in Froxlor versions prior to 2.3.12 represents a critical input validation failure within the SshKeys::add() endpoint, specifically concerning the handling of multi-line SSH public keys. This flaw stems from an insufficient sanitization process that fails to properly parse and validate the structure of SSH key data submitted by users. In standard operational contexts, SSH public keys are typically single lines containing a key type, base64-encoded key material, and an optional comment field. However, the application's logic incorrectly assumes or processes multi-line inputs in a manner that allows for structural manipulation. When a user submits a key entry that contains newline characters interspersed within what is intended to be a single public key string, the backend processing mechanism does not strictly enforce line boundaries as expected by the underlying SSH authentication subsystem. Instead, it treats these newlines as valid delimiters or ignores them in a way that permits additional text segments to be appended directly into the authorized_keys file without proper isolation from legitimate key entries.
This technical flaw enables an attacker who has access to the Froxlor web interface with customer-level privileges to inject arbitrary lines into the system's SSH configuration files. The impact is severe because it allows for the insertion of malicious SSH public keys that include specific option directives, such as command restrictions or environment variable settings. By crafting a multi-line payload where one line contains a legitimate-looking key fragment and subsequent lines contain additional authorized entries, an attacker can effectively bypass standard access controls. These injected entries are written directly to the user's authorized_keys file on the server side. Consequently, even if the original malicious entry is deleted through the Froxlor interface or if SSH access for that specific customer account is revoked via the control panel, the previously injected key remains in the underlying system configuration files. This persistence mechanism ensures that unauthorized access can be re-established at any time by using the pre-injected keys, effectively creating a backdoor that survives administrative remediation attempts within the application layer.
From an operational security perspective, this vulnerability facilitates persistent unauthorized remote shell access and potential lateral movement across systems managed by Froxlor. An attacker leveraging this flaw does not need to exploit server-level vulnerabilities or guess passwords; they only require valid customer credentials for a single account on the platform. Once inside, the ability to inject keys with option directives allows for further exploitation, such as restricting commands to specific actions while maintaining access, or setting up environment variables that could aid in subsequent attacks against other services running under the same user context. This aligns closely with CWE-798, which describes the use of hardcoded credentials or persistent unauthorized access mechanisms, and specifically relates to improper input validation leading to configuration file manipulation. In terms of the MITRE ATT&CK framework, this behavior maps to T1053 - Scheduled Task/Job, as it involves modifying system configurations for persistence, and potentially T1078 - Valid Accounts if the attacker uses legitimate credentials to perform the injection.
To mitigate this vulnerability, administrators must upgrade Froxlor to version 2.3.12 or later immediately upon availability, as these versions include patches that enforce strict validation of SSH key formats. The updated code ensures that only single-line public keys are accepted and properly sanitized before being written to authorized_keys files. Until the patch is applied, a temporary workaround involves manually inspecting user-specific authorized_keys files for unexpected multi-line entries or unauthorized key additions. Additionally, implementing file integrity monitoring on these configuration directories can help detect such injections in real-time. It is also recommended to review SSH server configurations to ensure that AllowUsers or AllowGroups directives are used alongside public key authentication to provide an additional layer of access control independent of the authorized_keys file contents. Regular audits of user accounts and their associated system permissions should be conducted to identify any signs of compromise resulting from this vulnerability, including checking for unknown processes or network connections originating from compromised customer accounts.