Roxy-WI CVE-2026-45550

The attacker must hold valid credentials for any Roxy-WI account in any user group on the target instance (CVSS PR:L), and the Roxy-WI web UI must be reachable from the attacker's network position (AV:N). No user interaction by the victim is required (UI:N), and exploitation works against default Roxy-WI 8.2.6.4 and prior configurations - there is no feature flag or non-default setting that must be enabled, because the vulnerable PUT /smon/check route and the missing user_group filter on update_smon* are present in the standard codebase. The primary limiting factor is the authentication requirement (PR:L) plus knowledge or enumeration of valid smon_id integers, which are sequential and therefore not a meaningful barrier.

The CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:H/A:L, score 9.1) reflects network-reachable, low-complexity exploitation by any low-privileged authenticated user, with scope change (cross-tenant impact) and high integrity damage - consistent with multi-tenant IDOR. EPSS and CISA KEV data were not provided in the input, and no public exploit is identified at time of analysis, so probabilistic exploitation signals are unknown. The real-world priority is nonetheless elevated for any multi-tenant Roxy-WI deployment because (a) prerequisites are minimal - only a valid login is needed; (b) smon_id values are sequential integers trivially enumerable; (c) no vendor-released patch is available, so defenders cannot simply upgrade; and (d) silent tampering with health-check definitions can mask outages or trigger false alerts without triggering obvious audit trails. The scope-change rating is appropriate because data in another tenant's authorization boundary is affected.

A low-privileged tenant user authenticates to Roxy-WI, then iterates smon_id values (1, 2, 3, …) via PUT /smon/check, rewriting each victim tenant's HTTP/TCP/Ping/DNS check definitions - for example, pointing a competitor's production health check at a benign always-up endpoint so a real outage goes undetected, or rewriting DNS check parameters to generate spurious paging alerts. Because the DB UPDATE succeeds silently with no cross-tenant access log entry, the victim tenant may not notice until monitoring fails them in production. No public exploit is identified at time of analysis, but the attack requires only a single HTTP request per target and is trivially scriptable.