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.
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.
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.
settings/node.go:
- Secret (protected) - used for cluster node authentication
- SkipInstallation (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
GET /api/settingsNodeSecret - attacker can impersonate cluster nodesClientSecret - attacker can perform OAuth flows as the applicationIPWhiteList - attacker learns network security configurationJwtSecret is in app settings (via cosy framework), attacker can forge authentication tokens for any user1. 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": "...", ...}
}
JwtSecret can forge valid JWT tokens for any user, including admin accounts. This provides permanent, independent access that survives password changes and session revocations.NodeSecret is 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.ClientSecret and Casdoor ClientSecret allow the attacker to perform OAuth flows as the nginx-ui application, potentially gaining access to user accounts on the identity provider.IPWhiteList, ReloadCmd, RestartCmd, ConfigDir, SbinPath, and other protected fields reveal the security posture and infrastructure layout, enabling more targeted attacks.GET /api/settings. In multi-user deployments, a low-privilege operator can escalate to full admin access.Filter out protected:"true" fields before serialization.
{
"cwe_ids": [
"CWE-200"
],
"github_reviewed": true,
"github_reviewed_at": "2026-05-06T17:01:04Z",
"nvd_published_at": "2026-05-04T21:16:32Z",
"severity": "MODERATE"
}