Description

Froxlor 2.3.10 and earlier contain a time-of-check time-of-use (TOCTOU) race condition in the SSH key synchronization cron (lib/Froxlor/Cron/System/SshKeys.php, SshKeys::generateFiles). The containment/symlink validation performed by FileDir::makeCorrectDir()/makeCorrectFile() is done only at check time; the live filesystem path is re-resolved as root at write time (file_put_contents with FILE_APPEND|LOCK_EX, followed by chmod/chown/chgrp), with a database round-trip and file reads in between, and no path or file-descriptor pinning (no O_NOFOLLOW or openat2(RESOLVE_NO_SYMLINKS)). On installations where the non-default setting system.allow_customer_shell=1 grants customers local shell access, a customer can atomically swap their ~/.ssh directory for a symlink after the check and before the write, causing the root-run cron to append the customer's public key to /root/.ssh/authorized_keys and to chown /root/.ssh to the customer, resulting in full root compromise of the panel host. The cron re-runs on every interval, allowing unlimited attempts. This is a residual race that bypasses the check-time fix introduced for GHSA-mq5v-... . The issue is fixed in Froxlor 2.3.12.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.8",
  "pubDate": "2026-09-26T14:16:57.067Z",
  "pubdate": "2026-09-26T14:16:57.067Z",
  "executiveSummary": "Froxlor versions 2.3.10 and earlier are susceptible to a critical Time-of-Check Time-of-Use (TOCTOU) race condition within the SSH key synchronization cron job.\nThe vulnerability resides in the SshKeys::generateFiles method, where path validation is decoupled from the subsequent file write and permission operations. Because the system performs validation checks and then re-resolves the filesystem path during execution as a root-privileged process, a local attacker with shell access can perform an atomic symlink swap.\nBy manipulating the filesystem state between the validation check and the file operation, an authenticated user can influence the cron job to manipulate sensitive system files, such as /root/.ssh/authorized_keys.\nThis allows a low-privileged customer to achieve full root compromise of the hosting panel. The exploit is particularly dangerous because the cron job runs repeatedly, providing an attacker with unlimited attempts to win the race condition. Exploitation requires the non-default system.allow_customer_shell=1 configuration to be enabled, providing the attacker with the necessary local shell environment to stage the race.",
  "technicalDetails": "The root cause of this vulnerability is an insecure implementation of filesystem operations within the Froxlor SSH synchronization logic (lib/Froxlor/Cron/System/SshKeys.php). Specifically, the SshKeys::generateFiles function relies on FileDir::makeCorrectDir() and makeCorrectFile() for containment and symlink validation. However, these checks occur strictly at the 'check time' phase.\nThe flaw manifests because the subsequent write operations—utilizing file_put_contents with FILE_APPEND|LOCK_EX, followed by chmod, chown, and chgrp—operate on paths that are re-resolved as root. There is no usage of file-descriptor pinning, O_NOFOLLOW flags, or secure path resolution mechanisms like openat2(RESOLVE_NO_SYMLINKS). A significant time window exists between the validation check and the execution, exacerbated by database round-trips and file read operations performed by the cron script.\nThe attack flow follows a precise exploitation pattern: 1) The attacker, possessing shell access via the enabled system.allow_customer_shell setting, monitors the execution cycle of the SSH key sync cron. 2) The attacker places a legitimate directory or file structure at the target path to pass the initial validation check. 3) Immediately following the validation check but prior to the execution of file_put_contents, the attacker atomically swaps the target directory with a symbolic link pointing to /root/.ssh/. 4) When the root-privileged cron process continues, it traverses the attacker-controlled symlink, resulting in the injection of the attacker's public key into /root/.ssh/authorized_keys. 5) The cron process then inadvertently performs a chown on the symlinked target, granting the attacker ownership of the root SSH directory.\nThis vulnerability effectively bypasses previous security patches (specifically those related to GHSA-mq5v-...) because it addresses the residual race condition inherent in the lack of atomic filesystem handling. The impact is a full, persistent root compromise of the panel host, as the attacker can subsequently authenticate via SSH as the root user. Since the cron task executes periodically, the attacker is afforded an unlimited window of opportunity to successfully execute the race condition, making the exploitation window highly reliable in local environments."
}