Froxlor vulnerabilities

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 missing authorization vulnerability that allows reseller accounts to read full-admin-only MySQL server and cronjob configuration via API read commands. Resellers can call MysqlServer.listing, MysqlServer.get, or Cronjobs.listing through api.php to obtain management usernames, hosts, ports, TLS settings, and cron metadata.

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.

Froxlor versions before 2.2.5 fail to validate newline characters in subdomain redirect URLs, allowing authenticated customers to inject arbitrary nginx or Apache configuration directives. Malicious URLs containing literal newlines are written verbatim into vhost config files during cron rebuild, enabling web server configuration corruption, denial of service, or hijacking of HTTP responses across hosted domains.

Froxlor 2.3.7 through 2.3.8 in the API commands Customers.get, Customers.listing, Admins.get, Admins.listing, Ftps.get, and Ftps.listing returns full database rows without removing password and data_2fa fields. An authenticated API caller with permission to use these endpoints can obtain customer, administrator, and FTP password hashes as well as Base32-encoded TOTP seeds for administrator and customer accounts. Password hashes can be cracked offline, and TOTP seeds can generate valid second-factor codes until two-factor authentication is reset. Exposure of both values for an account can enable takeover of the hosting panel or hosted resources and can defeat both authentication factors. This issue is fixed in version 2.3.8.

Froxlor before 0.9.33.2 with the default configuration/setup might allow remote attackers to obtain the database password by reading /logs/sql-error.log.

Froxlor before 0.9.35 uses the PHP rand function for random number generation, which makes it easier for remote attackers to guess the password reset token by predicting a value.

Froxlor 2.0.0 through 2.3.10 is vulnerable to stored cross-site scripting. When a customer (the lowest-privileged authenticated role) uploads an SSL certificate for one of their own domains, the Certificates API add()/update() methods parse it with openssl_x509_parse() and store the issuer organization (issuer['O']) value verbatim without sanitization. Froxlor's table-listing renderer then emits scalar cells through Twig's `raw` filter, disabling HTML auto-escaping, so when an administrator or reseller opens Domains > SSL certificates the attacker-supplied issuer value executes as script in the privileged user's session. This crosses a privilege boundary from customer to admin and can result in full administrator account takeover; because a Froxlor admin controls webserver, DNS, and PHP configuration applied by a cron job running as root, the issue can be further escalated to command execution as root on the managed server. The issue is fixed in Froxlor 2.3.12.

Credential disclosure vulnerability in Froxlor before version 2.3.12 in the DirProtections.listing API command that returns htpasswd password hashes. Authenticated API users can retrieve bcrypt password hashes for protected-directory users, enabling offline cracking attempts and exposure of reused credentials.

Froxlor through 2.3.10 does not enforce the mail.allow_external_domains policy in the EmailSender.add API command. When an administrator has enabled the allowed-sender feature but disabled external allowed-sender domains (mail.enable_allow_sender = 1, mail.allow_external_domains = 0), an authenticated customer with API access can still use EmailSender.add to register an arbitrary external sender address for their mailbox, which is stored despite the policy. This creates a bypass between the UI/administrator configuration and the API, and — where the generated mail configuration consumes the allowed-sender table — allows a customer to authorize sender identities outside their hosted domains, facilitating sender spoofing. Fixed in 2.3.12.

Froxlor 2.3.10 and earlier contain a TOCTOU race condition in the SSH key synchronization cron (lib/Froxlor/Cron/System/SshKeys.php, SshKeys::generateFiles). The containment/symlink validation is done only at check time; the live filesystem path is re-resolved as root at write time, with no path or file-descriptor pinning. On installations with system.allow_customer_shell=1, a customer can swap their ~/.ssh directory for a symlink after the check, causing the root-run cron to append the customer's public key to /root/.ssh/authorized_keys and chown /root/.ssh to the customer, resulting in full root compromise. Fixed in Froxlor 2.3.12.

Froxlor through 2.3.10 does not filter sensitive columns from API responses: Domains::get(), Domains::listing(), SubDomains::get(), and the admin branch of SubDomains::listing() perform a wildcard SELECT over the panel_domains table and return the row unmodified, including the panel_domains.dkim_privkey field. An authenticated, non-superadmin admin holding the delegated customers_see_all flag can therefore read the DKIM private signing keys of domains belonging to other tenants via Domains.get, Domains.listing, SubDomains.get, or SubDomains.listing, with a single listing call disclosing the key of every visible domain. The disclosed keys allow an attacker to sign email that passes DKIM verification and DMARC alignment for the affected domains. This is a follow-on to an incomplete fix that stripped password and data_2fa but not dkim_privkey. The issue is fixed in 2.3.12.

