CVE-2026-43633: HestiaCP Web Terminal RCE
Critical CVSS (10.0) reachable over network.
TL;DR - CVE-2026-43633 is a CVSS 10.0 deserialization flaw in HestiaCP’s web terminal. - HestiaCP 1.9.0–1.9.4 may allow unauthenticated attackers to execute commands as root when the feature is enabled. - Disable the web terminal, restrict panel access, and upgrade to a release containing commit
854d71b3c1737b0a0d0cc55c926008ffe1f6719b.
CVE-2026-43633 is a critical HestiaCP web terminal RCE vulnerability caused by unsafe deserialization across a PHP and Node.js session-handling boundary. It affects HestiaCP versions 1.9.0 through 1.9.4 and may allow unauthenticated attackers to execute arbitrary commands with root-level privileges when the vulnerable web-terminal functionality is enabled and reachable.
Summary
An attacker can inject crafted data through HTTP headers, causing the web-terminal service to process attacker-controlled values as trusted session data. Successful exploitation can provide arbitrary command execution with root-level impact.
The described attack path is unauthenticated, so internet-exposed HestiaCP installations require urgent review. The vulnerability was not listed in the CISA Known Exploited Vulnerabilities catalog at the time of assessment.
| Field | Value |
|---|---|
| CVE ID | CVE-2026-43633 |
| Product | HestiaCP web terminal |
| Affected versions | 1.9.0 through 1.9.4 |
| CVSS | 10.0 |
| Attack vector | Network |
| Authentication or privileges required | None |
| User interaction | None |
| CWE | CWE-502, Deserialization of Untrusted Data |
| Patch status | Fix commit identified; first fixed release not confirmed in the retrieved sources |
| Root impact | Arbitrary command execution with root-level privileges |
The available records identify HestiaCP commit 854d71b3c1737b0a0d0cc55c926008ffe1f6719b as the remediation reference. The retrieved NVD data does not identify a conventional fixed HestiaCP release version. Administrators should verify the first vendor release containing that commit before treating an upgrade as complete.
Analyst’s Take: Treat this first as an exposure and containment problem, not as a version-checking exercise. A vulnerable installation with the web terminal enabled and reachable can offer unauthenticated root-level command execution, while the first fixed release remains unconfirmed in the available records.
For background on unsafe deserialization, see our guide to what insecure deserialization is.
Root Cause
The vulnerability is caused by a session-format mismatch between HestiaCP’s PHP session-handling logic and the Node.js web-terminal component. Data originating in HTTP headers can reach the PHP session handler and subsequently be interpreted by Node.js using assumptions that do not safely match the original format or trust level.
The resulting boundary allows attacker-influenced serialized values to be processed as trusted session state. This is an unsafe deserialization condition, classified as CWE-502. If crafted values reach the vulnerable execution path, the attacker can influence commands executed by the web terminal.
The relevant trust-boundary sequence is:
- An unauthenticated client sends crafted HTTP-header data.
- The PHP session-handling layer processes that data.
- The Node.js web-terminal component interprets the resulting session values.
- Unsafe deserialization converts attacker-controlled content into trusted application state.
- The attacker obtains arbitrary command execution with root-level impact.
This is more serious than a conventional authenticated panel flaw because the attack does not depend on a valid HestiaCP account according to the available vulnerability description. Practical exposure still depends on whether the web-terminal component is enabled and reachable through the deployment’s network path.
Who’s Exposed
The affected product is HestiaCP, specifically its web-terminal component. The documented affected versions are:
| HestiaCP version | Status |
|---|---|
| 1.9.0 | Affected |
| 1.9.1 | Affected |
| 1.9.2 | Affected |
| 1.9.3 | Affected |
| 1.9.4 | Affected |
Systems running these versions should be considered exposed when the web-terminal feature is enabled and the relevant HestiaCP interface is reachable by an attacker. Internet exposure increases risk, but an internal attacker may also be able to exploit an installation reachable from an untrusted or semi-trusted network.
The available records do not identify a conventional fixed release number. They identify remediation commit 854d71b3c1737b0a0d0cc55c926008ffe1f6719b. Until HestiaCP maintainers or release metadata confirm the first release containing this correction, defenders should not assume that an unspecified later version is fixed solely because its version number is higher. Confirm the package or source revision explicitly.
Installations without the web-terminal feature enabled may not be exposed to the described attack path. Verify feature status rather than inferring it from deployment documentation. A server may also remain at risk if the component is enabled by default, started as a separate service, or exposed through a reverse proxy or panel configuration.
Severity Breakdown
NVD assigns CVE-2026-43633 a CVSS base score of 10.0, placing it in the critical severity category. The retrieved NVD response supplied the score but did not include the complete CVSS vector string. A GitHub Advisory result reports the following CVSS v4 characteristics:
| Component | Reported value | Practical meaning |
|---|---|---|
| Attack vector | Network | Exploitation can occur over a network connection |
| Attack complexity | Low | Exploitation does not require unusual conditions or extensive preparation |
| Attack requirements | Present | A deployment or environmental condition is required, such as the vulnerable feature being enabled |
| Privileges required | None | The attacker does not need an authenticated HestiaCP account |
| User interaction | None | No action by a victim is required |
The attack requirements field is operationally significant. It does not make the vulnerability low risk; it indicates that the vulnerable web-terminal functionality must be present or reachable for the attack path to apply. A publicly accessible server with the feature enabled satisfies the most concerning deployment condition.
The impact is especially severe because successful exploitation can lead to root-level command execution. That can enable modification of HestiaCP and operating-system files, credential theft, creation of persistence, hosting-account compromise, malware deployment, data theft, and use of the server as an entry point into connected systems.
Exploitation Status
No confirmed exploitation in the wild was established by the sources reviewed for this assessment. CVE-2026-43633 was also not present in the CISA Known Exploited Vulnerabilities catalog at the time of the check. As a result, there is no CISA KEV date-added value, due date, required action, or ransomware-campaign flag to report.
No confirmed public exploit repository or working public proof of concept was identified in the retrieved primary references. Public technical material does exist, including the HestiaCP issue, pull request, remediation commit, and third-party advisories. That material documents the vulnerability and its fix, but it should not be represented as a confirmed weaponized proof of concept.
The absence of KEV inclusion or a confirmed public proof of concept is not evidence that exploitation is impossible. The vulnerability is unauthenticated, network reachable under the relevant deployment conditions, and potentially provides root-level execution. Defenders should prioritize containment and remediation based on exposure and impact rather than waiting for exploitation reporting.
Related Security Guidance
Organizations managing multiple automated systems should also review the risks of AI agent sprawl, particularly where administrative credentials or infrastructure access are distributed across services. The same principles apply here: maintain an accurate asset inventory, minimize exposed management interfaces, and verify privileges at trust boundaries.
Sources
The following sources provide the vulnerability record, remediation reference, and supporting technical discussion:
- NVD: CVE-2026-43633
- HestiaCP remediation commit
- HestiaCP issue #5229
- HestiaCP pull request #5244
- Mercury ISS advisory
- VulnCheck advisory
- GitHub Advisory Database: GHSA-p57r-8pg4-2892
- CVE.org record
At assessment time, CVE-2026-43633 was not listed in CISA KEV, no confirmed in-the-wild exploitation was established, and no confirmed public exploit repository was identified. These statuses can change; organizations should reassess exposure and threat intelligence before closing the incident or remediation ticket.
This article may contain affiliate links. We earn a commission on qualifying purchases at no extra cost to you.
Detection Guidance
Begin by identifying all HestiaCP installations and determining their exact versions, web-terminal status, and exposure. Inventory should include standalone servers, hosting nodes, cloud images, and systems managed by third parties. Record whether the HestiaCP panel or web-terminal endpoint is reachable from the public internet, management networks, customer networks, or only through a VPN.
Review reverse-proxy, web-server, HestiaCP, and operating-system logs for unauthenticated requests to web-terminal paths, unusual HTTP headers, repeated malformed requests, and activity followed by command execution or process creation. The available research does not provide a definitive network signature, so the following pattern should be treated as a triage lead rather than a complete exploit detector.
Technical Notes: Log and Endpoint Triage
Search access logs for web-terminal requests and suspicious header-related activity:
sudo zgrep -Ei \
'web.?terminal|terminal|socket|upgrade|cookie:|x-forwarded|x-real-ip' \
/var/log/nginx/access.log* /var/log/apache2/access.log* 2>/dev/null
Correlate requests with newly spawned privileged processes. The exact process names and paths will vary by deployment, so investigate unusual root-owned children of panel, web-server, PHP, or Node.js processes:
sudo journalctl --since "2026-05-19" --no-pager \
| grep -Ei 'hestia|vesta|node|php|nginx|apache|httpd|sudo|useradd|ssh|curl|wget|bash|sh'
A generic SIEM query for initial triage could be expressed as:
(
url.path contains "terminal"
OR url.path contains "websocket"
)
AND (
http.request.method in ("GET", "POST")
OR http.request.headers exists
)
AND (
process.parent.name in ("node", "php-fpm", "nginx", "apache2", "httpd")
AND process.user.name = "root"
)
This query is intentionally broad. Header names, endpoint paths, and process-parent relationships differ across HestiaCP configurations. Treat any matching event as a lead and compare it with process execution, file changes, account modifications, and outbound network activity.
After suspected exploitation, inspect for new privileged users, modified SSH keys, cron jobs, systemd units, web shells, changed HestiaCP files, unexpected listening services, and outbound connections. Because root-level compromise is possible, do not rely solely on application logs to establish system integrity.
Remediation Steps
The primary remediation reference is HestiaCP commit:
854d71b3c1737b0a0d0cc55c926008ffe1f6719b
The retrieved sources do not confirm the first released HestiaCP version containing this commit. Therefore, the specific fixed release number is unknown from the available evidence. Administrators should obtain the vendor’s release confirmation and upgrade to that release or any later release that demonstrably includes the commit. Do not claim that a particular version is fixed without verifying the vendor changelog, package contents, or source revision.
Where an official release containing the fix is available, use the supported HestiaCP upgrade procedure for the installed distribution and then verify the resulting version and source state. Avoid replacing production files with an unreviewed commit. If no supported release is available, applying the referenced commit may be considered only after testing, backup, rollback planning, and code review in a controlled environment.
Technical Notes: Upgrade and Containment
The exact supported HestiaCP upgrade command was not specified in the retrieved sources. Do not substitute an unverified command into production. First inspect the installation’s documented upgrade mechanism and package state:
sudo hestia -v
sudo dpkg-query -W hestia 2>/dev/null || true
sudo rpm -q hestia 2>/dev/null || true
git -C /usr/local/hestia rev-parse HEAD 2>/dev/null || true
After upgrading through a vendor-supported method, verify that the installed source or package contains the remediation commit where applicable:
git -C /usr/local/hestia log --oneline --all \
| grep -F '854d71b3c1737b0a0d0cc55c926008ffe1f6719b'
If the web terminal is not required, disable it using the supported HestiaCP administrative procedure and stop or remove its associated service only after confirming the service name for the installation:
sudo systemctl list-units --type=service --all \
| grep -Ei 'hestia|terminal|node'
Do not blindly stop a service based only on a guessed unit name. Confirm the component, apply the supported disablement procedure, and verify from an external network that the web-terminal endpoint is no longer reachable.
As an interim control, restrict access to the HestiaCP interface with a VPN, firewall allowlist, or management-network ACL. This reduces exposure but is not a substitute for upgrading. Review inbound firewall rules, reverse-proxy routes, load-balancer listeners, and IPv6 exposure; controls applied only to IPv4 may leave the panel reachable over IPv6.
If exploitation is suspected, isolate the server from the internet, preserve relevant logs and disk evidence, rotate credentials and SSH keys from a trusted system, and rebuild from a known-good image where root compromise cannot be ruled out. A patch applied after confirmed root-level compromise does not establish that the host is clean.