In Roxy‑WI versions 8.2.6.4 and earlier, the API endpoints that manage HAProxy configuration sections accept an unvalidated JSON "option" field that is rendered directly into the generated HAProxy configuration via Jinja templates. Because the input is neither validated nor escaped, an authenticated user with role level 3 or lower can inject arbitrary HAProxy directives, including external‑check commands that execute arbitrary shell code. This flaw allows the attacker to gain remote code execution on the HAProxy process, running as the haproxy user, each time a health‑check is performed. The vulnerability is caused by improper input validation and results in command, OS command, and code injection, as identified by the listed CWEs.

The affected product is the Roxy‑WI web interface from roxy‑wi, which manages HAProxy load balancers. All deployments of Roxy‑WI version 8.2.6.4 and older that are used to configure HAProxy are vulnerable. Any user or group that has at least role level 3 access to the HAProxy section‑save API endpoints can exploit the system, potentially affecting all HAProxy instances within that management group.

The flaw carries a CVSS score of 9.9 and is considered a critical severity, even though the EPSS score is unavailable. It is not listed in the CISA KEV catalog. An attacker only needs to authenticate to the Roxy‑WI interface and send a crafted payload to the section‑save endpoints; no additional privileges on the HAProxy host are required. Once the malicious configuration is pushed and the service reloaded, the injected command executes as the haproxy user on every load‑balancing health‑check, enabling persistent remote code execution that can be leveraged for further lateral movement or data exfiltration.