PoC Exploit Targets Nginx-UI Backup Restore Public Released

A critical security flaw, identified as CVE-2026-33026, has emerged within the Nginx-UI backup restore mechanism.

This vulnerability allows threat actors to tamper with encrypted backup archives and inject malicious configurations during the restoration process.

With a public Proof-of-Concept (PoC) exploit now available, unpatched deployments are at immediate risk of full system compromise.

Cryptographic Flaw Exploit Mechanics and PoC

The root cause of this vulnerability lies in a severely flawed circular trust model within the application’s backup architecture.

When Nginx-UI generates a backup, it compresses the files into ZIP archives and encrypts them using AES-256-CBC. However, the system fails to maintain a trusted root of trust.

Instead of securing the encryption parameters server-side, the AES key and Initialization Vector (IV) are provided directly to the client as a backup security token.

Furthermore, the integrity metadata file, which contains the SHA-256 hashes of the encrypted files, is encrypted using this same key.

Because the attacker possesses the key, they can easily bypass all cryptographic security controls.

Adding to the severity, the restore process fails to enforce strict integrity verification, allowing restoration operations to proceed even when hash mismatches trigger system warnings.

Security researcher ‘dapickle’ successfully demonstrated how this architectural weakness can be weaponized.

The publicly released PoC includes Python scripts that automate the decryption and rebuilding of the Nginx-UI backup files.

An attacker begins by generating a standard backup and extracting the security token from the HTTP headers.

Using a decryption script, they unpack the archive and modify the internal configuration file (app.ini). A common attack vector involves injecting a malicious command, such as StartCmd = bash, into the configuration.

The attacker then uses a rebuilding script to compress the modified files, calculate new legitimate-looking hashes, update the metadata, and re-encrypt the entire bundle using the original token.

When this tampered backup is uploaded to the Nginx-UI restore interface, the system blindly accepts it and executes the injected payload.

Impact and Regression

This vulnerability carries a Critical severity rating, earning maximum CVSS 4.0 scores across multiple impact metrics.

Successful exploitation allows attackers to tamper with application configurations permanently, insert backdoors into Nginx routing, and achieve arbitrary command execution on the host machine.

Notably, this flaw is a regression of a previously reported vulnerability documented in the GitHub advisory GHSA-fhh2-gg7w-gwpq.

While an earlier patch addressed unauthorized access to backup files, it completely failed to resolve the underlying cryptographic design issue, leaving the system fundamentally vulnerable to archive modifications.

The security community has categorized the underlying weaknesses under multiple classifications, including improper validation of integrity check values (CWE-354) and failure to verify cryptographic signatures (CWE-347) properly.

The vulnerability impacts the Go-based Nginx-UI package, specifically versions 2.3.3 and earlier. To mitigate this critical threat, administrators must immediately upgrade to the patched release, version 2.3.4.

Beyond simply applying the latest patch, developers are advised to implement a server-side trusted integrity root. This involves signing backup metadata using a private key rather than relying on client-exposed tokens.

Furthermore, systems must be securely configured to avoid circular trust models and strictly abort the restore operation if any hash verification fails.

Disclaimer: HackersRadar reports on cybersecurity threats and incidents for informational and awareness purposes only. We do not engage in hacking activities, data exfiltration, or the hosting or distribution of stolen or leaked information. All content is based on publicly available sources.