CVE-2026-33030 is an insecure direct object reference in Nginx UI, scored CVSS 8.8. Any authenticated user can read, change and delete resources that belong to other users. It affects 2.3.3 and earlier, and at the time of publication there was no public patch.
What's affected
The GitHub advisory says all versions up to and including 2.3.3 are affected, and that at publication there were no publicly available patches. The related 2.3.4 release fixed a different issue, the backup flaw CVE-2026-33026, and I could not confirm that it addresses this one. Check advisory GHSA-5hf2-vhj6-gj9m for current status.
The cause given is that the base Model struct has no user_id field, and endpoints look records up by ID with no ownership check. The advisory raised the score from 7.5 to 8.8 after finding that DNS provider API tokens and ACME private keys are stored in plaintext.
How to check if you're exposed
Check your Nginx UI version and whether more than one person has an account. In a single user install, the practical risk is lower, because there is no other user's data to reach. In a multi user setup, every account is a risk.
Then list what is stored: DNS provider credentials for certificate issuance, ACME account keys and other settings. The advisory names Cloudflare, Alibaba Cloud DNS, Tencent Cloud DNS, AWS Route 53 and GoDaddy credential fields as examples of what is at stake.
What to do now
- Check the advisory GHSA-5hf2-vhj6-gj9m for a fixed release, and upgrade when one exists.
- Reduce the number of accounts to those you truly need, and remove shared logins.
- Use DNS API tokens with the narrowest scope your certificate process needs.
- Rotate DNS and cloud credentials stored in Nginx UI if untrusted users ever had accounts.
- Keep the interface behind a VPN or an allowlist.
If you run Nginx UI for a single administrator, the exposure is smaller, because there is no second user whose data can be reached. The risk grows with every extra account.
The advisory shows why plaintext storage matters. DNS provider credentials sit in the application's data, so a user who can read another user's record can read those tokens directly. Where your provider supports it, create tokens limited to the zones and actions that certificate issuance needs, so a leaked token cannot change unrelated records.
Watch the advisory for a release that adds an ownership check to every lookup. That check is the real fix for this class of bug.
Why it matters
The weaknesses in the record are CWE-639, authorization bypass through a user controlled key, and CWE-78, OS command injection. The advisory text describes the first, an IDOR, where the caller picks the record number and the server never asks who owns it. The record also tags OS command injection, which the advisory text I read does not explain in detail.
IDOR bugs are easy to write and easy to miss, because everything works for normal users. The fix is an ownership check on every lookup. Plaintext storage of credentials turned a data access bug into a credential theft path. The record's KEV flag is false.
Quick check
Is there a patch?
At publication the advisory said no public patch existed. Check the advisory for updates before assuming that still holds.
Sources
Last reviewed: 19 October 2026.
