nginx-ui 'MCPwn' (CVE-2026-33032) - Auth Bypass & Active Exploitation

We use it strictly for internal dev dashboards, but we found two instances accidentally exposed to the public VPC. We've since blocked it at the security group level. It's a handy tool, but exposing a management interface directly to the internet is asking for trouble. I'd recommend sticking to raw configs or Ansible for prod.

I've been analyzing the PoC code for this. The bypass is worryingly simple—it basically fails to validate the session token on specific endpoints. If attackers hit this, they aren't just defacing sites; they are injecting new server blocks to proxy traffic or serve malware.

Here is a basic KQL query to hunt for successful config changes in your Sysmon/EDR logs if you have file logging enabled:

DeviceFileEvents
| where FileName contains "nginx.conf"
| where InitiatingProcessFileName != "nginx"
| project Timestamp, DeviceName, InitiatingProcessAccountName,FolderPath


If you see `systemd` or a weird Python/Bash process touching that file, you are already compromised.

Just patched our staging environment. The fix was literally just a version bump to the latest commit, but the downtime was annoying. For those running it, put it behind a secondary auth proxy like OAuth2-Proxy immediately. It adds a layer of defense in depth that saves you when the app logic fails like this.

Good call on the proxy, Priya. For those unsure if they've already been compromised, I recommend auditing your access logs immediately. Since this bypasses normal auth, look for successful requests to configuration endpoints lacking a preceding login event.

You can quickly check for suspicious configuration changes using this one-liner on the host:

grep "POST /api" /var/log/nginx-ui/access.log | awk '{print $1, $7}' | sort | uniq

This lists unique IPs and endpoints, helping you spot unauthorized modifications immediately.

To assist with the log auditing SA_Admin_Staff mentioned, I recommend grepping for successful API calls that lack a valid session cookie. This helps identify the "ghost" administrative actions typical of this bypass:

awk '(/POST.*api/ || /PUT.*api/) && $9 == 200 && !/nginx_ui_session/ {print $1, $4, $7}' /var/log/nginx/access.log


If you find hits, assume your Nginx configurations have been tampered with and roll back from backups immediately.

Excellent points on log auditing. However, since the vulnerability allows modifying Nginx configurations, you should also verify that no backdoors were introduced before the patch was applied. If the attacker had access, they likely altered config files to maintain persistence. Verify the integrity of your configurations by checking for recent changes:

find /etc/nginx -name "*.conf" -mtime -2

This helps ensure you didn't lock the door while the intruder is still inside.

While patching and checking logs is crucial, don't stop there. Since this vulnerability allows full config control, attackers may have established persistence. Simply patching doesn't remove a backdoor they might have injected into your Nginx config. Compare your active config against your backups to find lingering artifacts.

diff -u /etc/nginx/nginx.conf /path/to/backup/nginx.conf

This helps ensure you haven't left a door open for them to return later.

If you can't patch immediately, consider a ModSecurity rule as a stopgap. This snippet blocks requests to the admin API if both Authorization and Cookie headers are missing, directly targeting the bypass mechanism described in the PoC.

apache SecRule REQUEST_URI "@beginsWith /api/admin"
"chain,phase:1,deny,status:403,id:1001,msg:'Block Unauth Access'" SecRule &REQUEST_HEADERS:Authorization "@eq 0"
"chain" SecRule &REQUEST_HEADERS:Cookie "@eq 0"