CVE-2026-107804 in Nginx UI
Summary
by MITRE • 10/09/2026
Nginx UI is a web user interface for the Nginx web server. From 2.2.0 until 2.6.0, the bundled reverse proxy does not preserve the external client identity used by Gin because the backend has no trusted proxy configuration. Management requests can be attributed to loopback and pass the IP allowlist loopback exception, although valid credentials are still required. Failed logins from different external clients are also attributed to the same loopback address, allowing an unauthenticated attacker to trigger a shared temporary login ban for password or OTP authentication without invalidating existing sessions. This issue is fixed in version 2.6.0.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 10/09/2026
The vulnerability identified in Nginx UI versions ranging from 2.2.0 through 2.6.0 stems from an improper configuration of the bundled reverse proxy, specifically regarding how it handles client identity information when forwarding requests to the backend application framework known as Gin. In a standard web architecture utilizing a reverse proxy, such as Nginx acting in front of an application server, it is critical for the proxy to preserve and forward the original client's IP address via HTTP headers like X-Forwarded-For or X-Real-IP. This allows the backend service to accurately identify the source of incoming requests. However, due to a missing trusted proxy configuration within this specific version range, the backend fails to recognize these forwarded addresses as legitimate sources of truth for client identity. Consequently, the application defaults to attributing all management interface traffic to the loopback address, typically 127.0.0.1 or ::1, which represents local machine communication rather than external network connections.
This misconfiguration creates a significant security flaw related to access control and authentication mechanisms that rely on IP-based allowlists. Many administrative interfaces implement an initial layer of defense by permitting access only from specific trusted networks, often including the loopback address for internal services or localhost management tools. Because every request is falsely attributed to this local interface, external attackers can bypass these IP-based restrictions without needing valid network-level permissions. While the vulnerability does not allow direct unauthorized access because valid credentials are still required for authentication, it effectively neutralizes one layer of defense-in-depth strategy designed to limit exposure based on source location.
A more severe operational impact arises from how this identity misattribution affects rate limiting and account lockout policies. Authentication systems typically employ temporary bans or locks after a certain number of failed login attempts to mitigate brute-force attacks against password or One-Time Password (OTP) authentication methods. Since all external clients are indistinguishable from the local loopback address, any user attempting to log in with incorrect credentials contributes to the failure count associated with that single IP identifier. This allows an unauthenticated attacker to trigger a shared temporary login ban for legitimate users who share the same perceived source identity or simply by exhausting the lockout threshold themselves. The result is a denial-of-service condition where valid administrators are locked out of their accounts, disrupting management operations and potentially causing downtime if automated recovery processes are not in place.
From a classification perspective, this issue aligns with CWE-285, which describes Improper Authorization, as it involves the bypassing of access control mechanisms through misconfiguration rather than code logic errors. It also relates to CWE-770, Allocation of Resources Without Limits or Throttling, in the context that the rate-limiting mechanism is applied incorrectly due to flawed identity attribution. In terms of offensive security frameworks, this vulnerability facilitates actions consistent with ATT&CK technique T1190, Exploit Public-Facing Application, by allowing attackers to leverage misconfigured trust relationships to interfere with authentication services and potentially disrupt availability through account lockout abuse.
The resolution for this vulnerability was implemented in version 2.6.0 of Nginx UI. To mitigate the risk before upgrading or if running an affected version, administrators should ensure that the reverse proxy is correctly configured to pass client IP addresses via appropriate headers such as X-Real-IP and X-Forwarded-For. The backend application must be explicitly configured to trust these proxies so that it can accurately parse and utilize the original client identity for access control decisions and rate-limiting calculations. Additionally, relying solely on IP-based allowlists is generally discouraged in modern security practices; implementing multi-factor authentication and robust account lockout policies that consider user identities rather than just IP addresses provides stronger protection against brute-force attacks and denial-of-service attempts via credential stuffing or lockout abuse.