CVE-2026-45566: Roxy-WI Login Redirect Flaw Enables Credential Phishing

Technical summary

The vulnerability exists in Roxy-WI's login redirect mechanism. The application attempts to prevent open redirect attacks by filtering the next parameter for literal 'https://' and 'http://' substrings. However, this allowlist-based approach overlooks the RFC 3986 userinfo syntax: user:password@host. When a user submits [email protected]/path, the server constructs https://[email protected]/path and returns it to the client. Modern browser URL parsing treats the credentials portion (victim.example) as userinfo and routes the request to evil.example. The vulnerability is rooted in CWE-601 (URL Redirection to Untrusted Site / 'Open Redirect') and affects versions 8.2.6.4 and earlier. The CVSS 3.1 score of 6.1 (MEDIUM) reflects network accessibility, low attack complexity, no privilege requirement, user interaction dependency, and scope change with limited confidentiality and integrity impact.

Business impact

This vulnerability enables phishing and credential theft at scale. An attacker can craft a legitimate-looking Roxy-WI login link that, after the user enters credentials, silently redirects to an attacker-controlled site mimicking the login page. Organizations managing Haproxy, Nginx, Apache, or Keepalived infrastructure via Roxy-WI are exposed to compromise of their load balancer and web server configurations. Attackers gaining valid administrator or operator credentials can modify traffic routing, inject malicious content, or establish persistent access to critical web infrastructure. The impact escalates if Roxy-WI manages multiple environment tiers (staging, production) or is a shared service across teams.

Affected systems

Roxy-WI version 8.2.6.4 and all prior releases are affected. The vulnerability applies regardless of which backend systems (Haproxy, Nginx, Apache, Keepalived) are managed, as the flaw is in the web interface's authentication layer. No patch versions have been identified in public advisories at publication. Organizations running Roxy-WI must verify their deployment version against the vendor advisory and monitor for patch availability. Self-hosted and cloud-deployed instances are equally vulnerable.

Exploitability

The attack has moderate to high exploitability despite MEDIUM CVSS rating. Exploitation requires a victim to click a malicious link, but no technical sophistication is needed to craft the attack payload. The attacker simply appends [email protected]/path to the legitimate Roxy-WI login URL. Social engineering via email, messaging, or documentation can distribute the link convincingly. Once clicked, the redirect happens transparently in the browser. There are no known active exploits in the wild at publication, and the vulnerability is not on the CISA Known Exploited Vulnerabilities (KEV) catalog, but the straightforward nature of the attack makes it a plausible candidate for weaponization.

Remediation

At publication, no official patch exists. Immediate mitigation steps include: (1) implement a network policy restricting Roxy-WI access to trusted IP ranges or VPN-only endpoints, reducing the attack surface; (2) educate administrators about verifying URLs carefully before login and recognizing phishing indicators; (3) deploy browser-based URL filtering or security awareness training; (4) monitor Roxy-WI access logs for unusual redirect patterns or login anomalies. Long-term, coordinate with the Roxy-WI vendor to obtain a patched version. When patches become available, prioritize deployment to any Roxy-WI instance with external or untrusted network access.

Patch guidance

No patches have been released as of the publication date (2026-06-17). Organizations should: (1) verify the Roxy-WI version in their environment using the admin panel or system logs; (2) subscribe to vendor security advisories and the Roxy-WI GitHub repository for patch notifications; (3) maintain a deployment runbook for applying patches urgently once released; (4) test patches in a staging environment before production rollout to ensure compatibility with custom plugins or configurations. When a patch is available, apply it to all instances managed by that Roxy-WI deployment.

Detection guidance

Monitor for signs of exploitation: (1) examine HTTP referrer logs and access logs for login requests containing '@' symbols in the next parameter or query string; (2) alert on redirect responses (302, 301) that contain userinfo syntax (e.g., https://[email protected]); (3) correlate successful logins followed immediately by access to external hosts—a strong indicator of a phishing attack; (4) review browser security logs or endpoint detection and response (EDR) tools for unexpected HTTPS connections to unknown domains immediately after Roxy-WI login; (5) check Roxy-WI configuration change logs for unauthorized modifications to backend server settings or credentials that might follow a compromised login session.

Why prioritize this

Although rated MEDIUM severity, this vulnerability merits prompt attention because: (1) it directly compromises authentication to critical infrastructure management tools; (2) the attack is trivially simple to execute—no advanced exploitation knowledge required; (3) successful phishing can grant attackers control over load balancers, web servers, and traffic routing across the organization; (4) it affects all versions up to 8.2.6.4 with no known patch, leaving the entire user base exposed pending vendor remediation; (5) Roxy-WI often manages production systems, so compromise can cascade into widespread service disruption or data exfiltration. Prioritize patching once available and implement compensating controls immediately.

Risk score, explained

The CVSS 3.1 score of 6.1 reflects: Attack Vector (Network) - exploitable remotely; Attack Complexity (Low) - no special conditions or exploitation tricks needed; Privileges Required (None) - unauthenticated access possible; User Interaction (Required) - victim must click the malicious link; Scope (Changed) - impact extends beyond the vulnerable component to backend systems. Confidentiality and Integrity are marked as Low because the attacker gains sensitive information (credentials, session tokens) and can modify configurations, but Availability is unaffected by the redirect alone. The MEDIUM severity is appropriate for a phishing vector, but context matters: organizations should treat this as HIGH priority given the administrative nature of the affected application.

Frequently asked questions