CVE-2026-58422
Gitea Análisis y mitigación de vulnerabilidades

Vista general

CVE-2026-58422 is an improper authorization vulnerability in Gitea's OAuth2 sign-in callback that silently re-enables administrator-disabled user accounts. It affects Gitea Open Source Git Server versions up to and including 1.26.1, and was published on July 3, 2026. The vulnerability was patched in version 1.26.4. It carries a CVSS v3.1 base score of 9.8 (Critical) per NVD estimates, while the official GitHub Security Advisory assigns a CVSS v4.0 score of 7.6 (High) (GitHub Advisory, Gitea Release).

Técnicas

The root cause is improper access control (CWE-284) in the OAuth2 callback handler located at routers/web/auth/oauth.go::handleOAuth2SignIn. When a user authenticates via a linked external identity provider, the handler reads the local user's IsActive flag and, if it is false, unconditionally sets opts.IsActive = optional.Some(true), calls user_service.UpdateUser, and immediately issues an authenticated session — all within the same response. This treats the administrator-set IsActive=false flag as stale bookkeeping to reconcile against the external IdP, rather than as an authoritative administrative override. The local-credential sign-in path correctly handles the IsErrUserInactive condition by blocking access; only the OAuth callback path bypasses this check. The fix distinguishes between accounts disabled by an administrator (where OAuth link tokens remain intact) and accounts deactivated by the sync cron job (where tokens are cleared), reactivating only the latter (GitHub Advisory, Fix PR).

Impacto

A user whose account has been disabled by a site administrator can silently re-enable their own account by completing a single OAuth2 authentication flow with any previously linked external identity provider, regaining full read and write access to their repositories, organizations, and access tokens without any administrator action or notification. In SSO-fronted Gitea deployments, this defeats the primary short-term incident-response mechanism — the "Disable Account" toggle — available to administrators before the underlying federated identity can be revoked at the IdP level. This is particularly critical for scenarios involving compromised accounts or offboarded employees where immediate access revocation is required (GitHub Advisory).

Pasos de explotación

  1. Prerequisite — Link an external IdP: The target user (e.g., alice) must have previously authenticated through a configured OAuth2/OIDC source (e.g., Keycloak, GitHub, GitLab, Google, or another Gitea instance acting as OIDC), which creates a row in the external_login_user table linking the local account to the IdP identity.
  2. Administrator disables the account: A site administrator navigates to Site Administration → User Accounts → alice → "Disable Account", setting IsActive=false on the local user row. This can be verified via GET /api/v1/admin/users/alice returning "active": false.
  3. Attacker initiates OAuth login: The disabled user navigates to the Gitea login page and clicks "Sign in with [IdP Name]", initiating the standard OAuth2 authorization code flow with the external identity provider.
  4. Complete the OAuth dance: The user authenticates successfully with the external IdP, which redirects back to Gitea's callback endpoint: GET /user/oauth2/{source-name}/callback?code=...&state=....
  5. Callback bypasses the disable check: The handleOAuth2SignIn handler in routers/web/auth/oauth.go reads IsActive=false, sets opts.IsActive = optional.Some(true), calls UpdateUser to flip the flag in the database, and issues a fresh authenticated session cookie in the same HTTP response.
  6. Account re-enabled silently: The user is redirected to / with a valid session. The admin API now returns "active": true without any administrator action, and the user has full access to their repositories, organizations, and tokens (GitHub Advisory, Fix PR).

Indicadores de compromiso

  • Logs: Gitea access logs showing a successful GET /user/oauth2/{source-name}/callback request followed by a session establishment for a user account that was previously marked as disabled; look for HTTP 302 redirects to / from the OAuth callback endpoint for known-disabled accounts.
  • Database / Audit: Unexpected changes to the user table where is_active transitions from 0 to 1 without a corresponding administrator action in the audit log; cross-reference with external_login_user table entries to identify OAuth-linked accounts.
  • API Monitoring: Repeated or unexpected GET /api/v1/admin/users/{username} responses returning "active": true for accounts that were previously confirmed disabled via the same endpoint.
  • Network: OAuth callback requests (/user/oauth2/*/callback) originating from IP addresses or user agents associated with previously offboarded or suspended users (GitHub Advisory).

Mitigación y soluciones alternativas

Upgrade to Gitea version 1.26.4 (or later), which contains the fix backported from the main branch (PR #38009/#38183). Note that version 1.26.3 introduced a regression causing "context deadline exceeded" errors on repository code pages and should be skipped — upgrade directly to 1.26.4. As a temporary workaround prior to patching, administrators can disable the OAuth2 authentication source(s) via Site Administration → Authentication Sources to prevent the callback from being reachable, or revoke the user's linked identity at the external IdP level to prevent successful IdP authentication. Administrators should also audit all currently disabled accounts to verify their IsActive status has not been silently flipped (Gitea Release, Fix PR).

Reacciones de la comunidad

The vulnerability was published by Gitea maintainer lunny via the GitHub Security Advisory on July 1, 2026, and the fix was contributed by community member bircni. The fix PR notes that the change reverts a partial behavior introduced in PR #31572 (which allowed sync-cron-disabled users to reactivate via OAuth), and the updated fix carefully distinguishes between admin-disabled and sync-disabled accounts to preserve the intended behavior of both flows. The release of v1.26.4 received positive community reactions on GitHub, with 21 users reacting to the release announcement (GitHub Advisory, Gitea Release).

Recursos adicionales


FuenteEste informe se generó utilizando IA

Relacionado Gitea Vulnerabilidades:

CVE ID

Severidad

Puntuación

Tecnologías

Nombre del componente

Exploit de CISA KEV

Tiene arreglo

Fecha de publicación

CVE-2026-58422CRITICAL9.8
  • Gitea logoGitea
  • gitea
NoNoJul 03, 2026
CVE-2026-58426CRITICAL9.6
  • Gitea logoGitea
  • gitea
NoNoJul 03, 2026
CVE-2026-58424HIGH8.9
  • Gitea logoGitea
  • gitea
NoNoJul 03, 2026
CVE-2026-58423HIGH7.7
  • Gitea logoGitea
  • gitea
NoNoJul 03, 2026
CVE-2026-42505MEDIUM5.3
  • cAdvisor logocAdvisor
  • crossplane-provider-gcp-beta-compute
NoJul 08, 2026

Evaluación gratuita de vulnerabilidades

Compare su postura de seguridad en la nube

Evalúe sus prácticas de seguridad en la nube en 9 dominios de seguridad para comparar su nivel de riesgo e identificar brechas en sus defensas.

Solicitar evaluación

Recursos adicionales de Wiz

Obtén una demostración personalizada

¿Listo para ver a Wiz en acción?

"La mejor experiencia de usuario que he visto en mi vida, proporciona una visibilidad completa de las cargas de trabajo en la nube."
David EstlickCISO
"Wiz proporciona un panel único para ver lo que ocurre en nuestros entornos en la nube."
Adam FletcherJefe de Seguridad
"Sabemos que si Wiz identifica algo como crítico, en realidad lo es."
Greg PoniatowskiJefe de Gestión de Amenazas y Vulnerabilidades