Roxy Wi CVE-2026-33432

LDAP authentication must be explicitly enabled in Roxy-WI configuration - this is a deployment-specific setting not enabled by default in all installations. The vulnerable code path in app/modules/roxywi/auth.py is only executed when the application is configured to authenticate against an LDAP directory server rather than using local user database. Organizations using local authentication, OAuth, SAML, or other authentication backends are not affected. No other limiting factors apply: exploitation is remote unauthenticated (AV:N/PR:N) against the default login interface with no user interaction required (UI:N) and low attack complexity (AC:L). The vulnerability affects all versions through 8.2.8.2 regardless of underlying platform, managed service types (Haproxy/Nginx/Apache/Keepalived), or network deployment architecture. Once LDAP mode is confirmed, exploitation succeeds against default configurations with no special privileges, non-default settings, or user interaction needed.

This represents a critical real-world risk despite the 7.7 CVSS score. The attack vector is network-based (AV:N) with low complexity (AC:L), requires no privileges (PR:N) or user interaction (UI:N), and proof-of-concept code exists (E:P in CVSS 4.0 vector). The vulnerability provides a complete authentication bypass - attackers gain full application access controlling production infrastructure (Haproxy/Nginx/Apache/Keepalived) without any credentials. However, exploitation is LIMITED to deployments where LDAP authentication is explicitly enabled (non-default configuration in many installations). The VI:H (high integrity impact) reflects complete compromise of the management interface, granting attackers ability to reconfigure critical network infrastructure, modify load balancer rules, redirect traffic, or cause denial of service across managed systems. The zero confidentiality/availability impact (VC:N/VA:N) in the vector appears inconsistent with real-world consequences - access to infrastructure management interfaces typically enables data exfiltration and service disruption. No EPSS score or CISA KEV listing provided, but proof-of-concept availability and the zero-authentication nature make this immediately exploitable once LDAP mode is discovered. Primary risk mitigation factor: many Roxy-WI deployments may use local authentication rather than LDAP, reducing exposed attack surface. Organizations using LDAP integration face immediate risk with no vendor patch available.

An external attacker identifies a Roxy-WI installation managing production load balancers at target.com. The login page reveals LDAP authentication is enabled (often visible in error messages or login form behavior). The attacker submits username '*)(objectClass=*))(|(cn=' with any password value. The injected metacharacters break out of the intended LDAP filter query, creating a tautological condition that returns the first user object from the directory. The authentication logic validates this returned entry rather than verifying credentials, granting the attacker administrative access to the Roxy-WI console without knowing any valid username or password. With administrative control, the attacker reconfigures Haproxy backends to redirect customer traffic to attacker-controlled servers for credential harvesting, or modifies Nginx configurations to inject malicious JavaScript into proxied web applications. Proof-of-concept code exists making exploitation straightforward for attackers with basic LDAP injection knowledge.