CVE-2026-109962

Froxlor before 2.3.14 contains an insecure direct object reference vulnerability in the email template editor (admin_templates.php) because the mail body is fetched by mailbodyid without an adminid ownership check. Authenticated reseller admins can pair their own subjectid with sequential foreign mailbodyid values in edit requests to read other admins' email templates, including the full administrator's.

Froxlor 0.10.0 before 2.3.14 contains a newline injection vulnerability that allows authenticated customers to inject arbitrary entries into the root-owned NSS group database via the unvalidated additional_members parameter of the Ftps.add API. Attackers can embed newline characters that the REBUILD_NSSUSERS cron writes unsanitized into /var/lib/extrausers/group, creating privileged group entries for local privilege escalation.

Froxlor 2.0.0 before 2.3.14 contains a stored cross-site scripting vulnerability that allows authenticated customers to inject HTML and JavaScript by setting a malicious theme value via customer_index.php. Script executes when an administrator views the customer overview with the Theme column enabled, letting attackers abuse the CSRF token to create administrator accounts or change server settings.

Froxlor through 2.3.10 disables a user's two-factor authentication immediately upon an unauthenticated-triggerable GET request to the 2FA management page (e.g. /customer_index.php?page=2fa&action=delete), with no confirmation, re-authentication, or CSRF token. The global CSRF middleware only covers POST/PUT/PATCH/DELETE requests, and the session cookie is set to SameSite=Lax, so a cross-site top-level navigation (link click or redirect) carries the victim's session and silently clears type_2fa/data_2fa. Both the customer and admin 2FA handlers are affected. An attacker who lures a logged-in panel user into following a crafted link reduces that account to password-only authentication, which can be chained with a compromised password for account takeover. Fixed in 2.3.12.

froxlor versions before 2.3.12 fail to invalidate existing panel sessions, API keys, and 2FA trust cookies when a user password is changed. Attackers holding hijacked sessions, valid API keys, or 2FA trust tokens retain full account access after password rotation, bypassing incident response actions.

Froxlor before 2.3.13 returns the ssl_key_file column — which stores the raw PEM TLS private-key content — verbatim in the JSON responses of the Certificates.get and Certificates.listing API commands, because the results of the underlying domain_ssl_settings queries are passed through ApiCommand::response() without any field stripping or allowlist. A low-privileged authenticated customer API caller can retrieve the private keys of their own domains' certificates, including Let's Encrypt keys that Froxlor generates server-side and stores root-only (0600) and to which the customer otherwise has no filesystem access; reseller and customers_see_all admin accounts can dump the private keys of other principals through the same sink. Disclosed keys enable domain impersonation, passive decryption of captured TLS traffic, and active machine-in-the-middle attacks.

Froxlor in versions 2.3.10 and earlier contains an incomplete fix for GHSA-c3p2 — Validate::validateUrl rejects CR/LF characters only in the path, query, and fragment components and never inspects the userinfo (user:pass@) components. An authenticated low-privilege customer with subdomain-create rights can supply a subdomain redirect URL carrying a CR/LF payload in the userinfo portion, which passes validation and is written verbatim into the generated nginx or Apache vhost configuration. Froxlor regenerates and reloads the web-server configuration as root, so injected directives take effect server-wide.

Froxlor in versions 2.3.10 and earlier contains an incomplete fix for GHSA-75h4-... — the customer data-export (DataDump) cron fails to validate intermediate path components of the export destination. Froxlor\FileDir::makeCorrectDir() contains an off-by-one in its path-component walk that skips the first segment below the customer home directory, and the guard in ExportCron.php checks only the final component with is_link(). An authenticated customer with the export feature enabled can schedule an export into a genuine subdirectory of their own webspace, then replace an intermediate path component with a symlink before the root-owned cron runs. The cron's 'chown -R' then recursively changes ownership of the linked directory tree (e.g. /etc) to the customer's UID, yielding host root and cross-tenant compromise.

Froxlor through 2.3.10 is vulnerable to arbitrary file deletion via symlink following in the FTP data deletion cron task. Cron task 8 (deleteFtpData), queued when an FTP account is deleted, calls FileDir::makeCorrectDir() without the $fixed_homedir argument, so the symlink component walk is skipped, and then executes 'rm -rf' as root on the resulting path with string-level guards only. Because makeCorrectDir() appends a trailing slash, GNU rm dereferences a symlink used either as an intermediate or final path component. An authenticated customer who can write to the FTP home directory can plant a symlink between task insertion and cron execution, causing the root cron job to recursively delete arbitrary directory trees.

Froxlor before 2.3.12 does not restrict or escape the system.letsencryptchallengepath setting — unlike sibling settings hardened in GHSA-33mp, the field has no string_regexp or required_otp guard, and its value is concatenated unescaped into the acme.sh command line built in lib/Froxlor/Cron/Http/LetsEncrypt/AcmeSh.php and executed by the root cron via FileDir::safe_exec. Because safe_exec only blacklists shell metacharacters such as ; | & > < \ $ ~ ?, spaces and quotes survive and the value is word-split into additional acme.sh arguments. An administrator, or any actor able to write settings (e.g. through the settings-import API), can inject acme.sh options such as --renew-hook, --pre-hook or --post-hook to obtain arbitrary command execution as root at the next Let's Encrypt cron run, or use --config-home/--cert-home for arbitrary file writes.