Public PoC puts nginx-ui backup restore flaw under fresh pressure
5 min. read 
Published on
A public proof of concept is now available for CVE-2026-33026, a critical nginx-ui backup restore vulnerability that lets attackers tamper with encrypted backups and inject malicious configuration during restore. GitHub’s advisory says the flaw affects nginx-ui versions prior to 2.3.4, and NVD also lists 2.3.4 as the patched release.
The core problem is not weak encryption by itself. The real issue is trust. GitHub says nginx-ui gives the client the AES key and IV as a backup security token, then protects the integrity metadata with that same key, which means anyone who has the token can decrypt the archive, modify files, rebuild hashes, and encrypt the package again.
Access content across the globe at the highest speed rate.
70% of our readers choose Private Internet Access
70% of our readers choose ExpressVPN
Browse the web from multiple devices with industry-standard security protocols.
Faster dedicated servers for specific actions (currently at summer discounts)
That design becomes even more dangerous during restore. GitHub says the restore process does not strictly enforce integrity verification and can continue even after hash mismatch warnings, which allows attacker-controlled configuration to get applied. In some setups, that can lead to arbitrary command execution on the host.
Why the public PoC matters
The newly published PoC lowers the barrier for abuse because it shows the workflow step by step. GitHub’s advisory includes Python code that decrypts the backup, lets an attacker edit files such as app.ini, recalculates SHA-256 hashes, and rebuilds the archive with the original token before upload to the restore interface.
The attack path described in the advisory starts with a normal backup. The attacker extracts the backup token from the HTTP response headers or the .key file, decrypts nginx-ui.zip, modifies configuration, updates hash_info.txt, and then uploads the tampered backup. GitHub says the system accepts the modified backup and applies the malicious configuration even if a warning appears.
That is why this bug deserves urgent attention. It is not just about reading sensitive backup contents. It is about turning the restore feature into a path for persistent configuration tampering, backdoor insertion into nginx configuration, and possible command execution depending on deployment settings.
What caused the flaw
GitHub’s advisory says the backup format lacks a trusted integrity root. Backup files are compressed into nginx-ui.zip and nginx.zip, encrypted with AES-256-CBC, hashed with SHA-256, and recorded in hash_info.txt, but that hash file is also encrypted with the same key and IV that the client receives.
That creates what the advisory calls a circular trust model. The client gets the key, the integrity metadata depends on that same key, and the restore process trusts hashes stored inside the backup itself. In other words, the attacker can modify both the data and the proof that is supposed to protect the data.
GitHub also says this is a regression from an earlier nginx-ui backup flaw. The previous advisory, GHSA-g9w5-qffc-6762, fixed unauthorized access to backup files but did not solve the deeper cryptographic design problem, which left the archive tampering weakness exploitable.
At-a-glance risk table
| Item | Verified detail |
|---|---|
| CVE | CVE-2026-33026 |
| Severity | Critical |
| Affected versions | nginx-ui prior to 2.3.4 |
| Fixed version | 2.3.4 |
| Root cause | Client-exposed key/IV plus self-contained integrity metadata create circular trust |
| Impact | Tampered restores, configuration injection, possible host command execution in some setups |
| Public PoC | Included in the GitHub advisory details |
What admins should do now
If you run nginx-ui, the immediate step is to upgrade to 2.3.4. The maintainer’s v2.3.4 release note says the update includes several security patches and recommends that all users update immediately.
Admins should also review recent backup generation and restore activity. Because the attack abuses a legitimate restore path, a successful compromise may look like an ordinary restore operation followed by suspicious configuration changes. That detection advice is an inference based on the documented restore workflow and impact.
The longer-term lesson goes beyond nginx-ui. Backup encryption does not help if the same party who receives the encrypted archive also receives everything needed to rewrite it and make it look valid. GitHub’s recommended mitigation calls for a trusted integrity root and server-side verification that fails closed when integrity checks do not match.
Quick response checklist
- Upgrade nginx-ui to version 2.3.4.
- Audit who can generate, download, and upload backups. This follows from the advisory’s token-based attack path.
- Review recent restore events for unexpected
app.inior nginx configuration changes. This is a practical detection step based on the PoC workflow. - Treat backup tokens and
.keyfiles as highly sensitive secrets until all affected systems are patched. - Prefer designs where integrity metadata is signed or validated server-side and restoration stops on mismatch.
FAQ
It is a critical nginx-ui backup restore flaw that lets attackers tamper with encrypted backup archives and inject malicious configuration during restoration.
NVD says nginx-ui versions prior to 2.3.4 are affected, and the issue is patched in version 2.3.4.
Because the client receives the AES key and IV, and the integrity metadata is protected with that same key. GitHub says an attacker with the token can decrypt, modify, recompute hashes, and re-encrypt the bundle.
Yes, in certain configurations. GitHub says restore of attacker-controlled configuration can lead to arbitrary command execution on the host depending on deployment settings.
Read our disclosure page to find out how can you help VPNCentral sustain the editorial team Read more
Improve this guide
User forum
0 messages