CVE-2026-101023

Executive Summary

CVE-2026-101023 is an improper authentication vulnerability in the Gitea OAuth2 token endpoint. An unexpired access token for a given OAuth2 application and grant can be submitted using the refresh_token grant type and exchanged for a new access token and refresh token. This allows an attacker holding a valid access token to extend access beyond the token's original lifetime.

Technical Analysis

The vulnerability resides in the OAuth2 token endpoint's handling of the refresh_token grant type. According to the NVD description, the endpoint correctly verified the signature and the grant associated with a submitted token, but failed to verify that the token was actually a refresh token. Consequently, a bearer of an unexpired access token — issued for the same OAuth2 application and grant — could present that access token under the refresh_token grant type and receive a new access token and refresh token in return.

This is a token-type confusion flaw: the server validates token authenticity and grant scope but not token class (access vs. refresh). The attack surface is the OAuth2 token exchange endpoint, reachable by any client that has previously obtained a valid access token for the application. The impact is a violation of the intended token lifecycle boundary. Normally, refresh tokens are long-lived and used to obtain new access tokens, while access tokens are short-lived. By treating an access token as a refresh token, the attacker can perpetually rotate credentials so long as the original access token remains unexpired, effectively bypassing the intended expiry of the access token. No code-level function names, parameter names, or file paths are specified in the available description; the description explicitly names the refresh_token grant type and the concepts of access token and refresh token.

Exploitation Scenarios

The following chain is inferred strictly from the NVD description. No public PoC is available.

1. Reconnaissance / target identification. The attacker identifies a Gitea instance hosting an OAuth2 application for which they already possess a valid, unexpired access token. This token may have been obtained legitimately (e.g., a user who later becomes malicious) or via a prior compromise of a client that stores tokens.

2. Triggering the flaw class. The attacker submits the access token to the OAuth2 token endpoint using the refresh_token grant type, the same application identifier, and the same grant. Because the endpoint verifies signature and grant but not token type, the access token is accepted as if it were a refresh token.

3. Payload / execution. The request is a standard OAuth2 token request with grant_type=refresh_token and the access token supplied in the refresh token field. On success, the server returns a new access token and a new refresh token. No injection, memory corruption, or code execution is involved; the exploit is purely a logic/authorization bypass.

4. Post-exploitation impact. The attacker can repeat the exchange to continuously mint fresh tokens, maintaining access to the OAuth2-protected resources beyond the access token's original lifetime. The blast radius is limited to the specific OAuth2 application and grant for which the access token was issued, but within that scope the attacker can persist indefinitely until the grant is revoked or the application is deleted.

Impact Assessment

The vulnerability weakens the OAuth2 token lifecycle guarantee that access tokens are short-lived. While no CVSS vector is provided (CVSS: N/A), the logical impact is an authentication bypass enabling session persistence. Integrity and confidentiality of resources accessible under the affected OAuth2 grant are at risk, and availability is unaffected. The attack requires possession of a valid access token, meaning it does not grant initial access but facilitates persistence and privilege retention. In multi-tenant or integration-heavy Gitea deployments, a compromised integration token could remain usable far beyond its expected lifetime, complicating incident response and token revocation efforts.

Detection Guidance

Sigma Rule

title: Gitea OAuth2 Access Token Used as Refresh Token
id: 8f2c1e4a-3b7d-4c9e-a1f2-6d5e8c0b9a71
status: experimental
description: Detects OAuth2 token exchanges where an access token is submitted with grant_type=refresh_token against a Gitea instance.
logsource:
  category: web
  product: gitea
detection:
  selection:
    cs-method: POST
    cs-uri-path|endswith: '/login/oauth/access_token'
    cs-uri-query|contains: 'grant_type=refresh_token'
  condition: selection
falsepositives:
  - Legitimate refresh token usage
level: medium

YARA Rule

rule CVE_2026_101023_Gitea_OAuth2_Token_Confusion
{
    meta:
        description = "Detects HTTP requests abusing Gitea OAuth2 refresh_token grant with an access token"
        author = "Threat Intelligence"
        date = "2026-01-01"
        reference = "CVE-2026-101023"
    strings:
        $grant = "grant_type=refresh_token"
        $endpoint = "/login/oauth/access_token"
    condition:
        any of them
}

Suricata IDS Rule

alert http any any -> any any (msg:"CVE-2026-101023 Gitea OAuth2 refresh_token grant abuse"; flow:to_server,established; http.method; content:"POST"; http.uri; content:"/login/oauth/access_token"; http.client_body; content:"grant_type=refresh_token"; classtype:attempted-user; sid:2026101023; rev:1;)

Elastic Detection

sequence by source.ip with maxspan=5m
  [http where http.request.method == "POST" and url.path endsWith "/login/oauth/access_token" and http.request.body contains "grant_type=refresh_token"]

Splunk SPL Query

index=web sourcetype=gitea OR sourcetype=access_combined
| search uri_path="/login/oauth/access_token" method=POST
| rex field=body "grant_type=(?<grant_type>\w+)"
| where grant_type="refresh_token"
| stats count by src_ip, grant_type
| where count > 5

Wazuh OSSEC Rule

<group name="gitea,oauth2,">
  <rule id="100023" level="10">
    <decoded_as>json</decoded_as>
    <field name="uri_path">/login/oauth/access_token</field>
    <field name="method">POST</field>
    <field name="body">grant_type=refresh_token</field>
    <description>CVE-2026-101023: Possible Gitea OAuth2 refresh_token grant abuse</description>
    <mitre>
      <id>T1078</id>
    </mitre>
  </rule>
</group>

Mitigation & Patch Guidance

Patch confidence: 0/4 (UNPATCHED — no patch evidence from any tracked source).

1. Immediate mitigations:

   • Revoke all OAuth2 access and refresh tokens associated with affected applications.
   • Reduce access token lifetimes in Gitea's OAuth2 configuration to limit the window of abuse.
   • Disable or restrict OAuth2 applications where the token endpoint is not strictly required.
   • Monitor token endpoint logs for grant_type=refresh_token requests where the submitted token is an access token (e.g., by type claim, if present).

2. Patch/upgrade steps: No vendor patch is currently available. Track Gitea security advisories and upgrade as soon as a fixed release is published. Until then, treat the instance as vulnerable.

3. Long-term hardening:

   • Enforce strict token-type validation in OAuth2 implementations (verify a token_type or equivalent claim before accepting a refresh request).
   • Rotate and scope OAuth2 grants minimally; avoid long-lived access tokens.
   • Implement continuous token auditing and anomaly detection for abnormal refresh patterns.

References

• NVD: https://nvd.nist.gov/vuln/detail/CVE-2026-101023
• Gitea Security Advisories: https://github.com/go-gitea/gitea/security/advisories
• OAuth 2.0 RFC 6749 (refresh token grant): https://datatracker.ietf.org/doc/html/rfc6749
• CWE-287 Improper Authentication: https://cwe.mitre.org/data/definitions/287.html
• MITRE ATT&CK T1078 Valid Accounts: https://attack.mitre.org/techniques/T1078/