MEDIUM 6.5

CVE-2026-45561: Roxy-WI SSRF Vulnerability in Agent Monitoring Routes

Roxy-WI, a web management interface for HAProxy, Nginx, Apache, and Keepalived servers, contains a server-side request forgery (SSRF) vulnerability in versions 8.2.6.4 and earlier. The vulnerability exists in routes used to monitor agent status, where user-supplied server IP addresses are passed directly into HTTP requests without proper validation. This allows an authenticated attacker to redirect requests to internal IP addresses (including metadata services, loopback, and private ranges) that should not be directly accessible, potentially exposing sensitive configuration data or service information.

Source data · NVD / CISA · public domain

CVSS
3.1 · 6.5 MEDIUM · CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N
Weaknesses (CWE)
CWE-918
Affected products
0 configuration(s)
Published / Modified
2026-06-10 / 2026-06-17

NVD description (verbatim)

Roxy-WI is a web interface for managing Haproxy, Nginx, Apache and Keepalived servers. In versions 8.2.6.4 and prior, the /smon/agent/{version,uptime,status,checks}/<server_ip> family of routes takes the URL path component verbatim into requests.get(f'http://{server_ip}:{agent_port}/...'). The path component is constrained only by Flask's default URL converter, which permits any value (including IPv4 literals like 169.254.169.254, RFC1918 ranges, and 127.0.0.1). At time of publication, there are no publicly available patches.

2 reference(s) · View on NVD →

SEC.co analysis · AI-assisted, reviewed against source

Technical summary

The /smon/agent/{version,uptime,status,checks}/<server_ip> endpoint family in Roxy-WI accepts the <server_ip> path parameter and interpolates it directly into requests.get(f'http://{server_ip}:{agent_port}/...') calls. While Flask's default URL converter applies basic syntactic constraints, it does not enforce IP address validation or prevent RFC1918 ranges, loopback addresses (127.0.0.1), or link-local addresses (169.254.169.254). An authenticated user can supply these addresses to force the Roxy-WI application server to make HTTP requests to internal targets, bypassing network segmentation and exposing application or system state. This is a classic SSRF pattern (CWE-918) where attacker-controlled input influences the target of an outbound request.

Business impact

In typical deployments, Roxy-WI operators manage multiple load balancers and web servers across an infrastructure. Compromise of the Roxy-WI instance itself becomes a pivot point for internal reconnaissance. An authenticated attacker—whether a legitimate operator with malicious intent, or an external actor who has gained credentials—can probe internal services, retrieve metadata that may reveal API keys or instance identities, or enumerate the network topology. This information can feed lateral movement or privilege escalation campaigns. The confidentiality risk is substantial; integrity and availability of monitored servers are not directly threatened, but operational visibility and internal security posture are undermined.

Affected systems

Roxy-WI versions 8.2.6.4 and prior are confirmed vulnerable. The vendor product list in available advisories is empty, suggesting either a standalone or limited-distribution software product. Operators should verify their deployed version against official Roxy-WI release notes. Any deployment of Roxy-WI in a multi-tier infrastructure where the application server has network access to internal services (metadata endpoints, internal APIs, management interfaces) is at risk.

Exploitability

Exploitation requires valid authentication credentials to Roxy-WI—the CVSS vector specifies PR:L (low privilege required). Unauthenticated access to the vulnerable endpoints is not possible. Once authenticated, no user interaction is needed; an attacker can craft malicious URLs directly. The network attack vector (AV:N) and low attack complexity (AC:L) mean that any authenticated user with network access can attempt exploitation immediately. No special tooling or zero-day techniques are required; standard HTTP requests suffice. At publication, no public exploits exist, but the vulnerability is straightforward to weaponize for internal reconnaissance.

Remediation