Froxlor through 2.3.10 stores only a numeric user ID in remembered-2FA tokens (panel_2fa_tokens) without recording the account namespace, and the remembered-token lookup during login is not constrained to the customer or administrator account type. Because customer and administrator IDs are allocated from separate namespaces, a remembered-2FA token legitimately issued to a customer with a given ID also matches an administrator with the same ID. An attacker who controls a customer account with a colliding ID, holds a valid remembered-2FA cookie for it, and already knows the target administrator's password can bypass the administrator's TOTP second factor and obtain an authenticated administrator session. This is a second-factor bypass only; it does not defeat password authentication. Fixed in 2.3.12.

Froxlor before 2.3.7 fails to properly scope sender alias lookups to the current customer in customer_email.php. Authenticated attackers can enumerate global sender alias IDs and read other customers' allowed sender values by supplying arbitrary senderid parameters in delete confirmation requests.

Froxlor before 2.3.7 fails to validate the mysql_server parameter against a customer's allowed_mysqlserver allowlist in the Mysqls.add API command. Attackers can supply a disallowed server index to create MySQL databases and users on forbidden servers, bypassing per-customer access controls.

Froxlor before 2.2.0 (affected up to and including 2.2.0-rc3) generates /etc/pure-ftpd/db/mysql.conf with mode 0644 via the XML configuration templates in lib/configfiles/, even though the file contains the Froxlor SQL user's password. On systems where the parent directories are world readable (the default on Debian 12), any unprivileged local user able to execute commands or code on the host — including virtual users without SSH access who can upload PHP/CGI scripts — can read the file and obtain the Froxlor database credentials. Database access can then be leveraged to alter an administrator's password hash and TOTP seed, log in as a Froxlor administrator, and ultimately gain root privileges. Only instances configured to use pure-ftpd are affected.

Froxlor before 2.3.12 fails to properly validate multi-line SSH public keys in the SshKeys::add() endpoint, allowing customers to inject arbitrary lines into authorized_keys files, including malicious SSH key entries with option directives.

Vulnerability in Froxlor before version 2.3.8. The lib/ajax.php entry point bypasses centralized request validation, and the editapikey action does not validate a CSRF token. An unauthenticated attacker can induce an authenticated administrator's browser to submit a forged request that adds an attacker-controlled address to an API key's allowed_from list or removes its expiration, weakening the key's security restrictions.

Froxlor before version 2.3.8 has a vulnerability in the DomainZones.add API command that does not reject line delimiters, tab characters, semicolons, or unsupported DNS record types before serializing values into a BIND zone file. An authenticated customer with DNS-zone permissions can inject additional resource-record lines, bypassing field-level validation. BIND accepts the injected records, allowing modification of DNS data and potential DNS availability impact.

Froxlor before version 2.3.8 contains a SQL Injection vulnerability in the Admins.add and Admins.update endpoints, where an attacker-controlled ipaddress array is stored and later concatenated into a SQL IN clause without parameterization. An authenticated administrator with change_serversettings permission can exploit this to retrieve arbitrary database data, including admin credentials.

Froxlor before version 2.3.8 contains a Stored XSS vulnerability in DNS TXT record content, which is not properly escaped before rendering in the admin panel. An authenticated customer with DNS editor access can inject JavaScript that executes in the administrator's browser session.

Froxlor before version 2.3.7 contains a vulnerability in the API authentication path that does not require a second factor (2FA) for accounts with two-factor authentication enabled. An attacker who obtains an API key and secret can access API functions without providing the TOTP code, potentially exposing or modifying customer data, domains, email and FTP accounts, databases, DNS records, and certificate material.

Froxlor version 2.3.6 and earlier has a vulnerability in DNS record validation for LOC, TLSA, and other types. The LOC regex allows newlines, TLSA matchingType=0 has no upper bound on hex data length, and validators return raw input without zone-file escaping.

Froxlor version 2.3.6 contains a symlink-following flaw in the root-owned SSH key synchronization path used for customer FTP users. An attacker with shell access can replace authorized_keys with a symlink to /root/.ssh/authorized_keys, enabling root SSH access.

Froxlor 2.3.6 does not enforce the approved shell list for FTP accounts. An authenticated customer with shell delegation can set an arbitrary shell like /bin/bash, which in the default nssextrausers integration leads to real host shell access.

Froxlor prior to version 2.3.7 has a vulnerability in the DomainZones.add API endpoint that does not sanitize newline characters in TXT record content. An authenticated customer with DNS editing enabled can inject newlines, allowing injection of arbitrary BIND directives and DNS records into the zone file.