Severity by source
AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:H/A:L
Primary rating from NVD · only source for this CVE.
CVSS VectorNVD
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:H/A:L
Lifecycle Timeline
2DescriptionNVD
Roxy-WI is a web interface for managing Haproxy, Nginx, Apache and Keepalived servers. In versions 8.2.6.4 and prior, PUT /smon/check (app/routes/smon/routes.py:117-138) gates only on roxywi_common.check_user_group_for_flask() - which validates that the caller has some group, not that the target check_id belongs to it. The downstream SQL update functions update_smon, update_smonHttp, update_smonTcp, update_smonPing, update_smonDns (app/modules/db/smon.py:515-562) all execute WHERE smon_id = ? with no user_group filter. The DELETE path is correctly filtered (app/modules/db/smon.py:319-327 does WHERE id = ? AND user_group = ?), demonstrating that the maintainers know the right pattern but did not apply it on UPDATE. Therefore any authenticated user can iterate over smon_id values and silently rewrite any other tenant's HTTP / TCP / Ping / DNS monitoring check. At time of publication, there are no publicly available patches.
Articles & Coverage 4
AnalysisAI
Cross-tenant data tampering in Roxy-WI versions 8.2.6.4 and prior allows any authenticated user to silently overwrite HTTP, TCP, Ping, and DNS monitoring checks belonging to other tenants by sending a crafted PUT /smon/check request with another tenant's smon_id. The flaw stems from missing user_group authorization on the UPDATE SQL path (CWE-639, IDOR), while the DELETE path is correctly filtered - confirming the maintainers knew the right pattern but failed to apply it on update. No public exploit identified at time of analysis, and no vendor-released patch is available, raising operational risk for multi-tenant deployments.
Technical ContextAI
Roxy-WI is a Python/Flask web interface for managing HAProxy, Nginx, Apache, and Keepalived clusters, including its own SMON (Service Monitor) subsystem for HTTP/TCP/Ping/DNS health checks. The vulnerable code path is in app/routes/smon/routes.py:117-138, where the PUT /smon/check handler relies solely on roxywi_common.check_user_group_for_flask() - a coarse check that confirms the caller belongs to some group but never validates that the target check_id belongs to the caller's group. The downstream update_smon, update_smonHttp, update_smonTcp, update_smonPing, and update_smonDns functions in app/modules/db/smon.py:515-562 issue SQL UPDATE statements scoped only by WHERE smon_id = ?, with no user_group predicate. This is the textbook CWE-639 Authorization Bypass Through User-Controlled Key pattern: a server-side object reference (smon_id) is trusted from the client without an ownership check.
RemediationAI
No vendor-released patch identified at time of analysis; the GitHub Security Advisory GHSA-856h-mvm2-2h2x (https://github.com/roxy-wi/roxy-wi/security/advisories/GHSA-856h-mvm2-2h2x) confirms the issue but does not yet list a fixed version. Until a patched release is published, operators should treat all authenticated Roxy-WI users as trusted within the SMON scope, which is impractical for multi-tenant installs - so the recommended compensating controls are: restrict /smon/check (PUT) at a reverse proxy or WAF to administrator IP ranges only, accepting that legitimate tenants will lose self-service edit capability; segregate tenants into separate Roxy-WI instances if multi-tenancy is required; and enable database-level audit logging on the smon tables so unauthorized rewrites can at least be detected and reverted. As a code-level workaround for operators willing to maintain a local fork, mirror the DELETE path's WHERE id = ? AND user_group = ? predicate (app/modules/db/smon.py:319-327) into the update_smon/update_smonHttp/update_smonTcp/update_smonPing/update_smonDns functions at app/modules/db/smon.py:515-562 - note this may break legitimate cross-group admin edits and should be validated against your role model.
The ngx_http_parse_chunked function in http/ngx_http_parse.c in nginx 1.3.9 through 1.4.0 allows remote attackers to cau
A critical vulnerability in Kubernetes ingress-nginx controller allows unauthenticated attackers with pod network access
nginx 0.8.41 through 1.4.3 and 1.5.x before 1.5.7 allows remote attackers to bypass intended restrictions via an unescap
An issue was discovered on GL.iNet devices before version 4.5.0. Rated critical severity (CVSS 9.8), this vulnerability
Nginx versions since 0.5.6 up to and including 1.13.2 are vulnerable to integer overflow vulnerability in nginx range fi
The resolver in nginx before 1.8.1 and 1.9.x before 1.9.10 allows remote attackers to cause a denial of service (invalid
Kubernetes ingress-nginx contains a configuration injection vulnerability via the mirror-target and mirror-host Ingress
A security issue was discovered in ingress-nginx https://github.com/kubernetes/ingress-nginx where the `auth-url` Ingres
A security issue was discovered in ingress-nginx https://github.com/kubernetes/ingress-nginx where the `auth-tls-match-c
Roxy-WI is a web interface for managing Haproxy, Nginx, Apache and Keepalived servers. Rated critical severity (CVSS 9.8
The STARTTLS implementation in mail/ngx_mail_smtp_handler.c in the SMTP proxy in nginx 1.5.x and 1.6.x before 1.6.1 and
Heap buffer overflow in NGINX Plus and NGINX Open Source ngx_http_rewrite_module allows remote attackers to crash worker
Same technique Authentication Bypass
View allShare
External POC / Exploit Code
Leaving vuln.today
EUVD-2026-36037