CVE-2026-54588: Account Takeover via Host Header Injection in Poweradmin Authentication

Poweradmin is a web-based administration tool designed to manage PowerDNS servers. The software allows DNS administrators to configure zones, manage records, and handle user authorization. To support enterprise environments, Poweradmin integrates with OpenID Connect (OIDC) and Security Assertion Markup Language (SAML) for Single Sign-On (SSO) operations. These integrations reside on the critical authentication perimeter, validating administrative sessions before granting write access to underlying DNS databases.\n\nPrior to versions 4.2.4 and 4.3.3, Poweradmin exposes an unsafe authentication interface. The software constructs callback endpoints, such as the OIDC redirect_uri and the SAML Assertion Consumer Service (ACS) URL, by parsing incoming request metadata on the fly. This processing relies on client-supplied headers rather than statically declared configuration values. The failure to validate incoming host metadata allows arbitrary remote clients to alter the internal state of the generated authentication URLs.\n\nThis vulnerability class is categorized under CWE-20 (Improper Input Validation) and CWE-601 (URL Redirection to Untrusted Site). By manipulating the HTTP Host header, an attacker changes the target location where the application expects identity assertions to be sent. When a legitimate administrative user attempts to log in using the poisoned flow, their session token is routed away from the legitimate infrastructure and toward an attacker-controlled endpoint. This bypasses authentication controls, exposing highly sensitive administrative privileges to unauthorized compromise.

The root cause of CVE-2026-54588 lies in the implementation of the PHP global server variable $_SERVER['HTTP_HOST'] within Poweradmin's SSO controller logic. When establishing connection parameters for third-party Identity Providers (IdPs), the application must supply an absolute URL representing its own callback path. To accomplish this, the application reads the system protocol via $_SERVER['HTTPS'] or HTTP_X_FORWARDED_PROTO and concatenates this with the host retrieved from the client request header.\n\nIn a standard HTTP transaction, the Host header is specified by the client browser. Because the application does not match the received Host value against a strict, predefined list of authorized domains, it treats the untrusted header as the canonical address of the server. This design choice assumes that the HTTP Host header will always reflect the true deployment domain, which is a faulty security assumption in multi-tenant or default-configured web servers.\n\nDuring OIDC or SAML initiation, the application calls helper functions to generate parameters like the 'redirect_uri'. These parameters are appended to the URL query string sent to the Identity Provider. Because the Host header is completely client-controlled, an attacker can substitute the standard domain with an arbitrary destination. The application consumes the malformed Host parameter verbatim, generating a poisoned callback configuration and passing it upstream to the IdP, which accepts the dynamic redirect target based on the initial request trust.

To understand the vulnerable logic, examine the conceptual implementation of the dynamic callback builder within Poweradmin's authentication controllers prior to the patches:\n\nphp\n// Vulnerable Implementation\npublic function getSsoCallbackUrl(): string\n{\n // Dynamically evaluate connection protocol\n $scheme = (!empty($_SERVER['HTTPS']) && $_SERVER['HTTPS'] !== 'off') ? 'https' : 'http';\n if (isset($_SERVER['HTTP_X_FORWARDED_PROTO'])) {\n $scheme = $_SERVER['HTTP_X_FORWARDED_PROTO'];\n \n // Retrieve unvalidated Host header directly from client request\n $host = $_SERVER['HTTP_HOST'];\n\n // Construct absolute redirect path using contaminated host\n return $scheme . '://' . $host . '/auth/oidc/callback';\n}\n\n\nIn this structure, an incoming request containing Host: attacker-controlled.com results in getSsoCallbackUrl() returning https://attacker-controlled.com/auth/oidc/callback. The application then transmits this address to the OAuth Authorization Server as the official callback target.\n\nTo remediate this structural flaw, the patched versions introduce configuration validation. The code is modified to verify the host header or reference a predefined base URL configuration. The corrected pattern avoids referencing $_SERVER['HTTP_HOST'] entirely, utilizing a static configuration parameter instead:\n\nphp\n// Patched Implementation using configured base URL\npublic function getSsoCallbackUrl(): string\n{\n // Retrieve static base URL from protected settings file\n $baseUrl = $this->config->get('interface.base_url');\n \n if (!empty($baseUrl)) {\n return rtrim($baseUrl, '/') . '/auth/oidc/callback';\n }\n \n // Fallback: Validate Host header against strict whitelist if base URL is missing\n $allowedHosts = $this->config->get('security.allowed_hosts', []);\n $host = $_SERVER['HTTP_HOST'] ?? '';\n $cleanHost = preg_replace('/:\\d+$/', '', $host);\n \n if (!in_array($cleanHost, $allowedHosts, true)) {\n throw new SecurityException('Unauthorized Host header detected');\n }\n \n $scheme = (!empty($_SERVER['HTTPS']) && $_SERVER['HTTPS'] !== 'off') ? 'https' : 'http';\n return $scheme . '://' . $cleanHost . '/auth/oidc/callback';\n}\n\n\nBy enforcing fallback verification or utilizing a declared base URL parameter, the application ensures that callback operations remain restricted to authorized, enterprise-controlled environments.

