CVE-2026-111627 in HestiaCP
Summary
by MITRE • 10/16/2026
HestiaCP before 1.10.5 contains an authorization bypass vulnerability that allows non-ROOT_USER administrators to perform write actions while impersonating the protected ROOT_USER account. Attackers can log in via the loginas parameter and POST to /add/cron/, because the read-only flag is never checked, causing crond to run their commands as the protected administrator's system account.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 10/16/2026
The vulnerability identified in Hestia Control Panel versions prior to 1.10.5 represents a critical authorization bypass flaw that fundamentally undermines the principle of least privilege within the administrative interface. This security defect specifically affects non-ROOT_USER administrators, who are typically granted restricted permissions to manage specific domains or services without accessing core system configurations. The root cause lies in the improper implementation of access control checks during the execution of privileged operations. Specifically, when an administrator utilizes the loginas parameter to impersonate another user account, the application fails to validate whether the target action is permitted for that role. This oversight allows lower-privileged users to escalate their privileges effectively by assuming the identity of the protected ROOT_USER account and executing write actions that should be strictly prohibited.
The technical mechanism of this exploitation involves a specific interaction with the cron job management interface at the /add/cron/ endpoint. An attacker can authenticate as any non-root administrator and then issue a POST request to add a new scheduled task. Crucially, while the application may display read-only indicators or restrict certain UI elements for lower-privileged users, it does not enforce these restrictions on the backend logic when processing requests made via the loginas parameter. The system fails to check the read-only flag associated with the impersonated account before executing the command. Consequently, the cron daemon executes the maliciously crafted commands under the context of the protected administrator's system account rather than the requesting user's account. This discrepancy between frontend restrictions and backend enforcement creates a direct path for privilege escalation.
The operational impact of this vulnerability is severe, as it allows an attacker to achieve arbitrary command execution with elevated privileges on the underlying operating system. By injecting commands into cron jobs that run as root or another high-privileged service account, attackers can compromise the integrity, confidentiality, and availability of the entire server environment. This could lead to full system takeover, data exfiltration, installation of backdoors, or disruption of critical services running under the protected administrator's identity. The ability to bypass administrative boundaries means that a single compromised low-level admin account can serve as an entry point for complete infrastructure compromise, negating the security benefits of role-based access control implemented within HestiaCP.
To mitigate this risk, organizations must immediately upgrade Hestia Control Panel to version 1.10.5 or later, where these authorization checks have been corrected to properly validate permissions regardless of the impersonation context. In environments where upgrading is not instantly feasible, administrators should restrict network access to the control panel interface using firewalls and ensure that only trusted IP addresses can reach the administrative endpoints. Additionally, implementing multi-factor authentication for all administrator accounts adds a layer of defense against credential theft, which is often the precursor to such exploitation attempts. Monitoring logs for unusual loginas activity or unexpected cron job creations by non-root users can also aid in early detection of potential abuse attempts.
From a classification perspective, this vulnerability aligns with CWE-269 Improper Privilege Management and CWE-732 Incorrect Permission Assignment for Critical Resource within the Common Weakness Enumeration framework. It is categorized under MITRE ATT&CK technique T1078 Valid Accounts, specifically involving privilege escalation through impersonation or abuse of legitimate credentials to gain higher-level access. The failure to enforce role-based constraints during API interactions highlights a common pattern in web application security where frontend validations are not mirrored by robust backend authorization logic. Addressing such flaws requires rigorous code review focusing on identity verification and permission checks at every step of the request processing pipeline, ensuring that impersonation features do inadvertently bypass critical security controls designed to protect high-privilege accounts.