External risk intelligence

Gitea Public Token Vulnerability Allows Unauthorized Access to Private Repository Secrets

CVE advisorySeverity: CRITICAL (CVSS 9.1)

CVE-2026-116289

Gitea is commonly deployed as a self-hosted, internet-facing platform for version control and CI/CD services. The vulnerable endpoint involves organization-level runners and token handling, which are standard features in web-based developer environments frequently exposed to the internet to facilitate remote collaboration and automation.

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 vulnerability in Gitea, a code hosting platform, could allow an attacker to gain unauthorized access to private repositories and their sensitive data. While the attacker would need a specific type of token, the potential impact involves access to workflow content, secrets, and variables. The primary concern is to confirm if Gitea is in use and if the specific access controls were improperly configured.

Improper token use grants broad repository access.
Affects private repository access and secrets.
Confirm Gitea use and token configurations.

Attack Path

How an attacker could exploit the issue

An attacker could leverage a specially crafted personal access token intended for public resources to register an organization-level runner. This misconfiguration allows the registered runner to execute jobs for private repositories within the organization that have Actions enabled, potentially exposing sensitive workflow content, secrets, and variables. The attacker could then gain access to private repository data and perform unauthorized actions.

Requires a specific type of token.
Exploits runner registration on an endpoint.
Leads to unauthorized access to private data.

Live Threat

Current exploitation, exposure, and threat context

This vulnerability could allow an attacker to register an organization-level runner that gains unauthorized access to private repository content and secrets within Gitea. This occurs when a personal access token restricted to public resources is misused with the organization Actions runner registration endpoint.

Private repository code and secrets.
Misused restricted access tokens.
Unauthorized access to sensitive data.

Operational Fix

Recommended remediation, mitigation, and detection steps

The real-world impact of this vulnerability likely falls under the purview of platform or application owners responsible for the Gitea instance, with potential involvement from security and network teams. The immediate first step is to identify all Gitea deployments, assess their exposure, and confirm the ownership of each instance to prioritize remediation efforts.

Platform or application owners should own.
Verify instance exposure and reachability first.
Plan remediation based on identified risk.

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 and what is it used for?

Gitea is an open-source, self-hosted platform designed for version control and software development. It functions as a central hub for hosting code repositories and includes built-in CI/CD services known as Gitea Actions. These features allow development teams to automate workflows, manage projects, and collaborate on software builds directly within their own infrastructure.

What does CWE-863 mean for CVE-2026-116289?

CWE-863 refers to Incorrect Authorization. In the context of this CVE, it means the software fails to verify if a user has the appropriate permissions to perform a specific action. Specifically, the system incorrectly allows a token intended only for public data to authorize the registration of an organization-level runner, granting access to private resources that should have remained restricted.

How is this Gitea vulnerability triggered?

An attacker triggers this by using a personal access token that is restricted to public resources, yet applying it against the organization Actions runner registration endpoint. Simply having a token is not enough; the attacker must specifically target this endpoint. The vulnerability does not trigger if the token is used for standard repository operations or if the organization does not use Actions.

Is my Gitea instance at risk according to Halo Surface Signal?

Halo Surface Signal identifies Gitea as a 'Likely' target because it is frequently deployed as an internet-facing platform to support remote CI/CD automation. If your instance is reachable from the internet, it is more accessible to external actors. You should prioritize assessment if your Gitea environment manages organization-level runners and exposes these management endpoints to your network.

When should I take action to secure my Gitea instance?

You should begin by identifying all Gitea deployments within your environment and confirming their exposure levels. Once you have an inventory of these instances, evaluate their configuration regarding organization-level runner registration. Since this involves potential access to sensitive repository secrets and variables, consult your platform administrators to verify current token policies and update to the patched version.

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.