Summary
Nginx UI: Auto backup name allows path traversal outside validated storage path
Nginx UI validates backup_path and storage_path against the administrator-defined backup.GrantedAccessPath boundary, but the final auto-backup output filename is built from the user-controlled auto-backup name without stripping path separators or .. components.
An authenticated user who can create or modify an auto-backup task can set a name such as task/../../../escaped. The configured storage_path still passes validation because it is inside GrantedAccessPath, but the generated backup path escapes that storage directory when filepath.Join(storage_path, filename) resolves the embedded traversal sequence.
This bypasses the documented backup path boundary and allows backup archives, and for encrypted configuration backups the adjacent .key file, to be written outside the intended storage directory with the Nginx UI process privileges.
Affected Versions
- Current
devbranch commit checked:4948fba8744e82c3d7003f68ee164e9f49421066 - Latest release checked:
v2.3.10, published 2026-04-28 - The vulnerable filename construction is present in both current
devandv2.3.10.
Security Boundary
The project documentation describes backup.GrantedAccessPath as the critical security boundary for backup operations. It says the setting:
- restricts backup operations to explicitly authorized directories,
- prevents unauthorized access to sensitive system directories,
- enforces administrator-defined boundaries,
- normalizes paths to prevent traversal attempts.
That boundary is enforced for the configured storage_path, but not for the final path after the backup name is appended.
Root Cause
model.AutoBackup.GetName() only trims whitespace and replaces spaces:
func (a *AutoBackup) GetName() string {
return strings.ReplaceAll(strings.TrimSpace(a.Name), " ", "_")
}
The result is then embedded directly into filenames:
filename := fmt.Sprintf("%s_%d.zip", autoBackup.GetName(), time.Now().Unix())
outputPath = filepath.Join(autoBackup.StoragePath, filename)
and for custom directory backups:
filename := fmt.Sprintf("custom_dir_%s_%d.zip", autoBackup.GetName(), time.Now().Unix())
outputPath = filepath.Join(autoBackup.StoragePath, filename)
The API validation rules require name, backup_type, storage_type, storage_path, and cron_expression, but do not reject /, \, or .. in name. ValidateAutoBackupConfig validates backup_path and storage_path, but it does not validate the final outputPath after appending the generated filename.
Relevant paths:
model/auto_backup.goapi/backup/auto_backup.gointernal/backup/auto_backup.gointernal/backup/utils.go
Proof of Concept
The following local-only reproducer mirrors the relevant code path without contacting any external system:
name := "task/../../../escaped"
filename := fmt.Sprintf("custom_dir_%s_%d.zip", getName(name), int64(1715555555))
outputPath := filepath.Join(storageDir, filename)
Setup:
- Create a temporary
granteddirectory. - Set
sourceDirandstorageDirunder that granted directory. - Treat only
grantedas the allowed path boundary. - Use the auto-backup name
task/../../../escaped. - Create the custom-directory backup using the same filename pattern and zip creation behavior.
Observed output:
granted_root=/Users/jagadeshachanta/.cache/tmp/nginx-ui-autobackup-poc-1538710430/granted
validated_storage_path=/Users/jagadeshachanta/.cache/tmp/nginx-ui-autobackup-poc-1538710430/granted/storage
auto_backup_name="task/../../../escaped"
constructed_filename="custom_dir_task/../../../escaped_1715555555.zip"
created_file=/Users/jagadeshachanta/.cache/tmp/nginx-ui-autobackup-poc-1538710430/escaped_1715555555.zip
escaped_validated_storage_path=true
created_file_exists=true
The configured storage path is inside the granted directory, but the created backup file is outside both the storage directory and the granted directory.
A repo-local regression test was also prepared at:
internal/backup/auto_backup_path_traversal_poc_test.go
The test cannot currently be executed cleanly in this checkout because unrelated build prerequisites fail before the package test runs:
app/app.go: pattern all:dist: no matching files found
model/cert.go: no required module provides package github.com/go-acme/lego/v5/certificate
internal/helper/key_type.go: no required module provides package github.com/go-acme/lego/v5/certcrypto
The standalone reproducer output above was therefore used as the executable proof for this report.
Disclosure Notes
This was tested only in a local isolated environment against source code and temporary directories. No online demo systems or production systems were tested.
AI assistance was used to inspect the open-source code, prepare the local reproducer, and draft this report. The issue and PoC output were verified locally before submission.
Impact
An authenticated user with access to the auto-backup API can bypass the administrator-configured backup storage boundary. Depending on filesystem permissions and deployment layout, this can:
- write backup archives outside the intended
storage_path, - write encrypted configuration backup key files outside the intended
storage_path, - place sensitive backup material in directories that administrators did not authorize for backup storage,
- create or overwrite timestamp-suffixed files outside the validated backup directory using the Nginx UI process privileges.
This is especially relevant because backup archives may contain Nginx UI configuration, database files, Nginx configuration, and for encrypted config backups the adjacent key file required to decrypt the archive.
Input manipulates file paths to reach files outside the intended directory, such as configuration or credential files. Typical impact: unauthorized file read or write outside the intended directory.
CVE-2026-84320 has a CVSS score of 6.3 (Medium). The vector is network-reachable, low privileges required, and no user interaction. A CVSS score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether this affects your application depends on whether the vulnerable code is present and reachable in your environment. A fixed version is available (1.9.10-0.20260715121709-f92218e01054); upgrading removes the vulnerable code path.
Affected versions
Security releases
Kodem intelligence
Severity tells you how bad this could be in the worst case. It does not tell you whether you are exposed. Exploitability and impact are functions of runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A vulnerable package can sit in your dependency tree and never run.
Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter. Kodem's runtime-powered SCA identifies whether this CVE is reachable in your applications.
Already deployed Kodem?
See it in your environmentNew to Kodem? Get a demo →Remediation advice
Recommended defense in depth:
- Treat auto-backup
nameas a display label only, not as a filesystem path component. - Sanitize generated filenames with
filepath.Baseor a strict allowlist such as[A-Za-z0-9._-]. - Reject path separators, drive separators, NUL bytes, and
..segments inname. - After constructing
outputPath, clean it and validate that the final path remains inside the already-validatedstorage_path. - Add regression tests for both local and S3 temporary-file paths.
Example invariant:
cleanOutput := filepath.Clean(outputPath)
cleanStorage := filepath.Clean(autoBackup.StoragePath) + string(filepath.Separator)
if !strings.HasPrefix(cleanOutput, cleanStorage) {
return ErrPathNotInGrantedAccess
}
Frequently Asked Questions
- What is CVE-2026-84320? CVE-2026-84320 is a medium-severity path traversal vulnerability in github.com/0xJacky/Nginx-UI (go), affecting versions < 1.9.10-0.20260715121709-f92218e01054. It is fixed in 1.9.10-0.20260715121709-f92218e01054. Input manipulates file paths to reach files outside the intended directory, such as configuration or credential files.
- How severe is CVE-2026-84320? CVE-2026-84320 has a CVSS score of 6.3 (Medium). This score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether it represents real risk in your environment depends on whether the vulnerable code is present and reachable.
- Which versions of github.com/0xJacky/Nginx-UI are affected by CVE-2026-84320? github.com/0xJacky/Nginx-UI (go) versions < 1.9.10-0.20260715121709-f92218e01054 is affected.
- Is there a fix for CVE-2026-84320? Yes. CVE-2026-84320 is fixed in 1.9.10-0.20260715121709-f92218e01054. Upgrade to this version or later.
- Is CVE-2026-84320 exploitable, and should I be worried? Whether CVE-2026-84320 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
- What actually determines whether CVE-2026-84320 is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
- How do I fix CVE-2026-84320? Upgrade
github.com/0xJacky/Nginx-UIto 1.9.10-0.20260715121709-f92218e01054 or later.