CVE-2026-84312: Nginx UI: Casdoor SSO callback uses a constant `state` parameter (login CSRF)
Summary
In the Casdoor SSO flow, the OAuth state parameter is hard-coded to settings.CasdoorSettings.Application — a value identical for every user and every login. The callback handler accepts whatever state the client sends without comparing it to anything stored in the user agent, enabling a login-CSRF: an attacker can force the victim's browser to authenticate as the attacker.
Details
api/user/casdoor.go:92-117 (GetCasdoorUri):
go func GetCasdoorUri(c gin.Context) { clientId := settings.CasdoorSettings.ClientId redirectUri := settings.CasdoorSettings.RedirectUri state := settings.CasdoorSettings.Application // ← constant ... c.JSON(http.StatusOK, gin.H{ "uri": fmt.Sprintf( "%s/login/oauth/authorize?clientid=%s&responsetype=code&redirecturi=%s&state=%s&scope=read", endpoint, clientId, encodedRedirectUri, state), }) }
api/user/casdoor.go:24-90 (CasdoorCallback):
go type CasdoorLoginUser struct { Code string json:"code" binding:"required,max=255" State string json:"state" binding:"required,max=255" }
func CasdoorCallback(c gin.Context) { var loginUser CasdoorLoginUser if !cosy.BindAndValid(c, &loginUser) { return } ... // state is NEVER compared to a per-session value token, err := casdoorsdk.GetOAuthToken(loginUser.Code, loginUser.State) ... u, err := user.GetUser(claims.Name) // username from Casdoor's JWT ... userToken, err := user.GenerateJWT(u) // JWT minted for whatever user came back }
Compare with the OIDC implementation in api/user/oidc.go:35-48, which generates a random state, stores it in an oidcstate cookie, and validates it on the callback. Casdoor has no such check.
Proof of Concept
1. Attacker initiates a Casdoor authorisation flow on their own browser, obtaining an authorisation code for their Casdoor account. 2. Attacker hosts a page that auto-submits the captured code to the victim's nginx-ui:
html <html><body><form action="https://victim.example/api/casdoorcallback" method="POST" enctype="text/plain" id="x"> <input name='{"code":"<attackercode>","state":"<App>","junk":"' value='"}'> </form> <script>document.getElementById('x').submit()</script> </body></html>
3. Server exchanges the attacker's code, looks up the username from claims.Name in the local user table, and mints a JWT for that row. The callback also sets the nginxuisecuresession cookie via middleware.EnsureSecureSessionCookie(c) (casdoor.go:84) — meaning the victim is now silently authenticated as the attacker. 4. Victim, believing they are using their own account, configures sites / TLS keys; the attacker reads them.
Impact
Login CSRF — the victim is forced to authenticate as the attacker, leading to data exfiltration of anything the victim subsequently uploads or configures. Particularly dangerous when nginx-ui is used by an organisation where Casdoor maps internal identities — the attacker can attribute their changes to the victim.
Patches
Mirror the OIDC implementation:
diff + import ( + "crypto/rand" + "crypto/subtle" + "encoding/hex" + ... + )
func GetCasdoorUri(c gin.Context) { ... - state := settings.CasdoorSettings.Application + b := make([]byte, 16) + if , err := rand.Read(b); err != nil { + cosy.ErrHandler(c, err); return + } + state := hex.EncodeToString(b) + c.SetSameSite(http.SameSiteLaxMode) + c.SetCookie("casdoorstate", state, 600, "/", "", + cSettings.ServerSettings.EnableHTTPS, true) ... }
func CasdoorCallback(c gin.Context) { + expected, err := c.Cookie("casdoorstate") + if err != nil { + c.AbortWithStatusJSON(http.StatusBadRequest, + gin.H{"message":"missing state cookie"}); return + } var loginUser CasdoorLoginUser if !cosy.BindAndValid(c, &loginUser) { return } + if subtle.ConstantTimeCompare([]byte(expected), []byte(loginUser.State)) != 1 { + c.AbortWithStatusJSON(http.StatusBadRequest, + gin.H{"message":"invalid state"}); return + } ... }
Workarounds
Disable Casdoor SSO until patched. The OIDC integration in api/user/oidc.go is correctly implemented and can be used as a substitute.
References
api/user/casdoor.go:92-117 api/user/casdoor.go:24-90 api/user/oidc.go:35-48 (correct implementation for comparison)
Credits
Vishal Shukla (@shukla304) and Sechub.dev AI Agent.
Other sources
Nginx UI is a web user interface for the Nginx web server. Prior to 2.4.1, GetCasdoorUri uses the configured Casdoor application name as a constant OAuth state value and CasdoorCallback does not compare the submitted state with a value bound to the initiating browser session. An unauthenticated attacker can cause a victim's browser to complete an attacker-controlled Casdoor authorization flow, and the callback can mint a Nginx UI session for the identity returned by that authorization code. This issue is fixed in version 2.4.1.
— NVD
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
go/github.com/0xJacky/Nginx-UIto a version that resolves this vulnerability.Fixed in 1.9.10-0.20260703131214-23d1934099b0 - Upgrade
Upgrade
nginx-uito a version that resolves this vulnerability.Fixed in 2.4.1 - Configuration
Disable Casdoor SSO until Nginx UI is patched.
Nginx UI Casdoor SSO Casdoor SSO = disabled
Event History
Frequently Asked Questions
Which deployments are affected?
Nginx UI versions prior to 2.4.1 are affected when Casdoor SSO is configured and used. The issue is in the Casdoor OAuth callback flow.
What does an attacker need to exploit this?
An attacker does not need to authenticate to Nginx UI. They need to cause a victim to complete an attacker-controlled Casdoor authorization flow, such as by getting the victim's browser to follow the flow.
What is the practical impact on a victim?
The callback can create a Nginx UI session in the victim's browser for the identity returned by the attacker-controlled authorization code. This can result in the victim being logged into the wrong account.
How can this be remediated?
Upgrade Nginx UI to version 2.4.1, which fixes the constant OAuth state handling and validates state against the initiating browser session.