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

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

Roxy-WI CVE-2026-45561

EUVD-2026-36042 MEDIUM

Server-Side Request Forgery (SSRF) (CWE-918)

2026-06-10 GitHub_M

Python Nginx SSRF Apache

6.5

CVSS 3.1 · NVD

Severity by source

NVD PRIMARY

6.5 MEDIUM

AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N

Primary rating from NVD · only source for this CVE.

CVSS VectorNVD

CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N

Attack Vector

Network

Attack Complexity

Low

Privileges Required

Low

User Interaction

None

Scope

Unchanged

Confidentiality

High

Integrity

None

Availability

None

Lifecycle Timeline

Analysis Generated

Jun 10, 2026 - 15:29 vuln.today

CVE Published

Jun 10, 2026 - 14:03 nvd

MEDIUM 6.5

DescriptionNVD

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.

AnalysisAI

{version,uptime,status,checks}/<server_ip> route family passes the Flask URL path parameter directly into a Python requests.get()` call without any allowlist or blocklist validation, making IPv4 literals such as 169.254.169.254, RFC1918 ranges, and 127.0.0.1 all valid targets. No publicly available patches exist at time of analysis, and no public exploit code or CISA KEV listing has been identified.

Technical ContextAI

Roxy-WI is a Python/Flask-based web management interface for proxy and load-balancer daemons including Haproxy, Nginx, Apache, and Keepalived. The vulnerable code uses Python's requests library with f-string interpolation: requests.get(f'http://{server_ip}:{agent_port}/...'), where server_ip is pulled directly from the Flask route variable <server_ip>. Flask's default URL converter applies no address-family or range constraints to path parameters, so any string - including link-local 169.254.169.254 (the AWS/GCP/Azure Instance Metadata Service endpoint), RFC1918 private ranges, and loopback addresses - is accepted and forwarded. CWE-918 (Server-Side Request Forgery) is the root cause class: the application acts as an uninstrumented HTTP proxy, issuing outbound requests to attacker-controlled internal destinations without validating that the target is a legitimate, externally-routable agent host. The CPE string cpe:2.3:a:roxy-wi:roxy-wi:*:*:*:*:*:*:*:* flags the entire product line with no fixed upper version bound.

RemediationAI

No vendor-released patch has been identified at time of analysis - the advisory explicitly states no publicly available patches exist at publication. Monitor https://github.com/roxy-wi/roxy-wi/security/advisories/GHSA-2crj-7rqc-x7rq and the upstream repository for a patched release. As compensating controls: first, implement egress firewall rules on the Roxy-WI host to block outbound HTTP/TCP connections to 169.254.169.254, all RFC1918 ranges (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16), and 127.0.0.1 originating from the application process - note this may disrupt legitimate agent monitoring if agents reside on internal addresses, so audit agent IP ranges before applying. Second, restrict access to the Roxy-WI web interface to trusted network segments or VPN-authenticated users only, reducing the pool of accounts that can trigger the vulnerable routes. Third, if the /smon/agent/ route family is not required, block it via a reverse proxy ACL (e.g., nginx deny directive on /smon/agent/) - this is the most effective near-term control with minimal functional trade-off if agent monitoring is unused. Fourth, for AWS-hosted deployments, enforce IMDSv2 (requiring a PUT-based session token before GET requests are honored), which prevents simple single-request metadata retrieval and significantly raises the bar for SSRF-based credential theft, though it does not eliminate the underlying vulnerability.