CVE-2026-26279

Froxlor is open source server administration software. Prior to 2.3.4, 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 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. This vulnerability is fixed in 2.3.4.

Froxlor is open source server administration software. Prior to 2.3.4, 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 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. This vulnerability is fixed in 2.3.4.

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 safe_exec() 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

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

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

What happens:

• $fielddata['string_type'] is never set to 'mail'
• validateFormFieldString() checks string_type to decide which validation to apply
• Since it's unset, FILTER_VALIDATE_EMAIL 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:

$fielddata['string_type'] = 'mail';    // = assignment

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

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

// Line 428
FileDir::safe_exec(
    "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 -…

Froxlor is open source server administration software. Prior to 2.3.4, 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 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. This vulnerability is fixed in 2.3.4.

Froxlor is open source server administration software. Prior to 2.3.4, 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 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. This vulnerability is fixed in 2.3.4.

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 safe_exec() 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

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

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

What happens:

• $fielddata['string_type'] is never set to 'mail'
• validateFormFieldString() checks string_type to decide which validation to apply
• Since it's unset, FILTER_VALIDATE_EMAIL 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:

$fielddata['string_type'] = 'mail';    // = assignment

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

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

// Line 428
FileDir::safe_exec(
    "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 -…