GHSA-jrq7-xrjx-pcfw: Path Traversal

Published Oct 15, 2026
·
Updated

Summary

Nginx UI validates backuppath and storagepath 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 storagepath still passes validation because it is inside GrantedAccessPath, but the generated backup path escapes that storage directory when filepath.Join(storagepath, 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 dev branch commit checked: 4948fba8744e82c3d7003f68ee164e9f49421066 - Latest release checked: v2.3.10, published 2026-04-28 - The vulnerable filename construction is present in both current dev and v2.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 storagepath, but not for the final path after the backup name is appended.

Root Cause

model.AutoBackup.GetName() only trims whitespace and replaces spaces:

go func (a AutoBackup) GetName() string { return strings.ReplaceAll(strings.TrimSpace(a.Name), " ", "") }

The result is then embedded directly into filenames:

go filename := fmt.Sprintf("%s%d.zip", autoBackup.GetName(), time.Now().Unix()) outputPath = filepath.Join(autoBackup.StoragePath, filename)

and for custom directory backups:

go filename := fmt.Sprintf("customdir%s%d.zip", autoBackup.GetName(), time.Now().Unix()) outputPath = filepath.Join(autoBackup.StoragePath, filename)

The API validation rules require name, backuptype, storagetype, storagepath, and cronexpression, but do not reject /, \, or .. in name. ValidateAutoBackupConfig validates backuppath and storagepath, but it does not validate the final outputPath after appending the generated filename.

Relevant paths:

- model/autobackup.go - api/backup/autobackup.go - internal/backup/autobackup.go - internal/backup/utils.go

Proof of Concept

The following local-only reproducer mirrors the relevant code path without contacting any external system:

go name := "task/../../../escaped" filename := fmt.Sprintf("customdir%s%d.zip", getName(name), int64(1715555555)) outputPath := filepath.Join(storageDir, filename)

Setup:

1. Create a temporary granted directory. 2. Set sourceDir and storageDir under that granted directory. 3. Treat only granted as the allowed path boundary. 4. Use the auto-backup name task/../../../escaped. 5. Create the custom-directory backup using the same filename pattern and zip creation behavior.

Observed output:

text grantedroot=/Users/jagadeshachanta/.cache/tmp/nginx-ui-autobackup-poc-1538710430/granted validatedstoragepath=/Users/jagadeshachanta/.cache/tmp/nginx-ui-autobackup-poc-1538710430/granted/storage autobackupname="task/../../../escaped" constructedfilename="customdirtask/../../../escaped1715555555.zip" createdfile=/Users/jagadeshachanta/.cache/tmp/nginx-ui-autobackup-poc-1538710430/escaped1715555555.zip escapedvalidatedstoragepath=true createdfileexists=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:

text internal/backup/autobackuppathtraversalpoctest.go

The test cannot currently be executed cleanly in this checkout because unrelated build prerequisites fail before the package test runs:

text 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/keytype.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.

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 storagepath, - write encrypted configuration backup key files outside the intended storagepath, - 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.

Suggested Fix

Recommended defense in depth:

1. Treat auto-backup name as a display label only, not as a filesystem path component. 2. Sanitize generated filenames with filepath.Base or a strict allowlist such as [A-Za-z0-9.-]. 3. Reject path separators, drive separators, NUL bytes, and .. segments in name. 4. After constructing outputPath, clean it and validate that the final path remains inside the already-validated storagepath. 5. Add regression tests for both local and S3 temporary-file paths.

Example invariant:

go cleanOutput := filepath.Clean(outputPath) cleanStorage := filepath.Clean(autoBackup.StoragePath) + string(filepath.Separator) if !strings.HasPrefix(cleanOutput, cleanStorage) { return ErrPathNotInGrantedAccess }

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.

Affected Software

1 affected componentFixes available
go/github.com/0xJacky/Nginx-UI<1.9.10-0.20260715121709-f92218e01054
1.9.10-0.20260715121709-f92218e01054

Remediation

Recommended actions to resolve this vulnerability, in priority order.

  1. Upgrade

    Upgrade go/github.com/0xJacky/Nginx-UI to a version that resolves this vulnerability.

    Fixed in 1.9.10-0.20260715121709-f92218e01054
  2. Compensating control

    Treat the auto-backup name as a display label rather than a filesystem path component: reject path separators, drive separators, NUL bytes, and `..` segments, and sanitize generated filenames with `filepath.Base` or an allowlist such as `[A-Za-z0-9._-]`. After constructing `outputPath`, apply `filepath.Clean` and verify that the final path remains inside the already-validated `storage_path` and therefore inside `backup.GrantedAccessPath`.

  3. Operational

    Add regression tests covering both local and S3 temporary-file paths, including the auto-backup name `task/../../../escaped`, and verify that the resulting backup archive and adjacent encrypted-configuration `.key` file cannot be written outside the validated storage directory.

Event History

Oct 15, 2026
Advisory Published
via GitHub·08:10 PM
Data Sourced
via GitHub·08:10 PM
DescriptionSeverityWeaknessAffected Software

Frequently Asked Questions

1

Who can exploit this issue?

An authenticated user who can create or modify an auto-backup task can exploit it. The user controls the auto-backup name used to construct the output filename.

2

What access or configuration is required for exploitation?

The configured storage_path must pass validation by being inside the administrator-defined backup.GrantedAccessPath boundary. Exploitation then relies on placing path separators or .. components in the auto-backup name so the final joined path escapes the storage directory.

3

What could an attacker write outside the intended directory?

The attacker can cause backup archives to be written outside the intended storage directory with the Nginx UI process privileges. For encrypted configuration backups, the adjacent .key file may also be written outside that directory.

4

Which releases are known to be affected?

The vulnerable filename construction is present in release v2.3.10 and in the checked current dev-branch commit 4948fba8744e82c3d7003f68ee164e9f49421066.

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203