CVE-2026-95106
CriticalCVSS 9.1Exploitation Probability (EPSS)
Low risk4th percentile - higher than 4% of all known CVEs
Summary
Gitea accepted pushed Git trees containing two entries with the same name, which Git's own consistency checks reject. Gitea's web views resolved such a path to the first entry, while `git checkout`, Gitea Actions, and release archives use the last. A contributor could open a pull request whose diff and file views show benign content while CI and checkouts at the same commit use different, attacker-controlled content. Incoming objects are now checked for consistency; objects already stored in existing repositories are not rescanned.
Risk Assessment
An attacker can introduce malicious content into a repository that gets executed in CI or during checkout, while code review shows a benign version, potentially leading to security breaches.
Recommendation
Update Gitea to a patched version and consider rescanning existing repositories for inconsistent trees.
Other vulnerabilities in Gitea
See all- CVE-2026-101023Critical
Gitea's OAuth2 token endpoint verified the signature and grant of a token submitted with the refresh_token grant type, but not that the token was a refresh token. An unexpired access token for the same OAuth2 application and grant could be exchanged for a new access token and refresh token. Whoever holds such an access token could keep access beyond the token's original lifetime.
- CVE-2026-94205Critical
Gitea Actions decided whether a fork pull request run needed approval based on the user who triggered the event rather than the pull request author. For `pull_request` activity triggered by a maintainer during ordinary triage, such as adding a label, the run was created without requiring approval, while the workflow definition was still taken from the fork head. Where Actions is enabled and a matching runner is registered, fork-controlled workflow code could run on the base repository's runners without an explicit approval.
- CVE-2026-73278Critical
Gitea's OAuth2 and OpenID Connect sign-in paths do not require a WebAuthn challenge when WebAuthn is the account's only configured second factor. A party able to authenticate through the affected external identity flow can obtain a full session without the passkey verification enforced during password login. One affected path can also persist an external identity link, extending the compromise beyond the initial session; accounts with TOTP configured are outside the reported WebAuthn-only scenario.
- CVE-2026-103059Critical
When Gitea's built-in SSH server is enabled (`START_SSH_SERVER = true`), the presented public key was looked up with an SQL `LIKE` comparison of its encoded content, which is case-insensitive on some databases, including the default SQLite. An attacker who can construct a case variant of another user's registered RSA public key for which they can derive the private key could have that key matched to the victim's account and authenticate over SSH as that user. Keys are now looked up by fingerprint.
- CVE-2026-60004CriticalActively exploited
Gitea before version 1.27.1 allows remote code execution via the diffpatch API through Git hook installation.
- CVE-2026-58508Critical
Two SSRF vulnerabilities in Gitea migration/mirror (DNS rebinding + missing re-validation).
- CVE-2026-58443Critical
Public-only repository tokens can update private PR head branches.
- CVE-2026-58433Critical
The team-repository linking endpoint bypasses the RepoAdminChangeTeamAccess organization setting. This means a user without proper permissions can change repository-team assignments.
- CVE-2026-56750Critical
Theft of the Remember-Me token in Gitea does not invalidate the attacker's session, allowing continued unauthorized access.
- CVE-2026-56654Critical
The vulnerability allows privilege escalation via access token scope escalation in the API.
Original NVD description (English source)
Gitea accepted pushed Git trees containing two entries with the same name, which Git's own consistency checks reject. Gitea's web views resolved such a path to the first entry, while `git checkout`, Gitea Actions, and release archives use the last. A contributor could open a pull request whose diff and file views show benign content while CI and checkouts at the same commit use different, attacker-controlled content. Incoming objects are now checked for consistency; objects already stored in existing repositories are not rescanned.
Vulnerability data from NVD (NIST) · CISA KEV · EPSS