CVE-2026-43634 Overview
CVE-2026-43634 is an IP spoofing vulnerability in HestiaCP versions 1.2.0 through 1.9.4. The control panel trusts the CF-Connecting-IP HTTP header without verifying that the request originated from Cloudflare's network. Unauthenticated remote attackers can supply an arbitrary IP address in this header to bypass authentication security controls. Exploitation allows attackers to circumvent fail2ban brute-force protection, bypass per-user IP allowlists, and poison authentication audit logs. The flaw is categorized under CWE-348: Use of Less Trusted Source.
Critical Impact
Unauthenticated attackers can spoof trusted IP addresses on every request, defeating brute-force protections and IP-based access controls in HestiaCP deployments.
Affected Products
- HestiaCP 1.2.0 through 1.9.4
- HestiaCP deployments using the web authentication interface
- HestiaCP instances regardless of whether Cloudflare is actually in front of them
Discovery Timeline
- 2026-05-19 - CVE-2026-43634 published to NVD
- 2026-05-19 - Last updated in NVD database
Technical Details for CVE-2026-43634
Vulnerability Analysis
HestiaCP reads the client IP address from the HTTP_CF_CONNECTING_IP server variable when present, falling back to REMOTE_ADDR otherwise. The application does not validate that the upstream connection originates from a Cloudflare IP range before honoring the header. Any direct HTTP request that includes a CF-Connecting-IP header causes HestiaCP to treat the supplied value as the authoritative client IP.
This trust decision affects multiple security subsystems. The fail2ban integration logs the spoofed IP rather than the attacker's real address, so brute-force lockouts never apply to the attacker. Per-user IP allowlists check the spoofed value, allowing attackers to assert a permitted address. Authentication audit logs record the attacker-controlled value, breaking forensic attribution.
Root Cause
The root cause is unauthenticated proxy header trust. HestiaCP accepts a header that is meant to be set only by a trusted reverse proxy without first authenticating the source of the connection. The vendor patch addresses this by replacing direct header reads with a get_real_user_ip() helper and adding the divinity76/cloudflare-ip-validator dependency to verify upstream connections against Cloudflare's published IP ranges.
Attack Vector
The vulnerability is exploitable over the network with no authentication, no privileges, and no user interaction. An attacker sends an HTTP request directly to the HestiaCP authentication endpoint and includes a CF-Connecting-IP header with the desired spoofed IP. Each subsequent request can carry a different spoofed value, allowing attackers to rotate identities to evade rate limits and brute-force protection.
check_return_code($return_var, $output);
unset($output);
-$ip = $_SERVER["REMOTE_ADDR"];
-if (isset($_SERVER["HTTP_CF_CONNECTING_IP"])) {
- if (!empty($_SERVER["HTTP_CF_CONNECTING_IP"])) {
- $ip = $_SERVER["HTTP_CF_CONNECTING_IP"];
- }
-}
+$ip = get_real_user_ip();
$v_ip = quoteshellarg($ip);
$user_agent = $_SERVER["HTTP_USER_AGENT"];
$v_user_agent = quoteshellarg($user_agent);
Source: HestiaCP patch commit f381e29. The patch replaces direct reads of HTTP_CF_CONNECTING_IP with a get_real_user_ip() helper that validates the upstream connection.
Detection Methods for CVE-2026-43634
Indicators of Compromise
- HTTP requests to HestiaCP endpoints containing a CF-Connecting-IP header from source IPs outside of Cloudflare's published IP ranges.
- Authentication audit log entries showing failed logins from IPs that never appear in web server REMOTE_ADDR access logs.
- Sustained brute-force login attempts against /login/ with no corresponding fail2ban ban events.
- Successful logins from IPs that match per-user allowlists while the underlying TCP connection originates from a different source.
Detection Strategies
- Compare REMOTE_ADDR from reverse proxy or web server logs against the IP value recorded in HestiaCP's auth.log to surface mismatches.
- Alert on any request containing CF-Connecting-IP when the deployment is not actually behind Cloudflare.
- Correlate authentication failures across multiple spoofed source IPs hitting the same username within a short window.
Monitoring Recommendations
- Forward HestiaCP authentication logs and front-end web server logs to a centralized log platform for correlation analysis.
- Monitor fail2ban ban events and alert when brute-force volume increases without proportional bans being issued.
- Track requests to /login/ and /api/ endpoints carrying proxy headers and baseline normal traffic patterns.
How to Mitigate CVE-2026-43634
Immediate Actions Required
- Upgrade HestiaCP to the patched release that includes commit f381e29 and the divinity76/cloudflare-ip-validator dependency.
- If Cloudflare is not used, configure the web server to strip the CF-Connecting-IP header from incoming requests before they reach HestiaCP.
- Restrict access to the HestiaCP admin port (default 8083) to known administrative networks using firewall rules.
- Review authentication and fail2ban logs for evidence of spoofed source addresses prior to patching.
Patch Information
The fix is delivered in HestiaCP commit f381e294500f671cf12716c638afd0bfde901f88, merged via pull request #5273 and tracked in issue #5229. The patch introduces a get_real_user_ip() function that only honors CF-Connecting-IP when the upstream TCP peer belongs to Cloudflare's IP ranges. Additional analysis is available from the VulnCheck advisory and MercuryISS research write-up.
Workarounds
- Place HestiaCP behind a reverse proxy such as nginx that explicitly unsets or overwrites the CF-Connecting-IP header on requests from non-Cloudflare sources.
- Bind the HestiaCP admin interface to localhost or a management VLAN and require VPN access for administrators.
- Disable per-user IP allowlists temporarily, since they cannot be relied upon while the header is spoofable.
# nginx workaround: strip spoofed CF-Connecting-IP from untrusted clients
# Place inside the server block fronting HestiaCP
set $cf_ip "";
if ($remote_addr !~ "^(173\.245\.|103\.21\.|103\.22\.|103\.31\.|141\.101\.|108\.162\.|190\.93\.|188\.114\.|197\.234\.|198\.41\.|162\.158\.|104\.16\.|104\.24\.|172\.64\.|131\.0\.72\.)") {
set $cf_ip "strip";
}
proxy_set_header CF-Connecting-IP $cf_ip;
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.


