CVE-2026-41235

Summary

Summary Froxlor 2.3.6 lets administrators configure system.availableshells 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.availableshells, 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.availableshells: The validated shell is stored into ftpusers.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. PoC An attacker needs a normal customer account and a deployment where customer shell delegation is enabled for that customer. Relevant runtime prerequisites: system.allowcustomershell=1 the attacking customer has shellallowed=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: Log in as a customer and obtain a valid csrftoken. Identify one FTP account owned by that customer. Submit an edit request that sets an arbitrary shell outside the administrator-approved system.availableshells list: Wait for Froxlor's master cron to process the queued REBUILDNSSUSERS task. Result: the request is accepted even if /bin/bash is not present in system.availableshells ftpusers.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.

Impact

Affected versions

Security releases

Remediation advice