CVE-2026-55987: Gitea Remote Code Execution Vulnerability

HIGH
Advisory Identifier: GHSA-vrhc-jjfc-m3m3
CVSS 8.1
CWE-863
Published
Advisory Summary

CVE-2026-55987 is a HIGH (CVSS 8.1) remote code execution vulnerability (CWE-863: Incorrect Authorization) affecting Gitea libraries in the Go ecosystem. The issue involves oauth2 sign-in reactivates an administrator-deactivated account on auth sources without refresh tokens (incomplete fix of #38009). Remediation is available by upgrading affected packages to version 1.27.0.

CVE-2026-55987 at a Glance

CVE Identifier CVE-2026-55987
GHSA Identifier GHSA-vrhc-jjfc-m3m3
Severity HIGH
CVSS v3.1 Base Score 8.1
CWE Classification CWE-863: Incorrect Authorization
Affected Product Gitea
Package Ecosystem Go
Published Date
Last Updated

Security Impact

CVSS: 8.1

The security impact metrics below are parsed directly from the CVSS v3.1 vector string (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N).

Attack Vector Network (AV:N)
Attack Complexity Low (AC:L)
Privileges Required Low (PR:L)
User Interaction None (UI:N)
Scope Unchanged (S:U)
Confidentiality High (C:H)
Integrity High (I:H)
Availability None (A:N)

How to Fix CVE-2026-55987

To remediate this vulnerability, upgrade all affected Gitea dependencies to a patched release. Both direct and transitive dependencies should be checked, as frameworks or security libraries may pull in vulnerable versions transitively.

code.gitea.io/gitea fixed: 1.27.0
Upgrade code.gitea.io/gitea to 1.27.0
Verify Direct and Transitive Dependencies

Run the following command in your project directory to verify that all resolved dependencies use the patched release:

inspect dependencies for code.gitea.io/gitea

How to Check if You Are Affected

To determine whether your application is affected by CVE-2026-55987, inspect your project dependencies for Gitea:

inspect dependencies for code.gitea.io/gitea

Analyze the terminal output to locate any version of Gitea in your dependency tree. If any resolved version matches the vulnerable ranges listed in the table below (for example, versions earlier than 1.27.0), your application is affected.

Note: Verify declared build manifests and deployed runtime container environments.

Technical Details

Vulnerability Mechanism & Technical Analysis

This vulnerability is classified under CWE-863: Incorrect Authorization, where the product performs an authorization check when an actor attempts to access a resource or perform an action, but it does not correctly perform the check. In Gitea, software state validation or input boundaries are circumvented during processing. Review the official source advisory statement below for specific affected components, classes, and reproduction details.

Source Advisory Statement

## Description Gitea'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 "the stored refresh token is empty" 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's action. This is the exact behavior #38009 was written to prevent. (`ProhibitLogin`, the hard ban, is enforced separately and is not affected.) No special privileges are required beyond being the deactivated user and being able to sign in through the source. ### Root Cause `routers/web/auth/oauth.go` (the `handleOAuth2SignIn` reactivation gate): ```go if !u.IsActive { extLogin, hasExt, err := user_model.GetExternalLogin(ctx, authSource.ID, gothUser.UserID) if err != nil { ctx.ServerError("GetExternalLogin", err); return } isDisabledByAutoSync := hasExt && extLogin.RefreshToken == "" // wrong signal if isDisabledByAutoSync { opts.IsActive = optional.Some(true) // reactivates the account } } ``` The assumption that `RefreshToken == ""` is produced only by the auto-sync cron is false: - The cron's disable path is unreachable for sources without refresh tokens. `services/auth/source/oauth2/source_sync.go` returns early: `if !provider.RefreshTokenAvailable() { return ... }`, so it never disables (or touches the tokens of) such users. - The stored token is exactly what the provider returned, with no synthesizing: `services/externalaccount/user.go` stores `RefreshToken: gothUser.RefreshToken`. When the provider issues none, this is `""` from the first login. - GitHub never issues a refresh token: `goth` hardcodes `func (p *Provider) RefreshTokenAvailable() bool { return false }` (`providers/github/github.go`). OIDC/OAuth2 without `offline_access` likewise store `""`. So for a GitHub (or no-refresh-token) source, `RefreshToken == ""` is the state of every user, including one an administrator deactivated, and the gate reactivates them. ### Proof of Concept Setup: - A Gitea instance with a GitHub authentication source (Admin Panel -> Authentication Sources -> OAuth2 -> GitHub), or any OAuth2/OIDC source configured without `offline_access`. - Account V: a normal user who has signed in at least once through that source (an `external_login_user` row exists with empty `refresh_token`). Steps: 1. As an administrator, open Admin Panel -> Users -> V and uncheck "Activated" (`is_active=false`). Confirm V's requests now bounce to the activation page. 2. As V, sign in again via "Sign in with GitHub" and complete the provider flow. 3. V lands in the application with a working session. `SELECT is_active FROM "user" WHERE lower_name='v';` now returns `true`. Expected (intended by #38009): V stays `is_active=false` and is routed to the activation page. Actual: V is `is_active=true` with a full session — the administrator's deactivation is undone. ``` - GitHub user, ADMIN deactivated refreshToken="" -> REACTIVATED + session granted <<< admin action undone - OIDC user w/ refresh token, ADMIN deactivated refreshToken="..." -> stays disabled (control) - OIDC user, AUTO-SYNC cron disabled refreshToken="" -> REACTIVATED (intended) RESULT: BYPASS CONFIRMED. ``` Gitea's own regression test `TestOAuth2CallbackReactivationGating` ("auto-sync-disabled user is reactivated") sets `RefreshToken=""` and asserts reactivation after a full OIDC callback — that state is identical to a GitHub-source user an administrator deactivated. ### Impact Any Gitea instance using a GitHub authentication source (one of the most common) or an OIDC/OAuth2 source without refresh tokens, that relies on the "Activated" toggle to disable accounts, is affected. A deactivated user restores their own account to active and obtains a session, regaining whatever access the account had. Deactivation does not clear `IsAdmin`, so a deactivated administrator regains admin access. Bound: accounts disabled with "Prohibit Login" stay blocked; this defeats the `IsActive=false` deactivation only.

CVE-2026-55987 Affected Gitea Versions

1 component(s)
Fixed Versions:
1.27.0
Product / Package Ecosystem Affected Versions Fixed Version
code.gitea.io/gitea
Go
< 1.27.0
1.27.0

References

Frequently Asked Questions

What is CVE-2026-55987?
CVE-2026-55987 is a security vulnerability in Gitea involving OAuth2 sign-in reactivates an administrator-deactivated account on auth sources without refresh tokens (incomplete fix of #38009) under CWE-863: Incorrect Authorization.
Which Gitea versions are affected?
Affected versions include releases prior to 1.27.0 across affected packages: code.gitea.io/gitea.
What version fixes CVE-2026-55987?
Upgrading to 1.27.0 (or the latest patched release for your respective branch) resolves the vulnerability.
Is code.gitea.io/gitea affected?
Yes, code.gitea.io/gitea is affected in releases prior to 1.27.0. Upgrade your dependency to 1.27.0 or later.
What is the CVSS score of CVE-2026-55987?
CVE-2026-55987 has a CVSS v3.1 base score of 8.1 (HIGH) with vector string CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N.
What CWE is associated with CVE-2026-55987?
CVE-2026-55987 is classified under CWE-863: Incorrect Authorization (The product performs an authorization check when an actor attempts to access a resource or perform an action, but it does not correctly perform the check.).
How can I check Go dependencies for CVE-2026-55987?
Run the dependency tree command: 'inspect dependencies for code.gitea.io/gitea'. This command lists direct and transitive dependencies in your build configuration so you can verify if a vulnerable version is resolved.
Machine-readable OSV JSON OSV v1.5 Schema
Normalized schema output
{
  "schema_version" : "1.4.0",
  "id" : "GHSA-vrhc-jjfc-m3m3",
  "modified" : "2026-07-21T21:02:10Z",
  "published" : "2026-07-21T21:02:10Z",
  "aliases" : [ "CVE-2026-55987" ],
  "summary" : "Gitea: OAuth2 sign-in reactivates an administrator-deactivated account on auth sources without refresh tokens (incomplete fix of #38009)",
  "details" : "## Description\n\nGitea'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 \"the stored refresh token is empty\" 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's action. This is the exact behavior #38009 was written to prevent. (`ProhibitLogin`, the hard ban, is enforced separately and is not affected.)\n\nNo special privileges are required beyond being the deactivated user and being able to sign in through the source.\n\n### Root Cause\n\n`routers/web/auth/oauth.go` (the `handleOAuth2SignIn` reactivation gate):\n\n```go\nif !u.IsActive {\n    extLogin, hasExt, err := user_model.GetExternalLogin(ctx, authSource.ID, gothUser.UserID)\n    if err != nil { ctx.ServerError(\"GetExternalLogin\", err); return }\n    isDisabledByAutoSync := hasExt && extLogin.RefreshToken == \"\"   // wrong signal\n    if isDisabledByAutoSync {\n        opts.IsActive = optional.Some(true)                          // reactivates the account\n    }\n}\n```\n\nThe assumption that `RefreshToken == \"\"` is produced only by the auto-sync cron is false:\n\n- The cron's disable path is unreachable for sources without refresh tokens. `services/auth/source/oauth2/source_sync.go` returns early: `if !provider.RefreshTokenAvailable() { return ... }`, so it never disables (or touches the tokens of) such users.\n- The stored token is exactly what the provider returned, with no synthesizing: `services/externalaccount/user.go` stores `RefreshToken: gothUser.RefreshToken`. When the provider issues none, this is `\"\"` from the first login.\n- GitHub never issues a refresh token: `goth` hardcodes `func (p *Provider) RefreshTokenAvailable() bool { return false }` (`providers/github/github.go`). OIDC/OAuth2 without `offline_access` likewise store `\"\"`.\n\nSo for a GitHub (or no-refresh-token) source, `RefreshToken == \"\"` is the state of every user, including one an administrator deactivated, and the gate reactivates them.\n\n### Proof of Concept\n\nSetup:\n- A Gitea instance with a GitHub authentication source (Admin Panel -> Authentication Sources -> OAuth2 -> GitHub), or any OAuth2/OIDC source configured without `offline_access`.\n- Account V: a normal user who has signed in at least once through that source (an `external_login_user` row exists with empty `refresh_token`).\n\nSteps:\n1. As an administrator, open Admin Panel -> Users -> V and uncheck \"Activated\" (`is_active=false`). Confirm V's requests now bounce to the activation page.\n2. As V, sign in again via \"Sign in with GitHub\" and complete the provider flow.\n3. V lands in the application with a working session. `SELECT is_active FROM \"user\" WHERE lower_name='v';` now returns `true`.\n\nExpected (intended by #38009): V stays `is_active=false` and is routed to the activation page.\nActual: V is `is_active=true` with a full session — the administrator's deactivation is undone.\n\n```\n- GitHub user, ADMIN deactivated                 refreshToken=\"\"    -> REACTIVATED + session granted   <<< admin action undone\n- OIDC user w/ refresh token, ADMIN deactivated  refreshToken=\"...\" -> stays disabled  (control)\n- OIDC user, AUTO-SYNC cron disabled             refreshToken=\"\"    -> REACTIVATED (intended)\nRESULT: BYPASS CONFIRMED.\n```\n\nGitea's own regression test `TestOAuth2CallbackReactivationGating` (\"auto-sync-disabled user is reactivated\") sets `RefreshToken=\"\"` and asserts reactivation after a full OIDC callback — that state is identical to a GitHub-source user an administrator deactivated.\n\n### Impact\n\nAny Gitea instance using a GitHub authentication source (one of the most common) or an OIDC/OAuth2 source without refresh tokens, that relies on the \"Activated\" toggle to disable accounts, is affected. A deactivated user restores their own account to active and obtains a session, regaining whatever access the account had. Deactivation does not clear `IsAdmin`, so a deactivated administrator regains admin access. Bound: accounts disabled with \"Prohibit Login\" stay blocked; this defeats the `IsActive=false` deactivation only.",
  "severity" : [ {
    "type" : "CVSS_V3",
    "score" : "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N"
  } ],
  "affected" : [ {
    "package" : {
      "ecosystem" : "Go",
      "name" : "code.gitea.io/gitea"
    },
    "ranges" : [ {
      "type" : "ECOSYSTEM",
      "events" : [ {
        "introduced" : "0"
      }, {
        "fixed" : "1.27.0"
      } ]
    } ]
  } ],
  "references" : [ {
    "type" : "WEB",
    "url" : "https://github.com/go-gitea/gitea/security/advisories/GHSA-vrhc-jjfc-m3m3"
  }, {
    "type" : "PACKAGE",
    "url" : "https://github.com/go-gitea/gitea"
  }, {
    "type" : "WEB",
    "url" : "https://github.com/go-gitea/gitea/releases/tag/v1.27.0"
  } ],
  "database_specific" : {
    "cwe_ids" : [ "CWE-863" ],
    "severity" : "HIGH",
    "github_reviewed" : true,
    "github_reviewed_at" : "2026-07-21T21:02:10Z",
    "nvd_published_at" : null
  }
}