What is the CVSS score of CVE-2026-45550?

CVE-2026-45550 has a CVSS 3.1 base score of 9.1 (Critical). CVSS vector: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:H/A:L. EPSS exploitation probability: 0.0%.

Which versions of Roxy-WI are affected by CVE-2026-45550?

A critical authorization flaw in Roxy-WI versions 8.2.6.4 and earlier allows authenticated users to secretly modify monitoring checks across tenants, undermining visibility and operational control in…

How to fix or mitigate CVE-2026-45550?

Within 24 hours: Audit your Roxy-WI deployment-document all instances and tenant counts to establish operational risk scope. Within 7 days: Implement network-level access controls restricting PUT /smon/check endpoints to authorized administrators only; enable detailed API logging to detect tampering attempts. Within 30 days: Monitor vendor communications for a security patch; validate patch compatibility and test in staging before production rollout.

Roxy-WI CVE-2026-45550

EUVD-2026-36037 CRITICAL

Authorization Bypass Through User-Controlled Key (CWE-639)

2026-06-10 GitHub_M

Authentication Bypass Nginx Apache

9.1

CVSS 3.1 · NVD

Severity by source

NVD PRIMARY

9.1 CRITICAL

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

Attack Vector

Network

Attack Complexity

Low

Privileges Required

Low

User Interaction

None

Scope

Changed

Confidentiality

Low

Integrity

High

Availability

Low

Lifecycle Timeline

Analysis Generated

Jun 10, 2026 - 15:14 vuln.today

CVE Published

Jun 10, 2026 - 14:00 nvd

CRITICAL 9.1

DescriptionNVD

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

News 9 New Nginx Vulnerabilities - 4 Critical, 5 High Severity Patched Jun 11, 2026 News 12 New Apache Vulnerabilities - 6 Critical, 6 High Severity Jun 11, 2026 News 11 New Apache Vulnerabilities - 4 Critical, 7 High Severity Jun 10, 2026 News Critical Cross-Tenant Data Tampering in Nginx Roxy-WI 8.2.6.4 - CVE-2026-45550 Jun 10, 2026

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.