File: internal/controller/oauth_controller.go (lines 211)
Project: tinyauth
Severity: BUG • Confidence: high • Slug: other-panic-dos
Finding
On line 211, when the OAuth provider returns a user object without Name set, the handler builds a fallback name with strings.Split(user.Email, "@")[1]. The earlier guard on line 180 only ensures user.Email != "", not that it is well-formed. If an OAuth provider (especially a custom/self-hosted one, or a misbehaving/malicious upstream) returns an email like "alice" with no @, strings.Split returns a one-element slice and [1] panics with an index-out-of-range. gin.Recovery() catches the panic and returns 500, so this is request-scoped (no server crash), but it makes the login flow easy to break with a malformed identity from the provider. Note that on line 221 the same user.Email is used safely via strings.Replace, so the inconsistency is just at the name-fallback site.
Recommendation
Either parse the email with mail.ParseAddress and bail with an error redirect when malformed, or guard the split: parts := strings.SplitN(user.Email, "@", 2); if len(parts) < 2 { ... }. Reusing utils.CompileUserEmail-style validation would be consistent with the rest of the codebase.
Revalidation
Verdict: true-positive
Verified on line 211: name = fmt.Sprintf("%s (%s)", utils.Capitalize(strings.Split(user.Email, "@")[0]), strings.Split(user.Email, "@")[1]). The only prior guard on line 180 checks user.Email != "", not that it contains @. If a (custom/self-hosted/malicious) OAuth provider returns a userinfo response with email: "alice", strings.Split returns ["alice"], and [1] panics with runtime index-out-of-range. gin.Recovery() (registered in router_bootstrap.go line 17) catches the panic and returns HTTP 500, so the impact is per-request — no server crash, but the OAuth login flow is reliably broken with a malformed email from the provider. Line 221 handles the same field defensively (strings.Replace(user.Email, "@", "_", 1)), confirming the inconsistency. Correctly classified BUG.
File:
internal/controller/oauth_controller.go(lines 211)Project: tinyauth
Severity: BUG • Confidence: high • Slug:
other-panic-dosFinding
On line 211, when the OAuth provider returns a user object without
Nameset, the handler builds a fallback name withstrings.Split(user.Email, "@")[1]. The earlier guard on line 180 only ensuresuser.Email != "", not that it is well-formed. If an OAuth provider (especially a custom/self-hosted one, or a misbehaving/malicious upstream) returns an email like"alice"with no@,strings.Splitreturns a one-element slice and[1]panics with an index-out-of-range. gin.Recovery() catches the panic and returns 500, so this is request-scoped (no server crash), but it makes the login flow easy to break with a malformed identity from the provider. Note that on line 221 the sameuser.Emailis used safely viastrings.Replace, so the inconsistency is just at the name-fallback site.Recommendation
Either parse the email with
mail.ParseAddressand bail with an error redirect when malformed, or guard the split:parts := strings.SplitN(user.Email, "@", 2); if len(parts) < 2 { ... }. Reusingutils.CompileUserEmail-style validation would be consistent with the rest of the codebase.Revalidation
Verdict: true-positive
Verified on line 211:
name = fmt.Sprintf("%s (%s)", utils.Capitalize(strings.Split(user.Email, "@")[0]), strings.Split(user.Email, "@")[1]). The only prior guard on line 180 checksuser.Email != "", not that it contains@. If a (custom/self-hosted/malicious) OAuth provider returns a userinfo response withemail: "alice",strings.Splitreturns["alice"], and[1]panics with runtime index-out-of-range.gin.Recovery()(registered in router_bootstrap.go line 17) catches the panic and returns HTTP 500, so the impact is per-request — no server crash, but the OAuth login flow is reliably broken with a malformed email from the provider. Line 221 handles the same field defensively (strings.Replace(user.Email, "@", "_", 1)), confirming the inconsistency. Correctly classified BUG.