nginx-ui Forged Backup RCE (CVE-2026-107806): TestConfigCmd After Authenticated Restore
Admin · October 13, 2026 · 7 views
Admin panels that trust their own backups
nginx-ui (0xJacky/nginx-ui) is a popular web panel for managing nginx configs, certificates, and reload workflows. CVE-2026-107806 is authenticated remote code execution with CVSS 4.0 9.4 Critical (PR:H): an admin who can use the product’s portable backup API can also forge a backup archive, restore it, and get shell execution when the panel runs nginx -t—because restored app.ini overwrote TestConfigCmd.
Public PoC: CVE-2026-107806 on pocbit.org. Repository: murrez/CVE-2026-107806. Fixed in 2.5.0 (GHSA-p393-cf76-4jmr).
| | | |---|---| | Affected | ≥ 2.3.8, < 2.5.0 | | Fixed | 2.5.0 | | CWE | CWE-94 — code injection via trusted configuration | | Auth | Admin JWT required (not anonymous internet spray) | | Verify marker | POCBIT-107806-OK |
Do not confuse with CVE-2026-42238
CVE-2026-42238 was the unauthenticated install-window restore story. 2.3.8 added authentication on restore—but post-auth trust remained: the server still accepted attacker-supplied AES backup keys and re-signed manifests until 2.5.0. Defenders who only blocked “install-time restore” may still be exposed on patched-for-42238 builds below 2.5.0.
Mechanism (defender view)
The PoC chain mirrors what a malicious insider or stolen admin session would do:
GET /api/backup— download encrypted backup; readX-Backup-Security(key_b64:iv_b64).- Decrypt inner
nginx-ui.zip, patchapp.ini→[nginx] TestConfigCmd. - Re-encrypt, fix
manifest.jsonhashes, re-signmanifest.sig(nginx-ui-backup-signing-v1:+ AES key). POST /api/restorewith the malicious archive.POST /api/nginx/test— panel runsTestConfigCmdvia/bin/sh -c.
So the bug is not “nginx misconfiguration”—it is restore integrity: treating client-provided backup crypto material as authoritative for a code-execution hook in config.
Cross-read: authentication bypass — what to check, API security JWT mistakes, RCE vs local privilege escalation.
Defender checklist
| # | Action | Detail |
|---|--------|--------|
| 1 | Version | Panel footer / API / container image tag — target ≥ 2.5.0 |
| 2 | Upgrade | Pull 2.5.0+ image or binary; rotate admin passwords after compromise suspicion |
| 3 | Exposure | Bind admin UI to VPN or management VLAN; never public 9000/8080 without MFA at edge |
| 4 | Session hygiene | Short JWT TTL, revoke on staff offboarding; monitor /api/backup + /api/restore |
| 5 | 2FA | PoC supports --secure-session when 2FA is enabled—stolen password alone may not be enough, but session theft still is |
| 6 | Audit logs | Restore followed by /api/nginx/test from same session |
| 7 | Correlation | CVE Detector + internal CMDB for devops panels |
Patch validation
- Lab container nginx-ui < 2.5.0 (pin vulnerable tag).
- Admin login → obtain JWT (authorized test).
python poc.py --mode checkthen--mode exploitwith marker command.- Upgrade to 2.5.0; forged restore should fail or not yield execution.
See safe PoC lab setup.
Discovery hints (your assets only)
title="Nginx UI" || body="nginx-ui"
port="9000" || port="8080"
FOFA-style hits are candidates only—confirm version with authenticated check.
FAQ
PR:H means low risk, right?
PR:H lowers mass unauthenticated exploitability, not impact. Stolen admin, supply-chain panel, or support credential scenarios still yield full host RCE on the nginx-ui machine.
Can we disable backup/restore?
If the product requires backup for ops, patch is the durable fix. Restrict API routes at reverse proxy as defense in depth.
Same host as production sites?
Treat compromise of nginx-ui as edge infrastructure breach—keys, upstream configs, and lateral movement to app servers.
Bottom line
CVE-2026-107806 shows how backup/restore features become RCE when signing keys ride along with the backup download and TestConfigCmd is writable through restore. Upgrade to nginx-ui 2.5.0+, lock the panel off the public internet, and audit restore + test API usage—especially if you previously mitigated CVE-2026-42238 but not 2.5.0.