GHSA-gcv3-5v9q-fmhh: Froxlor has an authorization bypass in FTP shell assignment via missing server-side `available_shells` enforcement
SummaryFroxlor 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.DetailsThe 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:The request handler forwards posted form data directly into the FTP API command implementation: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`:The validated shell is stored into `ftp_users.shell` and later consumed by the root-owned cron task that rebuilds NSS extrausers files: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.PoCAn 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` integrationFroxlor requires a valid CSRF token for POST requests, so the attacker performs the exploit from an authenticated session.Complete PoC flow:Log in as a customer and obtain a valid `csrf_token`.Identify one FTP account owned by that customer.Submit an edit request that sets an arbitrary shell outside the administrator-approved `system.available_shells` list: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 shellthe attacker can then authenticate to the host using that FTP user's credentials and obtain an interactive shellImpactThis 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.
CVSS v4.0: 8.6
CVSS v3.1: 8.8