CVE-2026-107810: Nginx UI Path Traversal Vulnerability

CVE-2026-107810 Overview

CVE-2026-107810 is a symlink following vulnerability [CWE-59] in Nginx UI, a web user interface for the Nginx web server. The flaw resides in internal/backup/restore.go and affects versions 2.0.0 through 2.4.x. The restore routine extracts inner archives before enforcing the restore_nginx and restore_nginx_ui flags, and it permits symbolic links that point at the live Nginx configuration path. An authenticated user with permission to restore backups can craft an archive that places a symlink in the staging tree, then writes a regular file through it. The outcome is persistent configuration injection or denial of service when Nginx later consumes the modified files. The issue is fixed in version 2.5.0.

Critical Impact
Authenticated attackers can write arbitrary files to the Nginx configuration directory, achieving persistent configuration tampering or denial of service even when restore flags are disabled.

Affected Products

Nginx UI versions 2.0.0 through 2.4.x
The vulnerable component is internal/backup/restore.go
Fixed in Nginx UI version 2.5.0

Discovery Timeline

2026-10-09 - CVE-2026-107810 published to NVD
2026-10-13 - Last updated in NVD database

Technical Details for CVE-2026-107810

Vulnerability Analysis

The vulnerability lives in the backup restore flow of Nginx UI. The restore handler accepts an uploaded archive, extracts the inner archives into a staging tree, and only afterwards consults the user-supplied restore_nginx and restore_nginx_ui flags that are supposed to gate what gets written to disk. Because extraction happens before enforcement, file system side effects from the archive precede the policy check.

The extractor also honors symbolic links contained in the archive. An attacker can place a symlink inside the staging tree whose target is the live Nginx configuration directory. A subsequent regular-file entry whose path resolves through that symlink will cause the writer to follow the link and overwrite files outside the staging area. The behavior occurs even when both restore flags are set to false, so the trust boundary established by those flags is bypassed entirely.

Root Cause

The root cause is a classic link-following flaw [CWE-59] combined with a trust-boundary ordering bug. The archive extractor does not validate that resolved paths remain inside the staging directory, and it does not strip or reject symlinks. The restore flags are evaluated too late in the control flow to prevent writes.

Attack Vector

Exploitation requires an authenticated Nginx UI account that can create and restore backups. The attacker builds a valid backup archive containing a symlink entry targeting the Nginx configuration path, followed by a regular file entry whose name traverses that symlink. Uploading and restoring the archive drops attacker-controlled content into the Nginx configuration tree. Reloading Nginx then applies the injected directives or triggers failure if the written content is malformed.

// Security patch excerpt from api/backup/restore.go
// Response now surfaces manifest trust level and skipped settings
// after the restore path was hardened against symlink abuse.
type RestoreResponse struct {
    NginxUIRestored bool                 `json:"nginx_ui_restored"`
    NginxRestored   bool                 `json:"nginx_restored"`
    HashMatch       bool                 `json:"hash_match"`
    TrustLevel      backup.ManifestTrust `json:"trust_level"`
    SkippedSettings []string             `json:"skipped_protected_settings"`
}

Source: GitHub commit a467ed6

Detection Methods for CVE-2026-107810

Indicators of Compromise

Unexpected modifications to files under the Nginx configuration directory with timestamps matching recent /api/backup/restore requests.
Presence of symbolic links inside the Nginx UI backup staging directory pointing outside that directory.
Nginx UI audit entries showing restore operations where restore_nginx and restore_nginx_ui were both false yet files changed on disk.
Nginx reload failures or new, unauthorized server or location blocks appearing after a restore event.

Detection Strategies

Monitor the Nginx UI HTTP API for POST requests to backup restore endpoints and correlate with subsequent file writes under /etc/nginx/ or the configured Nginx prefix.
Hash the Nginx configuration tree on a schedule and alert on drift that is not tied to an approved change window.
Inspect uploaded backup archives for entries whose type is symlink before they are staged.

Monitoring Recommendations

Enable file integrity monitoring on the Nginx configuration directory and the Nginx UI data directory.
Forward Nginx UI application logs and operating system audit logs to a centralized SIEM for correlation.
Track authentication events for Nginx UI accounts that hold backup or administrator privileges and alert on anomalous use.

How to Mitigate CVE-2026-107810

Immediate Actions Required

Upgrade Nginx UI to version 2.5.0 or later on every host running the service.
Audit the Nginx configuration tree for unauthorized changes made since the 2.0.0 release.
Rotate credentials for any Nginx UI accounts that could invoke the backup restore endpoint.
Review backup archive storage for unexpected files containing symlink entries.

Patch Information

The fix ships in Nginx UI 2.5.0. The commit a467ed6 hardens the restore trust boundaries by introducing manifest trust levels, protected-settings handling, and portable credential invalidation. See the GitHub Security Advisory GHSA-p8v3-89rh-jxc7 and the v2.5.0 release notes for full details.

Workarounds

Restrict access to the Nginx UI web interface to trusted administrators only, using network ACLs or a reverse proxy with mutual TLS.
Disable or remove backup restore functionality for non-administrator roles until the upgrade is complete.
Run Nginx UI under a service account that lacks write permission to the Nginx configuration directory where feasible.

bash

# Verify the installed Nginx UI version and upgrade if below 2.5.0
nginx-ui -version

# Example container upgrade
docker pull uozi/nginx-ui:2.5.0
docker stop nginx-ui && docker rm nginx-ui
docker run -d --name nginx-ui \
  -v /etc/nginx:/etc/nginx \
  -v /etc/nginx-ui:/etc/nginx-ui \
  -p 9000:9000 uozi/nginx-ui:2.5.0