A critical vulnerability in Nginx UI, the open-source web-based management interface for Nginx server clusters, allows any unauthenticated attacker with network access to download a complete system backup and immediately decrypt it using keys the server provides in the same HTTP response. Tracked as CVE-2026-27944 and assigned a CVSS 3.1 score of 9.8, the issue was disclosed on March 5, 2026 and is fixed in Nginx UI version 2.3.3. A proof-of-concept exploit was published alongside the advisory. No active exploitation has been confirmed at time of writing, though the single-request exploit path makes this trivially weaponizable.
Note: This vulnerability affects Nginx UI, a third-party management panel for Nginx. It is unrelated to Nginx itself or any vulnerabilities in the Nginx web server.
Root Cause: Two Independent Implementation Failures
The vulnerability is the product of two distinct oversights in the Go-based backend, documented in the advisory by reporter @tenbbughunters.
The first is a missing authentication middleware on the /api/backup route. In api/backup/router.go, the backup endpoint is registered directly without any session or token validation, while the corresponding /restore endpoint is correctly protected. The route registration makes the backup endpoint publicly accessible to any caller, authenticated or not.
The second failure compounds the first entirely. When the backup is served, the application includes the AES-256 encryption key and initialization vector (IV) in plaintext inside the X-Backup-Security HTTP response header, formatted as a colon-separated Base64 pair. An attacker who retrieves the backup already has everything needed to decrypt it within the same transaction. The encryption provides no effective protection because the decryption material is co-located with the encrypted data in the response.
Backup Contents and Impact
The backup archive generated by Nginx UI consolidates the most sensitive material in the server environment into a single file. According to the advisory, a decrypted backup exposes:
- database.db: User credentials and active session tokens, enabling full administrative takeover of the Nginx UI instance
- app.ini: Application configuration including secrets and API keys
- SSL private keys and certificates: For all sites managed through the interface, enabling traffic interception or impersonation of managed domains
- Nginx configuration files: Virtual host definitions, upstream configurations, and internal network topology
The combination of administrative credentials and SSL private keys means a successful exploit does not simply compromise the management panel. It provides the material necessary to impersonate managed web services, intercept TLS traffic, and pivot into any systems accessible via the Nginx infrastructure. The scope of impact is directly proportional to the number of sites and services the Nginx UI instance manages.
Exploit Mechanics
Exploitation requires a single unauthenticated HTTP GET request to /api/backup on the target host. The CVSS vector (AV:N/AC:L/PR:N/UI:N) reflects this: network-accessible, low complexity, no privileges, no user interaction required. The advisory includes a functional Python proof-of-concept that downloads the backup, parses the X-Backup-Security header to extract the AES key and IV, and decrypts the archive to disk in one step. The exploit requires only the pycryptodome library and the target URL.
As NVD and secondary researchers have noted, there is no public evidence of exploitation in the wild as of the disclosure date. However, the trivial exploitation path means that the window between disclosure and opportunistic scanning is short. Nginx UI has over 10,000 GitHub stars and is a common choice for teams managing self-hosted Nginx infrastructure, making it a plausible target for automated scanning campaigns.
Affected Versions and Remediation
All Nginx UI versions prior to 2.3.3 are affected. The fix registers the /api/backup endpoint within the authenticated router group and removes encryption key disclosure from the response headers. Administrators should upgrade immediately. As an interim measure for instances that cannot be patched, restricting access to the Nginx UI port to trusted IP ranges via firewall rules or a reverse proxy access control list eliminates the network-accessible attack surface. Management interfaces of this type should not be directly exposed to the public internet regardless of patch status.
Administrators who have run a vulnerable version with an internet-exposed Nginx UI instance should treat all secrets in the backup scope as potentially compromised and rotate accordingly: administrative passwords, session tokens, and SSL private key material for all managed domains.
This article is published for threat intelligence purposes. IntelFusions is not affiliated with any threat actor group. Claims described herein have not been independently verified unless explicitly stated. Primary source: GitHub Security Advisory GHSA-g9w5-qffc-6762.