CVE-2026-107810: 
Nginx UI vulnerability analysis and mitigation

CVE-2026-107810 is a symlink-following vulnerability in Nginx UI, a web-based management interface for the Nginx web server. Affecting versions 2.0.0 through 2.5.0 (exclusive), the flaw allows an authenticated user with backup creation and restore permissions to craft a malicious backup archive that writes attacker-controlled files into the live Nginx configuration path, even when both restore_nginx and restore_nginx_ui flags are set to false. The vulnerability was originally published by the maintainer on August 12, 2026, and added to the GitHub Advisory Database on October 9, 2026. It carries a CVSS v3.1 base score of 8.1 (High) (Github Advisory, Security Advisory).

The root cause is improper symlink resolution during archive extraction (CWE-59, CWE-61). In internal/backup/restore.go, the restore flow unconditionally extracts the outer archive, verifies the manifest, decrypts nginx-ui.zip and nginx.zip, and extracts both inner archives before evaluating the RestoreNginx or RestoreNginxUI flags. The zip extractor explicitly permits absolute symlinks whose targets fall under nginx.GetConfPath() or nginx.GetModulesPath(), and subsequent regular-file entries are written via os.OpenFile() on the symlinked path — which follows the symlink into the live configuration tree. An attacker exploits this by crafting a backup zip that contains a symlink entry pointing to the live Nginx config directory, followed by a regular file entry written through that link, bypassing the restore flag trust boundary entirely (Security Advisory, Github Advisory).

Successful exploitation allows an authenticated attacker to persistently inject arbitrary content into the live Nginx configuration path, which can result in malicious directives being loaded on the next Nginx reload or restart. This leads to high integrity impact (unauthorized modification of configuration files) and high availability impact (denial of service if malformed configuration causes Nginx to fail). Confidentiality is not directly impacted, but injected configurations could be used to redirect traffic, disable access controls, or facilitate further lateral movement within the infrastructure (Security Advisory, Github Advisory).

The vulnerability requires low privileges (authenticated user with backup permissions) and no user interaction, making it accessible to any user account that has been granted backup and restore capabilities. A theoretical proof-of-concept outline was included in the security advisory and verified locally by the reporter (Vincent550102) in an isolated environment, but no runnable exploit code or weaponized payload has been publicly released (Security Advisory). The EPSS score is approximately 0.363% (29th percentile), and there is no evidence of in-the-wild exploitation or CISA KEV catalog inclusion at this time. The NVD SSVC assessment classifies exploitation status as "poc" with the attack not being automatable (Github Advisory).

1. Authenticate: Log in to the target Nginx UI instance (versions 2.0.0–2.4.x) with an account that has backup creation and restore permissions.
2. Generate a legitimate backup: Use the Nginx UI backup feature to create a valid backup archive, obtaining the AES key/IV used for encryption.
3. Extract and modify the backup: Unpack the outer backup archive, decrypt nginx.zip from within it, and replace its contents with a crafted zip file containing:
   • A symlink entry (e.g., link) pointing to the live Nginx configuration directory (e.g., /etc/nginx/).
   • A regular file entry at a path traversing through the symlink (e.g., link/poc.conf) containing attacker-controlled Nginx configuration directives.
4. Recompute manifest integrity values: Update manifest.json with the correct size and hash values for the modified encrypted nginx.zip, then re-sign manifest.sig using the signing key derived from the AES key.
5. Repack the archive: Reassemble the outer backup archive with the tampered inner zip and updated manifest.
6. Trigger restore with flags disabled: Submit the crafted backup to the restore endpoint with both RestoreNginx: false and RestoreNginxUI: false. The restore process will still extract the inner archives and follow the symlink, writing the attacker's file (e.g., poc.conf) into the live Nginx configuration path.
7. Achieve persistence: The injected configuration file persists on disk and will be loaded by Nginx on the next reload or restart, enabling configuration injection or denial of service (Security Advisory, Github Advisory).

• File System: Unexpected .conf or other files appearing in the live Nginx configuration directory (e.g., /etc/nginx/) that were not created through normal administrative workflows; presence of symbolic links within the Nginx configuration staging or temp directories pointing to live config paths.
• Logs: Nginx UI application logs showing restore operations completed successfully with both restore_nginx and restore_nginx_ui set to false, particularly from non-administrative user accounts; Nginx error logs showing configuration parse failures or unexpected directive errors after a restore event.
• Network: Authenticated POST requests to the Nginx UI backup restore API endpoint (/api/backup/restore) from unexpected source IPs or user accounts, especially with unusual timing or frequency.
• Process: Nginx reload or restart events (nginx -s reload) occurring shortly after a backup restore operation, potentially loading injected configuration (Security Advisory).

The vulnerability is fixed in Nginx UI version 2.5.0, which hardens the backup restore trust boundaries by enforcing symlink restrictions and applying restore flags before extracting inner archives (v2.5.0 Release, Fix Commit). All users running versions 2.0.0 through 2.4.x should upgrade to v2.5.0 immediately. As a workaround prior to patching, restrict backup creation and restore permissions to only highly trusted administrator accounts, and monitor the Nginx configuration directory for unauthorized file changes. Additionally, review all backup archives before restoration and audit restore operation logs for suspicious activity (Github Advisory).

The vulnerability was reported by security researcher Vincent550102 and disclosed responsibly through GitHub's security advisory process. The fix was committed by the maintainer (0xJacky) and included in the v2.5.0 release alongside several other security hardening improvements. No significant broader media coverage or notable community debate has been identified beyond the standard advisory publication (Security Advisory, v2.5.0 Release).