CVE-2026-45556: Roxy-WI Authenticated Path Traversal to Root RCE
Critical CVSS (9.9) reachable over network.
TL;DR - Critical Roxy-WI flaw enables arbitrary file write via WAF rule save. - Affected: Roxy-WI “8.2.6.4 and prior”; authenticated users should be treated as high risk. - Urgent: root RCE is possible by writing a cron file on managed load balancers.
| Field | Value |
|---|---|
| CVE ID | CVE-2026-45556 |
| CVSS score | 9.9 |
| Attack vector | Network, via Roxy-WI web endpoint |
| Auth required | Yes, authenticated access required |
| Patch status | A fix is implied to exist after “8.2.6.4 and prior,” but the exact fixed version was not confirmed in the primary-source text available here |
Vulnerability at a Glance
CVE-2026-45556 is a critical remote code execution vulnerability in Roxy-WI, the web management interface used to administer HAProxy, Nginx, Apache, and Keepalived infrastructure. The issue sits in the WAF rule save workflow and stems from inadequate validation of a user-controlled file path. According to the NVD description, the vulnerable endpoint is POST /waf/<service>/<server_ip>/rule/<rule_id>/save, where the config_file_name form field is passed into an internal file-handling routine.
The practical impact is more serious than a typical path traversal bug because the attacker-controlled request body is written verbatim to the chosen destination path. NVD specifically notes that an attacker can target /etc/cron.d/ and place a malicious cron file there. Once cron processes that file, commands can execute as root on the load balancer host. In operational terms, this turns an authenticated web request into root-level code execution on infrastructure managed through Roxy-WI.
What is Vulnerable and What is Fixed
The affected version range explicitly called out in the available primary-source text is “8.2.6.4 and prior.” For defenders, that means you should treat Roxy-WI <= 8.2.6.4 as vulnerable until proven otherwise in your own package inventory, container tag metadata, or upstream release documentation.
The exact fixed version number was not stated in the source material available for this article. That matters because defenders often need a precise target for change management. In the absence of a directly verified fixed version, the safest statement is: upgrade to a Roxy-WI release newer than 8.2.6.4 only after confirming the vendor or upstream advisory explicitly marks it as containing the fix. If you cannot immediately verify the fixed release, assume your current deployment remains at risk and apply compensating controls now.
Why This Matters Operationally
This vulnerability is authenticated, so some teams may initially downplay it compared with unauthenticated internet-facing RCEs. That would be a mistake. Roxy-WI is an administrative plane for critical network services, and authenticated access in such platforms is already high impact. Any compromise of a legitimate user account, weak RBAC design, shared credentials, stale admin accounts, or exposed single-factor login can turn this into a direct path to root execution.
The NVD description also says the impact can extend to every load balancer the caller’s group manages. That makes the blast radius potentially larger than a single host compromise. If Roxy-WI is used to orchestrate multiple HAProxy, Nginx, Apache, or Keepalived systems, one abused account could become a pivot point for widespread persistence, service disruption, traffic interception, or credential harvesting across your load-balancing estate.
How the Exploit Works
At a high level, the flaw is a path traversal and arbitrary file write bug in the WAF rule save endpoint. The vulnerable parameter is config_file_name. Based on the NVD description, validation is too weak: it only checks whether the path contains certain service-related substrings such as nginx, haproxy, apache2, httpd, or keepalived, plus conf or cfg, and rejects .... That is not sufficient to constrain writes to a safe directory.
An additional weakness makes exploitation more practical: the application reportedly substitutes 92 with / before applying its substring checks. That lets an attacker build an absolute path that still satisfies the simplistic validation rules. NVD gives a concrete example: 92etc92cron.d92nginx_cfg_evil, which resolves to /etc/cron.d/nginx_cfg_evil. Because the config form field is written verbatim to that path, the attacker can place a cron entry and wait for cron to execute it as root.
Technical Notes
A request pattern defenders should understand looks conceptually like this:
POST /waf/nginx/10.0.0.10/rule/123/save HTTP/1.1
Host: roxywi.example
Content-Type: application/x-www-form-urlencoded
Cookie: session=<redacted>
config_file_name=92etc92cron.d92nginx_cfg_evil&config=* * * * * root /bin/bash -c 'id >/tmp/pwned'
The exact parameter names and route structure above align with the NVD description, but defenders should validate them against their own deployment, reverse proxy logs, and application logs before writing production detections.
Exploitation Status, PoC Status, and What to Assume
As of the research context provided for this article, CISA KEV does not list CVE-2026-45556. That means there is no KEV-based confirmation of exploitation in the wild at this time. This is useful signal, but it should not be treated as a safety guarantee. KEV is a lagging operational list, not a complete catalog of all active exploitation.
There is also no public proof-of-concept confirmed from the sources used here. The NVD text appears to indicate that there were no publicly available exploit artifacts at publication time, but the retrieved description was truncated before the sentence completed. Because of that truncation, the most accurate statement is: no public PoC is confirmed here, and no in-the-wild exploitation is confirmed here. In the absence of stronger data, defenders should assume exploit development is straightforward because the NVD description is technically detailed and includes a workable attack path.
What Defenders Should Do Next
First, inventory every Roxy-WI instance and identify whether it is at version 8.2.6.4 or earlier. Do not stop at the management server itself; identify every managed load balancer in scope because the likely impact zone is broader than the UI host. Then review who can authenticate, what groups they belong to, and whether any accounts show suspicious recent activity.
Second, verify the upstream fix version from the official advisory, patch on an emergency timeline, and conduct a compromise assessment. Specifically check for unauthorized files in /etc/cron.d/, unexplained root-level command execution, unexpected service restarts, or outbound network traffic from load balancers after administrative actions in Roxy-WI. Where evidence is incomplete, assume the possibility of abuse and keep monitoring in place after patching.
For further information on securing your network, you can read our article on how to secure your home Wi-Fi network or learn about the difference between Red Team and Pen Testing.
Detection and Triage
Start by reviewing all access to the vulnerable endpoint pattern: /waf/<service>/<server_ip>/rule/<rule_id>/save. Even if your current logging is incomplete, reverse proxy logs, WAF logs, and application access logs may still preserve URI, authenticated user, source IP, response code, and request timing. Focus especially on requests followed closely by unexpected config writes, cron activity, or restarts on managed nodes.
You should also inspect managed load balancers for unauthorized files under /etc/cron.d/, especially names containing service keywords and cfg or conf substrings. Look for recently created cron entries, suspicious one-liners invoking shell interpreters, curl, wget, python, perl, nc, bash redirection, or outbound callbacks. Because the attack path writes arbitrary content, indicators may vary widely between intrusions.
Technical Notes
Concrete hunting patterns you can use right away:
Web and reverse proxy log grep for the vulnerable route
grep -R -E 'POST /waf/(nginx|haproxy|apache2|httpd|keepalived)/.*/rule/.*/save' /var/log/nginx/ /var/log/apache2/ 2>/dev/null
Suspicious payload markers in HTTP logs or app logs
grep -R -E 'config_file_name=.*92etc92cron\.d92|config_file_name=.*/etc/cron\.d/|config_file_name=.*cron\.d.*(cfg|conf)' /var/log 2>/dev/null
Find recently modified cron drop-ins
find /etc/cron.d -type f -mtime -14 -ls
grep -R -nE '(curl|wget|bash -c|nc |python|perl|/dev/tcp/)' /etc/cron.d
Example Sigma-style detection logic
title: Roxy-WI WAF save endpoint possible cron drop attempt
logsource:
category: webserver
detection:
selection_uri:
cs-method: POST
cs-uri-stem|contains:
- "/waf/nginx/"
- "/waf/haproxy/"
- "/waf/apache2/"
- "/waf/httpd/"
- "/waf/keepalived/"
selection_uri2:
cs-uri-stem|contains: "/rule/"
selection_uri3:
cs-uri-stem|endswith: "/save"
keywords:
cs-uri-query|contains:
- "92etc92cron.d92"
- "/etc/cron.d/"
- "config_file_name="
condition: selection_uri and selection_uri2 and selection_uri3 and keywords
level: high
If you do not log request bodies or form parameters, assume detections will miss some attempts. In that case, prioritize host-based inspection of /etc/cron.d/, process execution telemetry, and any outbound connections originating from the load balancer shortly after administrative activity in Roxy-WI.
Mitigation and Patching
The primary remediation is to upgrade from affected versions “8.2.6.4 and prior” to a verified fixed release newer than 8.2.6.4. Because the exact fixed version number was not confirmed in the source material used here, do not guess. Verify the release in the upstream GitHub advisory or project release notes before implementing at scale. If you cannot immediately validate the fixed version, treat this as an urgent exposure and reduce risk through access control and monitoring.
Compensating controls matter here because exploitation requires authentication. Restrict Roxy-WI access to a tightly controlled admin network or VPN, enforce MFA if available in your environment, review all local and federated accounts with access, remove stale accounts, and audit group memberships that can manage load balancers. If feasible, place a temporary reverse-proxy rule or WAF rule in front of Roxy-WI to alert on or block suspicious requests to /waf/*/rule/*/save, especially those containing 92etc92cron.d92, /etc/cron.d/, or unexpected absolute path indicators.
Technical Notes
Because packaging varies by deployment, there is no single universal upgrade command confirmed for every Roxy-WI install. Use your platform-appropriate package manager only after verifying the target fixed version:
Debian/Ubuntu-style package workflow
apt-cache policy roxy-wi
sudo apt update
sudo apt install --only-upgrade roxy-wi
RHEL/Alma/Rocky-style package workflow
dnf info roxy-wi
sudo dnf upgrade roxy-wi
If deployed from a Git checkout, verify the fixed tag first
git remote -v
git fetch --tags
git tag --sort=-v:refname | head
Temporary file-system hardening and audit steps
sudo chattr +i /etc/cron.d # Do not use blindly in production; validate operational impact first
sudo auditctl -w /etc/cron.d -p wa -k cron_drop_watch
sudo ausearch -k cron_drop_watch
If you cannot patch immediately, at minimum restrict access to Roxy-WI, rotate credentials for all privileged users, inspect /etc/cron.d/ on managed systems, and monitor for follow-on persistence. Also consider disabling or tightly controlling the specific administrative workflow around WAF rule saves until the fixed release is deployed and validated.
References
| Source | URL |
|---|---|
| NVD CVE record | https://nvd.nist.gov/vuln/detail/CVE-2026-45556 |
| Upstream GitHub advisory | https://github.com/roxy-wi/roxy-wi/security/advisories/GHSA-85gm-773v-x7m4 |
| CISA KEV catalog | https://www.cisa.gov/known-exploited-vulnerabilities-catalog |
This article may contain affiliate links. We earn a commission on qualifying purchases at no extra cost to you.