HestiaCP CVE-2026-43634

HestiaCP versions 1.2.0 through 1.9.4 with the web admin interface (default port 8083 / login endpoint) reachable by the attacker; no authentication, no user interaction, and no non-default configuration are required because the vulnerable header-trust logic is unconditional in vulnerable releases. Limiting factors: only the authentication control plane (fail2ban throttling, per-user IP allowlists, and audit-log IP fields) is affected - exploiting this CVE alone yields integrity impact (log poisoning and bypass of IP-based brute-force/allowlist controls), not direct code execution or data disclosure unless chained with a separate authentication or RCE flaw such as CVE-2026-43633. Per-user IP allowlist bypass additionally requires the attacker to know or guess a permitted IP value.

CVSS 4.0 8.7 with vector AV:N/AC:L/AT:N/PR:N/UI:N and VI:H reflects a high-integrity-impact, network-reachable, unauthenticated, no-user-interaction flaw against the panel's authentication-control plane - consistent with bypassing fail2ban, IP allowlists, and audit integrity. Publicly available exploit code (Mercury ISS write-up bundling CVE-2026-43633 and this CVE) plus a vendor patch shift this from theoretical to operationally urgent for any internet-exposed HestiaCP instance. The CVSS scope intentionally rates only integrity impact (VI:H, VC:N, VA:N) because the bug itself does not yield code execution or data disclosure; however, the Mercury ISS advisory chains this with CVE-2026-43633 to reach unauthenticated RCE, so treating this issue in isolation as 'just an audit-log problem' would underestimate real-world risk. EPSS and CISA KEV status are not provided in the input data, so widespread automated exploitation cannot be confirmed at this time, but the combination of public PoC, trivial header-injection complexity, and panel exposure on the open internet makes prioritised patching warranted.

An attacker targeting an internet-exposed HestiaCP login page sends repeated failed login attempts to /login/, attaching a CF-Connecting-IP header with a different attacker-chosen value (or a victim/allowlisted address) on every request. Because the panel trusts the header without validating that REMOTE_ADDR belongs to Cloudflare, fail2ban never accumulates enough failures against the real attacker IP to trigger a ban, per-user IP allowlists can be satisfied by spoofing a permitted address, and audit logs are populated with attacker-controlled IPs - enabling sustained brute-force or, when chained with CVE-2026-43633 as described in the public Mercury ISS write-up, full unauthenticated RCE.