At time of publication, no official patch has been released. Operators should monitor Roxy-WI's official repository and advisory channels for a security release. In the interim, implement network-level mitigations: restrict outbound HTTP/HTTPS traffic from the Roxy-WI server to only authorized agent endpoints and ports; use egress filtering or a proxy to block requests to RFC1918 ranges, loopback, and link-local addresses; and limit administrative access to Roxy-WI to trusted operators. Consider running Roxy-WI in a network segment that does not have direct visibility to sensitive internal services or metadata endpoints.

Patch guidance

No patches are available as of the publication and modification dates (June 10 and June 17, 2026). Check the official Roxy-WI GitHub repository and security advisories for updates. When a patch is released, verify the version number against the advisory and test in a non-production environment before deploying. Given the authentication requirement, prioritize patching instances exposed to untrusted users or shared administrative teams.

Detection guidance

Monitor HTTP request logs from the Roxy-WI application for requests to /smon/agent/* endpoints where the <server_ip> parameter contains RFC1918 addresses (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16), loopback (127.0.0.1), or link-local addresses (169.254.x.x). Track outbound HTTP connections from the Roxy-WI server to internal IP ranges, especially on non-standard ports or to known metadata services. Review access logs for unusual authentication patterns or privilege-escalation attempts preceding SSRF activity. Implement alerting on suspicious agent endpoint queries; legitimate monitoring queries should target only production agent endpoints.

Why prioritize this

This is a MEDIUM severity vulnerability (CVSS 6.5) with a legitimate but constrained attack surface. Authentication is required, which limits exposure in well-controlled environments. However, in organizations with loose credential hygiene or shared administrative accounts, the risk is elevated. The vulnerability is simple to exploit and has high information disclosure value, making it attractive for reconnaissance. Given the lack of a patch and the need for immediate mitigation, this should be addressed within 30 days in high-risk deployments (those with internal metadata or sensitive API endpoints accessible from the Roxy-WI network segment) and within 60 days in lower-risk environments.

Risk score, explained

The CVSS 3.1 score of 6.5 (MEDIUM) reflects high confidentiality impact (C:H) but no integrity or availability impact. The authentication requirement (PR:L) prevents unauthenticated exploitation. The network attack vector and low complexity acknowledge that any authenticated user can exploit this immediately. The score appropriately captures the reconnaissance and internal-pivoting risk without overstating direct harm to managed services. In organizations where Roxy-WI has elevated privileges or broad internal network access, internal risk assessments may justify a higher prioritization than the base CVSS suggests.

Frequently asked questions

Can an unauthenticated attacker exploit this?

No. The CVSS vector specifies PR:L (low privilege required), meaning a valid Roxy-WI account is necessary. However, in deployments where credentials are shared, leaked, or assigned to contractors, the effective attack surface may be larger.

What version of Roxy-WI am I running, and how do I check?

Log into the Roxy-WI web interface and check the footer or Settings menu for version information. Alternatively, inspect the GitHub repository's releases page or your installation directory. Versions 8.2.6.4 and prior are vulnerable.

If I restrict network access from Roxy-WI to internal services, am I safe?

Egress filtering and network segmentation significantly reduce risk by preventing the application from reaching internal targets even if exploited. However, do not rely on this alone—apply a patch as soon as one is available and follow the principle of least privilege for credentials and network permissions.

Is this vulnerability being actively exploited in the wild?

No indication of active exploitation has been reported as of the publication date. However, given the straightforward nature of SSRF attacks and the relative simplicity of exploitation, defenders should assume that once disclosure occurs, weaponized use is likely.

This analysis is based on published vulnerability information available as of the modification date (June 17, 2026) and vendor advisories. Patch availability, affected versions, and remediation timelines may change; verify all version numbers and patch guidance directly with official Roxy-WI sources. This page is for informational purposes and does not constitute professional security advice. Organizations should conduct their own risk assessments and consult with security teams before implementing mitigations. SEC.co makes no warranty regarding the accuracy, completeness, or timeliness of this content. Source: NVD (public-domain), retrieved 2026-07-19. Analysis generated by SEC.co (claude-haiku-4-5).