CVE-2026-45552: Critical Authorization Bypass in Roxy-WI
| Field | Value |
|---|---|
| CVE ID | CVE-2026-45552 |
| CVSS score | 9.9 |
| Attack vector | Authenticated authorization bypass |
| Auth required | Yes, any valid authenticated user, including guest role |
| Patch status | No publicly available patch confirmed by NVD at publication time |
TL;DR - Authenticated Roxy-WI users can reach sensitive
/install/*actions without proper role or tenant checks. - Affects Roxy-WI8.2.6.4 and prior; investigate8.2.6.5as a likely remediation lead, but fix confirmation is not explicit. - Treat as urgent in multi-tenant deployments or anywhere Roxy-WI stores privileged SSH credentials.
What is CVE-2026-45552 and why it matters
CVE-2026-45552 is a critical authorization bypass in Roxy-WI, the web management interface used to administer HAProxy, Nginx, Apache, and Keepalived infrastructure. According to the NVD description, the flaw exists because several install-related endpoints under the install blueprint are protected only by @jwt_required() and are missing the expected role enforcement and tenant or group ownership checks. That means the application verifies that the caller is logged in, but does not properly verify whether that user should be allowed to operate on the requested server.
This matters because the exposed functionality is not low-risk metadata access. The vulnerable endpoints can trigger installation and reconfiguration workflows for exporters, WAF components, and GeoIP data. In Roxy-WI, those actions are executed through Ansible using per-server SSH credentials stored in the platform. If those credentials were provisioned with sudo rights, an otherwise low-privileged user could effectively cause privileged changes on managed systems outside their own tenant scope.
The issue is especially serious in shared or multi-tenant environments. The NVD record explicitly states that any logged-in user, including the default guest role, may be able to invoke these actions across every server registered in the Roxy-WI database, regardless of ownership. That turns what might look like a web authorization bug into a potential cross-environment management-plane compromise.
At disclosure time, there is no confirmed public vendor patch statement in the NVD text. That uncertainty raises operational risk for defenders because the usual containment path, patch immediately, is not fully settled from primary advisory text. In the absence of a definitive fix advisory, assume the issue is exploitable anywhere affected versions are deployed and exposed to low-trust authenticated users.
Affected products and version ranges
The NVD record states that Roxy-WI versions 8.2.6.4 and prior are affected. That is the clearest affected version range available from the primary vulnerability source included in the research note. If your deployment is on 8.2.6.4, 8.2.6.3, or any earlier branch still in use, it should be considered exposed unless you have independently verified custom access-control hardening or backported fixes.
The fix version is less straightforward. The NVD description says that at the time of publication, there are no publicly available patches. Separately, the Roxy-WI changelog shows a release v8.2.6.5 dated 15.05.2026 with the generic note “A lot of security issues have been fixed.” That is useful as a remediation lead, but it is not an explicit confirmation that CVE-2026-45552 is fixed in 8.2.6.5. Practitioners should avoid overstating that relationship.
In practical terms, defenders should use the following working assumptions:
| Version | Status based on available sources |
|---|---|
8.2.6.4 and prior |
Explicitly affected |
8.2.6.5 |
Possible remediation candidate, but not explicitly confirmed as the fix version for this CVE |
| Later versions | Unknown from the provided primary sources; verify via release notes, commit history, or vendor confirmation |
If you cannot validate the exact fix version, treat all deployments on 8.2.6.4 and earlier as vulnerable and prioritize containment. For 8.2.6.5 or later, do not assume safety solely from a generic changelog entry. Validate whether the missing decorators and group-scope checks were actually added to the affected endpoints.
Technical root cause and attack path
Per the NVD description, the vulnerable install blueprint uses @jwt_required() in app/routes/install/routes.py, but individual endpoints are not wrapped in page_for_admin and do not call roxywi_common.is_user_has_access_to_its_group(server_ip) or check_is_server_in_group(server_ip). In plain terms, login is enforced, but authorization is not consistently enforced at the endpoint level.
The NVD record specifically names the following vulnerable functions or routes:
install_exporterinstall_wafinstall_geoipcheck_geoipget_exporter_versionget_task_status
Only the GET index page install_monitoring is described as gated by roxywi_auth.page_for_admin(level=2). That asymmetry is the core defect. It is common in web applications for the visible page to be permission-checked while the API actions behind it are insufficiently protected. Attackers do not need the UI if they can call backend endpoints directly with a valid session or JWT.
Technical Notes
The missing control pattern described by NVD can be summarized like this:
# Simplified vulnerable pattern
@bp.before_request
@jwt_required()
def before_request():
pass
@bp.route("/install/exporter", methods=["POST"])
def install_exporter():
# no page_for_admin
# no is_user_has_access_to_its_group(server_ip)
# no check_is_server_in_group(server_ip)
run_ansible_playbook()
A safer pattern would enforce both role and server-scope checks on each sensitive action:
@bp.route("/install/exporter", methods=["POST"])
@page_for_admin(level=2)
def install_exporter():
server_ip = request.json["server_ip"]
check_is_server_in_group(server_ip)
if not roxywi_common.is_user_has_access_to_its_group(server_ip):
abort(403)
run_ansible_playbook()
Because the backend uses stored per-server SSH credentials, the likely attack path is straightforward: obtain any valid account, enumerate server identifiers or IPs known to the platform, then invoke install or reconfiguration actions against assets outside the attacker’s tenant. The application becomes a proxy for privileged automation.
CVSS score and risk interpretation
CVE-2026-45552 has a CVSS score of 9.9, which places it in the critical range. The exact vector string was not returned in the source material provided, so defenders should avoid inferring components that are not explicitly published. Even without the full vector, the severity aligns with the combination of low attack complexity, authenticated reachability, and potentially high impact on confidentiality, integrity, and availability of managed servers.
The most important operational nuance is that this is not unauthenticated internet-wide code execution. Some teams may be tempted to downgrade urgency because valid login is required. That would be a mistake in environments where guest accounts exist, self-service onboarding is enabled, shared tenants are used, or credentials can be phished or reused from other breaches. “Authenticated” does not mean “low risk” when the authenticated role can be as weak as guest.
The risk also scales with how Roxy-WI is deployed. If the platform stores SSH credentials with sudo access to production servers, successful abuse can become a management-plane compromise. If it is single-tenant and tightly restricted to a handful of trusted admins, exposure is narrower but still significant because a compromised low-privilege account may become enough to pivot into infrastructure control.
Exploitation status, PoC status, and what defenders should assume
At the time of this writing, exploitation in the wild is not confirmed from the provided sources. The CVE is not listed in CISA’s Known Exploited Vulnerabilities catalog, which means there is no CISA-backed confirmation of active exploitation. That is useful context, but it should not be treated as evidence of safety.
Also based on the provided research note, no public proof-of-concept is known from the sources checked. A GitHub security advisory exists for the project and describes the issue, but that is not the same as public exploit code. So the most accurate status is:
| Signal | Status |
|---|---|
| Confirmed exploitation in the wild | No confirmed evidence from KEV |
| Public PoC exploit | None known from the provided sources |
| Public advisory | Yes, GitHub advisory and NVD entry |
In the absence of a known PoC, defenders should assume the barrier to exploitation is still relatively low. The vulnerability description is specific enough that a capable attacker or internal tester could reproduce the issue by inspecting the affected routes and trying cross-tenant requests. For practical prioritization, treat it as high-likelihood abuse in environments where low-privileged accounts are common.
How to detect attempted or successful exploitation
Detection should focus on authenticated requests to install-related endpoints by unexpected users, especially guest or low-privilege accounts, and on follow-on automation activity targeting servers outside the caller’s assigned group. Because the vulnerability is an authorization flaw, successful exploitation may not generate obvious application errors. A normal-looking 200 or task-creation response can still indicate abuse.
Start by identifying whether your Roxy-WI deployment logs request paths, usernames, source IPs, JWT subjects, and target server identifiers. If it does, baseline legitimate use of /install/* functionality. In many environments, only a narrow set of admin accounts should access these routes. Any guest-role or non-admin access should be considered suspicious until explained.
Technical Notes
Example HTTP path patterns to review in reverse proxy, web app, or application logs:
/install/exporter
/install/waf
/install/geoip
/install/check_geoip
/install/get_exporter_version
/install/get_task_status
A simple grep approach for text-based logs:
grep -E '(/install/exporter|/install/waf|/install/geoip|/install/check_geoip|/install/get_exporter_version|/install/get_task_status)' /var/log/nginx/access.log
Example suspicious pattern to look for in access logs, especially if tied to a non-admin or guest user context:
POST /install/exporter HTTP/1.1" 200
POST /install/waf HTTP/1.1" 200
POST /install/geoip HTTP/1.1" 200
If logs include authenticated user metadata, flag any install-route access by users outside your admin set. Example Splunk-style query:
index=web_logs (uri_path="/install/exporter" OR uri_path="/install/waf" OR uri_path="/install/geoip" OR uri_path="/install/check_geoip" OR uri_path="/install/get_exporter_version" OR uri_path="/install/get_task_status")
| stats count values(uri_path) values(src_ip) values(http_method) by user
| lookup authorized_roxywi_admins user OUTPUT user as authorized_user
| where isnull(authorized_user)
At the system level, correlate suspicious web requests with Ansible or SSH execution from the Roxy-WI host. If the platform launches playbooks or outbound SSH immediately after one of these requests, that is a strong indicator of successful abuse. Review shell history, process execution telemetry, and outbound connections from the Roxy-WI server to managed nodes.
Mitigation and patching guidance
Because the NVD record says no publicly available patch was available at publication time, mitigation has to balance immediate containment with version-upgrade validation. The safest immediate step is to restrict who can authenticate to Roxy-WI at all. Disable guest or low-trust accounts, enforce SSO or MFA if available, and lock the application behind a VPN or administrative network path until you confirm remediation.
You should also review what credentials Roxy-WI stores for managed servers. If those accounts have broad sudo rights, the blast radius is larger. Reduce privilege where feasible, rotate credentials after suspected abuse, and segment environments so one Roxy-WI tenant cannot implicitly administer another tenant’s servers through shared automation infrastructure.
On versioning, investigate upgrade to 8.2.6.5 or later because it is the nearest post-affected release with generic security-fix language. However, do not document 8.2.6.5 internally as the confirmed fix for CVE-2026-45552 unless you verify the code changes or receive explicit vendor confirmation. If upgrade is not immediately possible, add compensating controls at the reverse proxy or WAF layer to block access to the named endpoints for non-admin users.
Technical Notes
If you are using a package-managed deployment, first identify the installed version:
roxy-wi --version
If your deployment is managed via Git, capture the current revision before upgrading:
cd /opt/roxy-wi
git rev-parse HEAD
git tag --list | tail
Where your operational process allows, update to the next available security-maintenance release and verify authorization controls on the affected routes. The exact upgrade method depends on how Roxy-WI was installed, so use your documented package or Git workflow rather than a guessed command. If your team has standardized deployment automation, update through that pipeline and test with a non-admin account.
As an immediate workaround, restrict the vulnerable paths at the web server or reverse proxy to approved admin source ranges or identities. Example Nginx-style path restriction concept:
location ~ ^/install/(exporter|waf|geoip|check_geoip|get_exporter_version|get_task_status)$ {
allow 10.0.0.0/8;
deny all;
}
If you can enforce application-layer policy upstream, require administrative identity claims for these routes until the application itself is verified fixed. Also consider temporarily disabling guest accounts and any tenant self-registration workflows.
What to do next
First, inventory every Roxy-WI instance and identify whether it is running 8.2.6.4 or prior. If yes, classify it as affected. Then determine whether the deployment is multi-tenant, whether guest accounts exist, and whether stored SSH credentials have sudo rights. Those three answers will tell you how urgent containment is in your environment.
Second, examine logs for historical access to the named /install/* endpoints by non-admin users. If you find suspicious use, assume follow-on server changes may have occurred through Ansible or SSH and expand the investigation to the managed nodes targeted around the same time. Rotate stored credentials if compromise is plausible.
Third, validate your remediation path. If you plan to move to 8.2.6.5 or later, verify the fix in code or by test: a guest or low-privilege user should receive a hard denial when attempting to access install-related routes for any server, especially servers outside their group. Until then, compensating controls are warranted.
References
- NVD CVE record: CVE-2026-45552
- GitHub Security Advisory: GitHub Advisory
- Roxy-WI changelog: Changelog
- CISA KEV catalog: CISA KEV
For further reading on multi-tenant security, check out our article on the best enterprise password managers with SSO and learn more about OpenID Connect (OIDC).
This article may contain affiliate links. We earn a commission on qualifying purchases at no extra cost to you.