External risk intelligence

Gitea Authentication Bypass Allows Session Hijacking Via OAuth2 and OpenID Connect.

CVE advisorySeverity: CRITICAL (CVSS 9.8)

CVE-2026-73278

Gitea is commonly deployed as a self-hosted, internet-facing web application for code hosting and collaboration. The vulnerability exists within the authentication and sign-in paths of this web service, which are typically exposed to the public internet to facilitate remote access for developers and automated systems.

Authentication Bypass

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

This advisory addresses a vulnerability in Gitea, a self-hosted code collaboration platform, related to its sign-in process. Specifically, the way it handles external identity logins can allow an attacker to bypass security checks, potentially gaining unauthorized access to user accounts and sessions without proper multi-factor authentication. The main concern is confirming relevance and exposure.

  • Login bypass allows account access without full checks.
  • Bypassed authentication can lead to session compromise.
  • Verify if Gitea's login process is exposed externally.

Attack Path

How an attacker could exploit the issue

An attacker could target users who rely solely on passkeys for two-factor authentication to bypass security checks. By exploiting the sign-in process, an attacker could gain full session access without requiring the user's passkey, potentially leading to a complete account compromise. This issue could also allow an attacker to maintain a persistent link to an external identity, prolonging the compromise beyond the initial session.

  • No user interaction needed.
  • Bypasses passkey verification during login.
  • Allows unauthorized session access.

Live Threat

Current exploitation, exposure, and threat context

When an external identity provider is used for sign-in, an attacker could potentially bypass multi-factor authentication, including passkey verification, to gain unauthorized access to a user's account. In some cases, this compromise could persist even after the initial session ends by linking the external identity.

  • User accounts and associated data.
  • Bypass of second-factor authentication.
  • Unauthorized account access and control.

Operational Fix

Recommended remediation, mitigation, and detection steps

This vulnerability in Gitea's authentication flow could allow unauthorized access to accounts, potentially leading to session hijacking and persistence of external identity links. The primary responsibility for addressing this likely falls to the teams managing Gitea instances, which could include application owners, platform engineers, or infrastructure teams, depending on the deployment model. The first crucial step is to identify all deployed Gitea instances, assess their exposure and criticality, and then coordinate remediation efforts with the relevant accountable owners.

  • Identify Gitea instances and owners.
  • Verify affected sign-in paths.
  • Plan remediation based on exposure.

Supplementary metadata

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.

Frequently asked questions

What is Gitea and what is it used for?

Gitea is a lightweight, open-source platform used for self-hosting Git repositories and managing software development projects. Teams use it to host code, track issues, and manage team collaboration on their own infrastructure rather than relying on third-party cloud services.

What does CVE-2026-73278 mean for security?

This vulnerability is classified as CWE-287, which refers to improper authentication. In Gitea, it means the application fails to verify a WebAuthn passkey during certain login flows. Consequently, an attacker can bypass the expected second-factor requirement, allowing them to gain unauthorized access to an account if they can reach the sign-in page.

How does an attacker trigger this vulnerability?

An attacker triggers this by using OAuth2 or OpenID Connect to sign in to an account where WebAuthn is the only configured second factor. The vulnerability does not occur if the account uses TOTP (Time-based One-Time Password) as a second factor, as those configurations remain protected.

Is my Gitea instance at risk?

Halo Surface Signal indicates that Gitea is often deployed as an internet-facing service, which increases the likelihood of exposure for this authentication bypass. If your instance is accessible from the public internet and you allow external identity sign-ins, you should evaluate your current authentication configurations.

What should I do to secure my Gitea instance?

Start by identifying all your Gitea deployments and their associated owners. Prioritize reviewing accounts that rely solely on WebAuthn for second-factor authentication. Consult the official Gitea release documentation to identify the patched versions and coordinate a deployment update for your managed instances.

References