GHSA-9h23-53f4-q947: Medium severity go/github.com/0xJacky/Nginx-UI vulnerability
Summary
In Nginx UI versions 2.2.0 through 2.5.x, the official bundled reverse-proxy topology did not preserve the external client identity used by Gin. The backend treated the local proxy peer as the client because no trusted proxy was configured, while the proxy supplied the actual address in forwarding headers.
Impact
This has two distinct effects in bundled-proxy deployments:
IP allowlist enforcement: management API requests forwarded by the bundled proxy were identified as loopback and could pass the loopback exception even when the external source was not in the configured allowlist. Protected management operations still required valid credentials; this did not grant unauthenticated administrator access. Login availability: failed login attempts from different external sources were attributed to one loopback address. An unauthenticated attacker could therefore trigger the shared temporary login-ban threshold and deny password or OTP login to other users behind the proxy until the ban expired. Existing authenticated sessions were not invalidated.
Remediation
Upgrade to Nginx UI 2.6.0 or later. The fix explicitly trusts only the intended bundled proxy, validates configured trusted proxies, uses the resolved client address consistently, and fails closed when an IP allowlist is enabled but the client address is invalid.
Fix commit: https://github.com/0xJacky/nginx-ui/commit/e30e331303fc21cf077a2bea724bd79e66892eaf
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
go/github.com/0xJacky/Nginx-UIto a version that resolves this vulnerability.Fixed in 1.9.10-0.20260904075558-e30e331303fc - Upgrade
Upgrade
Nginx UIto a version that resolves this vulnerability.Fixed in 2.6.0
Event History
Frequently Asked Questions
Which deployments are exposed to these effects?
The issue affects Nginx UI versions 2.2.0 through 2.5.x when deployed with the official bundled reverse-proxy topology. In that topology, the backend identifies forwarded requests as coming from the local proxy rather than the external client.
Can the allowlist bypass give an attacker unauthenticated administrator access?
No. Requests could receive the loopback allowlist exception, but protected management operations still required valid credentials. The issue does not grant unauthenticated administrator access.
What can an unauthenticated attacker do through the login-related impact?
They can generate failed login attempts from different external sources that are all attributed to the same loopback address. This can trigger the shared temporary login ban and prevent other users behind the proxy from using password or OTP login until the ban expires; existing authenticated sessions remain valid.
What is the remediation?
Upgrade to Nginx UI 2.6.0 or later. The fix explicitly trusts only the intended bundled proxy.