An attack targeting CVE-2026-54588 requires zero privileges and relies on manipulating the initial authentication sequence. The exploitation path consists of three distinct phases: host header poisoning, victim redirection, and token harvest.\n\nmermaid\ngraph LR\n Attacker["Attacker Server"] -->|1. Poisoned Host Header Login Request| Poweradmin["Poweradmin"]\n Poweradmin -->|2. Poisoned redirect_uri Parameter| IdP["Identity Provider (IdP)"]\n IdP -->|3. Victim Browser Redirection with Code| Attacker\n\n\nIn the first phase, the attacker prepares an authentication initiation link. By routing an HTTP request to Poweradmin's SSO endpoint with the header Host: attacker-controlled.com, the attacker forces the application to record the malicious domain as the official callback endpoint. This request generates a valid authentication redirect URL pointing to the Identity Provider, containing the parameter redirect_uri=https://attacker-controlled.com/auth/oidc/callback.\n\nIn the second phase, the attacker delivers this generated link to an administrative user via a social engineering vector. When the administrator clicks the link, their browser is navigated to the legitimate Identity Provider (such as Okta, Keycloak, or Azure AD). The victim enters their valid credentials on the authentic identity portal, unaware that the session initialization parameter contains the injected redirect URI.\n\nIn the final phase, the Identity Provider processes the successful login. It issues a cryptographic authorization code or SAML assertion and sends the victim's browser to the destination defined in the redirect_uri parameter. Because the Identity Provider trusts the initial redirect parameter (or lacks strict whitelist enforcement), it transmits the victim's authorization code directly to https://attacker-controlled.com. The attacker intercepts this code from their web server logs, replays it against the legitimate Poweradmin installation, and achieves a complete administrative session bypass.

The impact of CVE-2026-54588 is classified as critical, presenting a severe risk to infrastructure integrity. Successful exploitation allows unauthenticated remote attackers to compromise any user account, including high-level administrators, without obtaining credentials. This results in complete loss of confidentiality, integrity, and availability within the Poweradmin interface.\n\nBecause Poweradmin functions as the primary control plane for PowerDNS, compromising an administrator session grants the attacker full control over DNS zones. An attacker can alter resource records, modify MX records to intercept corporate emails, change NS records to redirect entire subdomains, or manipulate A/AAAA records to point enterprise web traffic to malicious sites. These actions can be executed within seconds of establishing the hijacked session.\n\nAdditionally, control over DNS infrastructure facilitates secondary attacks. Attackers can obtain valid SSL/TLS certificates by completing automatic ACME DNS-01 challenges, allowing them to decrypt traffic or host authentic-looking phishing sites on legitimate subdomains. The vulnerability's CVSS v3.1 score is calculated at 9.6, reflecting the high impact on confidentiality and integrity, combined with a network-based attack vector requiring minimal user interaction.

Remediation of CVE-2026-54588 requires upgrading the affected Poweradmin deployments to safe releases. For the 4.2.x branch, organizations must apply patch version 4.2.4. For the 4.3.x branch, organizations must migrate to version 4.3.3. These releases contain modifications that restrict redirection endpoints to trusted, verified locations.\n\nIf immediate upgrading is not possible, administrators should configure infrastructure-level mitigations on reverse proxies or web servers. In Nginx, declare a default server block to drop any requests that do not match the expected server name explicitly. This technique neutralizes Host header injection before the request payload is parsed by the PHP FastCGI Process Manager (FPM):\n\nnginx\n# Nginx Host Validation Rule\nserver {\n listen 80 default_server;\n listen [::]:80 default_server;\n server_name _;\n return 444; # Drop request without response\n}\n\nserver {\n listen 80;\n server_name dns-admin.example.com;\n location / {\n proxy_pass http://php-fpm-upstream;\n proxy_set_header Host $host;\n }\n}\n\n\nIn Apache, force the use of static canonical names and deny access to requests carrying unrecognized Host values. Set UseCanonicalName On in the main configuration, and establish rewrite rules that intercept incoming traffic lacking the corporate hostname. Additionally, review the Identity Provider client configurations to ensure that redirect whitelists are restricted to exact matching URLs and do not utilize wildcard matches.