CVE-2026-42223 — nginx-ui
MEDIUMCVE-2026-42223 is a medium-severity (CVSS 6.5) Information Exposure vulnerability in github.com/0xJacky/nginx-ui. A fix is available for github.com/0xJacky/nginx-ui — see the affected versions and patch details below.
nginx-ui: Settings API Exposes Protected Secrets
Exploitation Status
Proof-of-concept exploit code exists
- CISA’s SSVC triage found public proof-of-concept exploit code for this CVE, though no confirmed active exploitation.
Exploitation and automatability from CISA’s SSVC triage for CVE-2026-42223.
EPSS Exploitation Probability
EPSS (Exploit Prediction Scoring System) is a daily probability model maintained by FIRST.org. It estimates the likelihood a CVE will be exploited in production environments within the next 30 days, derived from real-world threat intelligence signals.
How urgent is this, really
CVE-2026-42223 plotted by exploitation likelihood (EPSS) against impact (CVSS). The shaded corner — EPSS 50%+ and CVSS 7.0+ — is where this CVE doesn't sit, though severity or exploitability alone can still warrant action.
Where this sits among everything scored
Of 377,636 CVEs with a current EPSS score, this one falls in the < 10% band (highlighted). Real counts from FIRST.org, not a sample — log-scaled since the landscape is heavily right-skewed.
Real-World Exposure
github.com/0xJacky/nginx-uiReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects Go packages — download data is not available via public APIs for these ecosystems.
Description
Summary
The GetSettings API handler (api/settings/settings.go:24-65) serializes all settings structs to JSON and returns them to authenticated users. Many sensitive fields are tagged with protected:"true" - however, this tag is only enforced during writes (via ProtectedFill in SaveSettings) and is completely ignored during reads. This exposes 40+ protected fields including JwtSecret (enabling auth token forgery), NodeSecret (enabling cluster node impersonation), OIDC ClientSecret (enabling OAuth account takeover), and the IP whitelist configuration.
Details
Vulnerable Code
api/settings/settings.go:49-64 - GetSettings serializes all fields
c.JSON(http.StatusOK, gin.H{
"app": cSettings.AppSettings,
"server": cSettings.ServerSettings,
"database": settings.DatabaseSettings,
"auth": settings.AuthSettings,
"casdoor": settings.CasdoorSettings,
"oidc": settings.OIDCSettings,
"cert": settings.CertSettings,
"http": settings.HTTPSettings,
"logrotate": settings.LogrotateSettings,
"nginx": settings.NginxSettings,
"node": settings.NodeSettings,
"openai": settings.OpenAISettings,
"terminal": settings.TerminalSettings,
"webauthn": settings.WebAuthnSettings,
})
Go's json.Marshal serializes all exported fields with json: tags. The protected:"true" struct tag is a custom tag - it has no effect on JSON serialization.
Protection is Write-Only
api/settings/settings.go:126-135 - ProtectedFill only used during saves
cSettings.ProtectedFill(cSettings.AppSettings, &json.App)
cSettings.ProtectedFill(cSettings.ServerSettings, &json.Server)
cSettings.ProtectedFill(settings.AuthSettings, &json.Auth)
// ... etc
ProtectedFill prevents overwriting protected fields during SaveSettings, but GetSettings has no corresponding filter. The protection is asymmetric - secrets can be read but not overwritten.
Exposed Protected Fields
settings/node.go:
Secret(protected) - used for cluster node authenticationSkipInstallation(protected),Demo(protected)
settings/oidc.go (all protected):
ClientId,ClientSecret,Endpoint,RedirectUri,Scopes,Identifier
settings/casdoor.go (all protected):
Endpoint,ExternalUrl,ClientId,ClientSecret,CertificatePath,Organization,Application,RedirectUri
settings/auth.go:
IPWhiteList(protected) - exposes security configuration
Attack Scenario
- Low-privilege authenticated user calls
GET /api/settings - Response includes
NodeSecret- attacker can impersonate cluster nodes - Response includes OIDC
ClientSecret- attacker can perform OAuth flows as the application - Response includes
IPWhiteList- attacker learns network security configuration - If
JwtSecretis in app settings (via cosy framework), attacker can forge authentication tokens for any user
PoC
1. GetSettings serializes all fields without filtering protected:"true" tags. From api/settings/settings.go:49-64:
c.JSON(http.StatusOK, gin.H{
"app": cSettings.AppSettings,
"server": cSettings.ServerSettings,
"database": settings.DatabaseSettings,
"auth": settings.AuthSettings,
"casdoor": settings.CasdoorSettings,
"oidc": settings.OIDCSettings,
"cert": settings.CertSettings,
"http": settings.HTTPSettings,
"logrotate": settings.LogrotateSettings,
"nginx": settings.NginxSettings,
"node": settings.NodeSettings,
"openai": settings.OpenAISettings,
"terminal": settings.TerminalSettings,
"webauthn": settings.WebAuthnSettings,
})
Go's json.Marshal serializes all exported fields. The custom protected:"true" tag has no effect on serialization.
2. Protected secrets are defined across settings/*.go. High-impact examples:
// settings/server_v1.go:19
JwtSecret string `json:"jwt_secret" protected:"true"`
// settings/node.go:5
Secret string `json:"secret" protected:"true"`
// settings/oidc.go
ClientSecret string `json:"client_secret" protected:"true"`
// settings/auth.go
IPWhiteList []string `json:"ip_white_list" protected:"true"`
3. ProtectedFill is write-only. It appears 10 times in SaveSettings (lines 126-135) but 0 times in GetSettings:
// api/settings/settings.go:126-135 - Only used during writes
cSettings.ProtectedFill(cSettings.AppSettings, &json.App)
cSettings.ProtectedFill(cSettings.ServerSettings, &json.Server)
cSettings.ProtectedFill(settings.AuthSettings, &json.Auth)
// ... 7 more calls
4. Exploit request. Any authenticated user can retrieve all secrets:
GET /api/settings HTTP/1.1
Authorization: Bearer <any-valid-jwt>
Response includes (among 45 protected fields):
{
"app": {"jwt_secret": "<the-actual-jwt-signing-key>", ...},
"node": {"secret": "<node-authentication-secret>", ...},
"oidc": {"client_secret": "<oidc-client-secret>", ...},
"casdoor": {"client_secret": "<casdoor-client-secret>", ...},
"auth": {"ip_white_list": ["10.0.0.1", ...], ...},
"nginx": {"reload_cmd": "nginx -s reload", "restart_cmd": "...", ...}
}
Impact
- Authentication bypass via JwtSecret: An attacker who obtains the
JwtSecretcan forge valid JWT tokens for any user, including admin accounts. This provides permanent, independent access that survives password changes and session revocations. - Cluster compromise via NodeSecret: The
NodeSecretis used for inter-node authentication in nginx-ui clusters. An attacker can impersonate any cluster node, push malicious configurations to all nodes, and intercept cluster synchronization traffic. - Third-party OAuth takeover: Leaked OIDC
ClientSecretand CasdoorClientSecretallow the attacker to perform OAuth flows as the nginx-ui application, potentially gaining access to user accounts on the identity provider. - Security configuration disclosure: The
IPWhiteList,ReloadCmd,RestartCmd,ConfigDir,SbinPath, and other protected fields reveal the security posture and infrastructure layout, enabling more targeted attacks. - Low barrier to exploitation: Any authenticated user (not just admins) can access
GET /api/settings. In multi-user deployments, a low-privilege operator can escalate to full admin access.
Remediation
Filter out protected:"true" fields before serialization.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐹Go | github.com/0xJacky/nginx-ui | all versions | 2.3.8go get github.com/0xJacky/nginx-ui@v2.3.8 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for github.com/0xJacky/nginx-ui, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update github.com/0xJacky/nginx-ui to 2.3.8 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms CVE-2026-42223 is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 Security's impact-aware SCA analyses which vulnerable code paths your application actually calls, so a match like CVE-2026-42223 can be triaged on real exposure rather than presence alone.
Tailored to CVE-2026-42223. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is CVE-2026-42223 in your dependencies?
O3 Security finds CVE-2026-42223 across Go dependencies, including transitive ones, and its impact-aware SCA ranks findings by whether your code actually calls the vulnerable path.