CVE-2026-100714 in Froxlor
Summary
by MITRE • 09/26/2026
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.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 09/26/2026
The vulnerability identified in Froxlor versions prior to 2.3.12 represents a critical command injection flaw rooted in improper input validation and unsafe execution of system commands. This specific weakness allows an attacker with administrative privileges or access to the settings-import API to execute arbitrary code as the root user, leveraging the automated Let's Encrypt certificate renewal process. The core technical failure lies within the handling of the system.letsencryptchallengepath configuration setting. Unlike other similar configuration fields in Froxlor that were hardened against injection attacks through strict regular expression validation and required one-time password guards, this particular field lacks such protective measures. Consequently, user-supplied input is concatenated directly into command-line arguments without sanitization or escaping, creating a direct pathway for code execution.
The operational mechanism of the exploit involves manipulating the acme.sh script invocation located in lib/Froxlor/Cron/Http/LetsEncrypt/AcmeSh.php. The application constructs an acme.sh command line by appending the value of the letsencryptchallengepath setting directly to other arguments. This constructed string is then passed to FileDir::safe_exec for execution via a root cron job. While safe_exec attempts to mitigate risk by blacklisting common shell metacharacters such as semicolons, pipes, ampersands, redirections, backslashes, dollar signs, tildes, and question marks, it fails to account for the behavior of word splitting in shell environments. Spaces and quotes are not filtered out, allowing an attacker to break out of the intended argument context. By injecting spaces followed by valid acme.sh options, such as --renew-hook, --pre-hook, or --post-hook, the attacker can inject additional commands that will be executed with root privileges during the next scheduled certificate renewal cycle.
The impact of this vulnerability is severe due to the privilege level at which it operates. Since the cron job runs as root, any command injected via these hook options gains full system control. An adversary could use --renew-hook or similar parameters to execute arbitrary shell commands, effectively achieving remote code execution with the highest possible privileges on the server. Alternatively, an attacker might exploit acme.sh configuration options like --config-home or --cert-home to write files to arbitrary locations on the filesystem. This capability can be used to plant backdoors, modify system configurations, or escalate further into other parts of the infrastructure by manipulating critical file paths that are subsequently read or executed by root processes.
This vulnerability aligns with CWE-78 Improper Neutralization of Special Elements used in an OS Command and CWE-94 Improper Control of Generation of Code. From a tactical perspective, it maps to ATT&CK technique T1059 Command and Scripting Interpreter, specifically involving the execution of system commands through automated processes. The lack of strict input validation despite the high privilege level of the executing context highlights a significant gap in secure coding practices for configuration management interfaces.
Mitigation requires immediate upgrading to Froxlor version 2.3.12 or later, where this issue has been resolved by implementing proper string escaping and stricter validation rules similar to those applied to other sensitive settings. In environments where an upgrade is not immediately feasible, administrators should restrict access to the settings-import API and any interface that allows modification of system configuration values. Additionally, monitoring cron logs for unusual acme.sh invocations or unexpected file writes in certificate directories can help detect exploitation attempts. Ensuring that only trusted users have administrative access to Froxlor is essential to prevent unauthorized manipulation of these critical security controls.