CVE-2026-33026 is a critical backup integrity flaw in Nginx UI, scored CVSS 9.1. An attacker holding a backup token can alter an encrypted backup and have the restore accept it, injecting configuration. Versions up to 2.3.3 are affected, so upgrade to 2.3.4.
What's affected
The GitHub advisory lists the Go module github.com/0xJacky/nginx-ui at 2.3.3 and below, with 2.3.4 as patched. The 2.3.4 release notes say the update includes several security patches.
The advisory says that in certain configurations this may lead to arbitrary command execution on the host.
How to check if you're exposed
Check the installed version in the Nginx UI interface or your container tag and compare it with 2.3.4.
Then look at where backups and backup tokens live. The advisory says the key and IV are given to the client as a backup security token. Find who holds those tokens and where the archives are stored, such as shared drives, chat history or tickets.
Also review recent restores for configuration changes nobody asked for.
What to do now
- Upgrade Nginx UI to 2.3.4 or later.
- Treat backup archives and backup tokens as secrets. Store them with restricted access.
- Before restoring any backup, review the configuration it contains.
- Check recent restores and the current Nginx configuration for unexpected directives.
- Take fresh backups after the upgrade, so new backups use the fixed format.
Why it matters
The weaknesses are CWE-347, improper verification of a cryptographic signature, CWE-354, improper validation of an integrity check value, and CWE-312, cleartext storage of sensitive information. The advisory explains the circle. Files are encrypted with AES-256-CBC. The hash list that is meant to prove integrity is encrypted with the same key, and the key is handed to the client. Someone with the token can decrypt, edit, recompute the hashes and encrypt again.
Worse, the advisory says the restore accepted backups even when hash checks failed. Encryption gives secrecy, not integrity. For integrity you need a key or signature that the attacker does not hold. The record's KEV flag is false.
Quick check
Doesn't encryption already protect the backup?
Not against tampering. Whoever holds the key can change the contents and rebuild the checks, which is what the advisory describes.
Is the tokenless attacker a concern?
The advisory describes an attacker who can access the backup token. Protecting tokens and archives reduces exposure, and the upgrade is the fix.
Sources
Last reviewed: 19 October 2026.
