https://cve.radiocsirt.org Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Fri, 09 Oct 2026 11:14:16 +0000 https://cve.radiocsirt.org/vuln/cve-2026-55987 <p><strong>Affected:</strong> Gitea Open Source Git Server</p> <p>OAuth2 sign-in reactivates an administrator-deactivated account on auth sources without refresh tokens (incomplete fix of #38009)</p> <p><strong>Affected:</strong> Gitea Open Source Git Server</p> <p>OAuth2 sign-in reactivates an administrator-deactivated account on auth sources without refresh tokens (incomplete fix of #38009)</p> https://cve.radiocsirt.org/vuln/cve-2026-55987 https://cve.radiocsirt.org/vuln/ghsa-vrhc-jjfc-m3m3 <p><strong>Affected:</strong> Go: code.gitea.io/gitea</p> <p>## Description</p> <p>Gitea&#39;s OAuth2 sign-in callback reactivates a deactivated user account (`IsActive=false`) when the user signs in through an authentication source that does not issue refresh tokens (notably GitHub, and any OIDC/OAuth2 source configured without `offline_access`). PR #38009 added a gate intended to reactivate users only when the OAuth2 auto-sync cron had disabled them, using &#34;the stored refresh token is empty&#34; as the signal. That signal is wrong: for sources that never issue refresh tokens, an empty refresh token is the normal state of every user, so the gate cannot distinguish a cron-disabled account from one an administrator deliberately deactivated. The next time the administrator-deactivated user signs in through the provider, Gitea sets `IsActive=true` and grants a full session, silently undoing the administrator&#39;s action. This is the exact behavior #38009 was written to prevent. (`ProhibitLogin`, the hard ban, is enforced separately and is not affected.)</p> <p>No special privileges are required beyond being the deactivated user and being able to sign in through the source.</p> <p>### Root Cause</p> <p>`routers/web/auth/oauth.go` (the `handleOAuth2SignIn` reactivation gate):</p> <p>```go if !u.IsActive { extLogin, hasExt, err := user_model.GetExternalLogin(ctx, authSource.ID, gothUser.UserID) if err != nil { ctx.ServerError(&#34;GetExternalLogin&#34;, err); return } isDisabledByAutoSync := hasExt &amp;&amp; extLogin.RefreshToken == &#34;&#34; // wrong signal if isDisabledByAutoSync {…</p> <p><strong>Affected:</strong> Go: code.gitea.io/gitea</p> <p>## Description</p> <p>Gitea&#39;s OAuth2 sign-in callback reactivates a deactivated user account (`IsActive=false`) when the user signs in through an authentication source that does not issue refresh tokens (notably GitHub, and any OIDC/OAuth2 source configured without `offline_access`). PR #38009 added a gate intended to reactivate users only when the OAuth2 auto-sync cron had disabled them, using &#34;the stored refresh token is empty&#34; as the signal. That signal is wrong: for sources that never issue refresh tokens, an empty refresh token is the normal state of every user, so the gate cannot distinguish a cron-disabled account from one an administrator deliberately deactivated. The next time the administrator-deactivated user signs in through the provider, Gitea sets `IsActive=true` and grants a full session, silently undoing the administrator&#39;s action. This is the exact behavior #38009 was written to prevent. (`ProhibitLogin`, the hard ban, is enforced separately and is not affected.)</p> <p>No special privileges are required beyond being the deactivated user and being able to sign in through the source.</p> <p>### Root Cause</p> <p>`routers/web/auth/oauth.go` (the `handleOAuth2SignIn` reactivation gate):</p> <p>```go if !u.IsActive { extLogin, hasExt, err := user_model.GetExternalLogin(ctx, authSource.ID, gothUser.UserID) if err != nil { ctx.ServerError(&#34;GetExternalLogin&#34;, err); return } isDisabledByAutoSync := hasExt &amp;&amp; extLogin.RefreshToken == &#34;&#34; // wrong signal if isDisabledByAutoSync {…</p> https://cve.radiocsirt.org/vuln/ghsa-vrhc-jjfc-m3m3