CVE-2026-42223
Nginx UI vulnerability analysis and mitigation

Overview

CVE-2026-42223 is a sensitive information exposure vulnerability in Nginx UI, a web-based management interface for the Nginx web server. The GetSettings API handler (api/settings/settings.go:24-65) serializes all settings structs to JSON and returns them to any authenticated user, completely ignoring the protected:"true" struct tags that are only enforced during write operations. This exposes 40+ protected fields including JwtSecret, NodeSecret, OIDC ClientSecret, and IP whitelist configuration. All versions up to and including 2.3.7 are affected; the issue was patched in version 2.3.8, released April 21, 2026, and publicly disclosed on April 27, 2026. The CVSS v3.1 base score is 6.5 (Medium) (Github Advisory, GitHub Security Advisory).

Technical details

The root cause is an asymmetric access control design flaw (CWE-200: Exposure of Sensitive Information to an Unauthorized Actor). In Go, the custom protected:"true" struct tag has no effect on json.Marshal serialization — it is a developer-defined tag with no built-in enforcement. The ProtectedFill function is called 10 times within SaveSettings to prevent overwriting sensitive fields on write, but is never invoked in GetSettings, meaning any authenticated HTTP GET to /api/settings returns the full unfiltered JSON payload. The attack requires only a valid Bearer token (low-privilege user credentials suffice), no special configuration, and no user interaction, making it trivially exploitable over the network (Github Advisory, GitHub Security Advisory).

Impact

Successful exploitation allows any authenticated user to retrieve over 40 sensitive configuration secrets in a single API call. Obtaining the JwtSecret enables an attacker to forge valid JWT tokens for any user account — including administrators — providing persistent access that survives password changes and session revocations. The NodeSecret can be used to impersonate cluster nodes, push malicious Nginx configurations across all nodes, and intercept cluster synchronization traffic. Leaked OIDC and Casdoor ClientSecret values enable OAuth account takeover on connected identity providers, while disclosure of IPWhiteList, ReloadCmd, RestartCmd, ConfigDir, and SbinPath reveals the security posture and infrastructure layout for further targeted attacks (Github Advisory).

Exploitability

A proof-of-concept exploit is publicly documented in the GitHub Security Advisory, consisting of a single authenticated HTTP GET request to /api/settings with a Bearer token. The advisory itself constitutes a concrete, reproducible attack sequence. No evidence of active in-the-wild exploitation has been reported as of the time of writing. The EPSS score is approximately 0.031–0.042%, placing it in the 13th percentile for exploitation probability. The vulnerability is not currently listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. No specific threat actor attribution has been identified (Github Advisory, GitHub Security Advisory).

Exploitation steps

  1. Obtain valid credentials: Acquire any valid Nginx UI account credentials — even a low-privilege operator account is sufficient. No administrative access is required.
  2. Authenticate and retrieve a Bearer token: Log in to the Nginx UI instance via the web interface or API to obtain a valid JWT Bearer token for the session.
  3. Send the exploit request: Issue a simple HTTP GET request to the settings endpoint:
GET /api/settings HTTP/1.1
Host: <target-nginx-ui>
Authorization: Bearer <your_token>
  1. Extract sensitive secrets from the response: Parse the JSON response to extract high-value fields, including:
    • app.jwt_secret — for forging admin JWT tokens
    • node.secret — for cluster node impersonation
    • oidc.client_secret / casdoor.client_secret — for OAuth account takeover
    • auth.ip_white_list — to understand network access controls
  2. Forge admin JWT tokens (optional escalation): Using the extracted JwtSecret, craft a signed JWT token for an administrator account using any standard JWT library, granting persistent admin-level access independent of the original credentials.
  3. Impersonate cluster nodes or perform OAuth flows (optional lateral movement): Use the NodeSecret to authenticate as a cluster node and push malicious Nginx configurations, or use the OIDC ClientSecret to perform OAuth flows as the Nginx UI application against the identity provider (Github Advisory, GitHub Security Advisory).

Indicators of compromise

  • Network: Authenticated HTTP GET requests to /api/settings from non-administrative user accounts or from unexpected source IPs; unusual outbound connections from the Nginx UI host following a settings API call (potential exfiltration).
  • Logs: Nginx UI access logs showing GET /api/settings requests from low-privilege user accounts or at unusual times; multiple rapid sequential requests to /api/settings from the same account (automated scraping).
  • Authentication Events: New JWT tokens appearing for administrator accounts without corresponding login events; authentication attempts to OIDC/OAuth identity providers using the application's client_id from unexpected IP addresses.
  • Cluster Activity: Unexpected new nodes joining the Nginx UI cluster; configuration changes pushed across cluster nodes without corresponding admin activity in the audit log.

Mitigation and workarounds

Upgrade Nginx UI to version 2.3.8 or later, which introduces a 2FA-gated reveal flow for sensitive settings and proper masking of sensitive values in the UI, preventing unfiltered serialization of protected fields (GitHub Release). If an immediate upgrade is not possible, restrict access to the Nginx UI interface to trusted administrators only using network-level controls (firewall rules, VPN, or reverse proxy authentication), and monitor API access logs for any GET /api/settings requests from non-administrative accounts. Additionally, consider rotating all secrets (JWT secret, node secret, OIDC client secret) if the instance was accessible to non-admin authenticated users prior to patching, as those secrets should be considered compromised (Github Advisory).

Community reactions

Heise Online covered the vulnerability with an article titled "Critical security vulnerability in Nginx UI closed again," noting the recurring nature of security issues in the project (Heise). The vulnerability was reported by security researcher yotampe-pluto and received coverage from multiple vulnerability tracking platforms including VulnDB, Vulners, and CIRCL. Social media activity was observed on Bluesky and Nitter/Twitter via the CVEnew account. Community sentiment reflected concern about the low barrier to exploitation — any authenticated user could trigger the disclosure — and the breadth of secrets exposed in a single API call.

Additional resources


SourceThis report was generated using AI

Related Nginx UI vulnerabilities:

CVE ID

Severity

Score

Technologies

Component name

CISA KEV exploit

Has fix

Published date

CVE-2026-44015CRITICAL9.9
  • Nginx UI logoNginx UI
  • cpe:2.3:a:nginxui:nginx_ui
NoYesMay 12, 2026
CVE-2026-42222CRITICAL9.8
  • Nginx UI logoNginx UI
  • cpe:2.3:a:nginxui:nginx_ui
NoYesMay 04, 2026
CVE-2026-42221CRITICAL9.8
  • Nginx UI logoNginx UI
  • github.com/0xJacky/Nginx-UI
NoYesMay 04, 2026
CVE-2026-42238CRITICAL9
  • Nginx UI logoNginx UI
  • github.com/0xJacky/Nginx-UI
NoYesMay 04, 2026
CVE-2026-42223MEDIUM6.5
  • Nginx UI logoNginx UI
  • github.com/0xjacky/nginx-ui
NoYesMay 04, 2026

Free Vulnerability Assessment

Benchmark your Cloud Security Posture

Evaluate your cloud security practices across 9 security domains to benchmark your risk level and identify gaps in your defenses.

Request assessment

Get a personalized demo

Ready to see Wiz in action?

"Best User Experience I have ever seen, provides full visibility to cloud workloads."
David EstlickCISO
"Wiz provides a single pane of glass to see what is going on in our cloud environments."
Adam FletcherChief Security Officer
"We know that if Wiz identifies something as critical, it actually is."
Greg PoniatowskiHead of Threat and Vulnerability Management