External risk intelligence

Gitea OAuth2 PKCE Challenge Method Persistence Flaw

CVE advisorySeverity: CRITICAL (CVSS 9.1)

CVE-2026-26247

Gitea is commonly deployed as a self-hosted web-based Git service. Because it functions as an internet-facing application and API for code hosting and collaboration, it is frequently exposed to the public internet to facilitate remote access for development teams.

Halo Surface Signal: 4 out of 5 — likely to be public-facing.

External exposure likelihood

Horizon Alert

Summary of the vulnerability and why it matters

A vulnerability in Gitea, a self-hosted Git service, allows attackers to potentially gain unauthorized access to sensitive information by bypassing security checks during token exchange. This issue affects how the system handles the OAuth2 PKCE S256 challenge method, which is crucial for secure authorization. The main concern is confirming if our environment uses Gitea and is exposed to potential exploitation.

Security flaw in Git service authorization.
Critical issue with potential data compromise.
Confirm Gitea usage and exposure.

Attack Path

How an attacker could exploit the issue

An attacker could potentially gain unauthorized access to user tokens by exploiting how Gitea handles OAuth2 authorization. This vulnerability arises when the application fails to properly store a security verifier during the authorization process, allowing an attacker to exchange a code for an access token without successfully completing the intended security check. If exploited, this could lead to a compromise of user data and unauthorized actions on behalf of the affected user.

No authentication is required for entry.
An attacker triggers the vulnerability during authorization.
Leads to unauthorized token access.

Live Threat

Current exploitation, exposure, and threat context

When supported by the advisory, this vulnerability could allow an attacker to exchange an authorization code for an access token without proper verification. This may affect the integrity and confidentiality of the service by enabling unauthorized token issuance.

Unauthorized token issuance.
Bypass of authorization code verification.
Compromised service integrity.

Operational Fix

Recommended remediation, mitigation, and detection steps

This vulnerability affects self-hosted Gitea instances, likely managed by infrastructure or platform teams responsible for the Git service. The first practical step is to identify all Gitea deployments, confirm their internet accessibility and business criticality, and then coordinate remediation with the accountable owner.

Platform or Infrastructure team ownership.
Verify internet-exposed Gitea instances.
Plan and schedule an upgrade.

Supplementary metadata

CVSS vector

Validate whether this threat affects your internet-facing exposure.

Halo Threat Intelligence helps prioritize remediation with Halo Surface Signal and H/A/L/O context. Start exposure validation with a free external attack surface trial.

Free EASM Trial See How Signal Works

Frequently asked questions

What is Gitea?

Gitea is a lightweight, self-hosted Git service that provides a web-based interface for version control, repository management, and team collaboration. Development teams use it to host code, manage project tasks, and automate workflows internally or publicly. Because it centralizes source code, it acts as a critical hub for developer activity and project documentation.

What does CVE-2026-26247 mean for authorization?

This vulnerability, classified as CWE-284 (Improper Access Control), involves a failure in the OAuth2 PKCE S256 challenge process. Normally, PKCE ensures that only the party initiating an authorization request can exchange a code for an access token. In affected Gitea versions, the system fails to persist the verification challenge correctly, allowing an attacker to bypass this security check and obtain tokens they should not have.

How does an attacker trigger this vulnerability?

An attacker triggers this flaw during the OAuth2 flow by interacting with the authorization process. Because the application fails to verify the PKCE challenge, the attacker can exchange an authorization code for an access token without needing the original verifier. This bypass does not occur if the authorization flow is configured to use different methods or if the specific PKCE S256 requirement is not involved in the user's login attempt.

Why is this CVE concerning for my Gitea instance?

Halo Surface Signal notes that Gitea is frequently deployed as an internet-facing application to support remote teams. If your instance is reachable from the public internet, it faces a higher likelihood of unauthorized access attempts compared to internal-only services. Because this issue affects the authorization mechanism itself, it can lead to compromised user accounts or data exposure regardless of other local security settings.

What should I do first to address this?

The most effective first step is to inventory all instances of Gitea across your infrastructure to determine which versions are running. Once you have a list of your deployments, prioritize those that are accessible from the internet for immediate attention. Work with your platform or infrastructure team to coordinate an upgrade to version 1.25.5 or later, which contains the fix for this authorization persistence issue.

References

Written by Nicholas Merritt

Nicholas Merritt is VP of Security Solutions at Halo Security. With more than 25 years across application security, vulnerability prioritization, and offensive security, he helps teams translate threat data into practical exposure validation and remediation focus. He authors Halo Threat Intelligence CVE advisories using Halo Surface Signal and H/A/L/O context to prioritize internet-facing risk.