Description

Froxlor before 2.3.12 does not restrict or escape the system.letsencryptchallengepath setting: unlike sibling settings hardened in GHSA-33mp, the field has no string_regexp or required_otp guard, and its value is concatenated unescaped into the acme.sh command line built in lib/Froxlor/Cron/Http/LetsEncrypt/AcmeSh.php and executed by the root cron via FileDir::safe_exec. Because safe_exec only blacklists shell metacharacters such as ; | & > < \ $ ~ ?, spaces and quotes survive and the value is word-split into additional acme.sh arguments. An administrator, or any actor able to write settings (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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "9.1",
  "pubDate": "2026-09-26T14:16:57.240Z",
  "pubdate": "2026-09-26T14:16:57.240Z",
  "executiveSummary": "Froxlor versions prior to 2.3.12 contain a critical command injection vulnerability stemming from improper input validation of the system.letsencryptchallengepath configuration setting.\nThe vulnerability allows an authenticated attacker, such as an administrator or any actor capable of modifying system settings (e.g., via the settings-import API), to inject arbitrary arguments into the acme.sh command-line execution string.\nBecause the underlying cron process executes with root privileges, successful exploitation results in full system compromise via arbitrary command execution.\nThe flaw exists because the application performs insufficient sanitization within the FileDir::safe_exec utility, failing to adequately constrain input characters like spaces and quotes. This allows attackers to bypass existing blacklist-based protections to weaponize the acme.sh utility.\nThe risk profile is severe, as it facilitates privilege escalation to root. Immediate patching to version 2.3.12 or later is required to remediate this configuration handling defect.",
  "technicalDetails": "The root cause of this vulnerability is the inadequate validation and sanitization of the system.letsencryptchallengepath setting in Froxlor. Unlike other system settings hardened in GHSA-33mp, the 'system.letsencryptchallengepath' configuration field lacks robust input guards, such as regex-based validation (string_regexp) or OTP enforcement.\nThe application passes the raw, unescaped input from this setting into the acme.sh command line, which is constructed and executed within lib/Froxlor/Cron/Http/LetsEncrypt/AcmeSh.php. While the application utilizes a helper function, FileDir::safe_exec, for command execution, this function employs a blacklist-based protection mechanism that filters only a subset of shell metacharacters (e.g., ; | & > < \\ $ ~ ?).\nCritically, the blacklist implemented in FileDir::safe_exec fails to filter spaces and quotation marks. This oversight allows an attacker to manipulate the command-line argument structure. By injecting spaces and quotes, an attacker can break out of the intended argument scope, causing the shell to word-split the input and inject unauthorized parameters into the acme.sh execution sequence.\nThe attack flow proceeds as follows: 1. An attacker with access to the system settings—via the web interface or the settings-import API—modifies the 'system.letsencryptchallengepath' value to include malicious acme.sh flags. 2. The attacker injects flags such as --renew-hook, --pre-hook, or --post-hook, followed by a command of their choosing. 3. Upon the next invocation of the Let's Encrypt cron job, the system executes the malicious command chain.\nThe ability to specify options like --config-home or --cert-home provides additional primitives for arbitrary file writes, potentially allowing for the overwriting of sensitive system files or configuration files. Since the cron process executes with root privileges, any command specified in a hook or any file modification attempt is executed or written with root-level authority, leading to full system takeover. This vulnerability persists in all versions up to and including 2.3.10 and is remediated in version 2.3.12."
}