Gitea vulnerabilities

Two SSRF vulnerabilities in Gitea migration/mirror (DNS rebinding + missing re-validation).

Public-only repository tokens can update private PR head branches.

The team-repository linking endpoint bypasses the RepoAdminChangeTeamAccess organization setting. This means a user without proper permissions can change repository-team assignments.

Theft of the Remember-Me token in Gitea does not invalidate the attacker's session, allowing continued unauthorized access.

The vulnerability allows privilege escalation via access token scope escalation in the API.

A public-only scope token can bypass restrictions on limited-visibility owners (Repository and Package categories) — residual after CVE-2026-25714 / PR #37118.

The OIDC userinfo endpoint returns identity claims without enforcing API token scopes.

The vulnerability in Gitea Actions Artifacts V4 stems from HMAC ambiguity in signed URLs, allowing cross-repository artifact read and cross-task upload-state write.

A vulnerability in Gitea before version 1.26.0 fails to close the connection on bufio.Scanner errors while processing pre-receive hook input, allowing oversized input to bypass branch-protection checks.

A vulnerability in Gitea up to version 1.26.1 is caused by insufficient permission checks for Composer package source links. This can expose private or internal package source information.

The vulnerability in Gitea before version 1.25.5 is that LFS push and sync mirror operations do not use the migration HTTP transport, bypassing the configured migration transport protections for those LFS requests.

A vulnerability in Gitea before version 1.25.5 does not correctly persist the OAuth2 PKCE S256 challenge method during authorization, allowing token exchange without the required verifier check.

A vulnerability in Gitea versions before 1.25.5 allows reusing expired or single-use OAuth2 authorization codes during token exchange. Inconsistent enforcement of code expiry and single-use behavior may lead to unauthorized access.

A vulnerability in Gitea before version 1.25.5 mishandles path resolution during template repository generation, allowing template processing to read or write through symlinked or otherwise non-regular paths.

CVE-2026-22874 affects Gitea versions up to and including 1.26.2. The SSRF (Server-Side Request Forgery) protection in webhook and migration allow-list filtering is incomplete, potentially allowing an attacker to make unauthorized requests to internal network resources.

In Gitea before version 1.25.5, validation constraints for repository creation fields are missing, including length-limited template fields and trust model or object format values.

Gitea Docker images up to version 1.26.2 set REVERSE_PROXY_TRUSTED_PROXIES=* by default, allowing any source IP to impersonate a user when reverse-proxy authentication headers like X-WEBAUTH-USER are enabled.

A vulnerability in Gitea up to version 1.26.1 allows repository archive downloads to bypass token scope checks on the web archive download endpoint.

A vulnerability in Gitea allows improper validation of repository ownership when linking attachments to releases. An attachment uploaded to a private repository could be linked to a release in a different public repository, making it accessible to unauthorized users.

Gitea does not properly validate repository ownership when deleting Git LFS locks. A user with write access to one repository may be able to delete LFS locks belonging to other repositories.

Gitea does not properly validate project ownership in organization project operations. A user with project write access in one organization may be able to modify projects belonging to a different organization.

Unbounded Arch package file metadata can cause resource amplification in Gitea package uploads.

Webhook Authorization Header Returned in Plaintext via API.

GHSA-8fwc-qjw5-rvgp ClearRepoWatches fix not applied to API EditRepo path — sister code path retains stale watches on public->private.

Private Repository Existence Disclosure via go-get Meta Endpoint.

Cross-repository label-ID enumeration oracle via unscoped DeleteIssueLabel API.

Personal access token scope enforcement bypass on the repository home page (`GET /{owner}/{repo}`) discloses private repository contents.

Repository migration SSRF via multi-answer DNS allow-list bypass.

SSRF in restore-repo via unsanitized pull_request.yml Head.CloneURL.

Webhooks created by a collaborator keep firing after their repo access is revoked, enabling ongoing real-time exfiltration of private repo content. The issue stems from incomplete revocation cleanup in `DeleteCollaboration`.

Branch protection can be bypassed via PR retargeting, preserving a stale `official` approval flag. This allows changes to be pushed to protected branches without the required approval.

A cross-repository IDOR in issue-dependency removal lets an attacker tamper with and comment on private repos they cannot access. There is a lack of proper object-level authorization.

The vulnerability allows manipulation of repository visibility via Git push options. An attacker can change repository visibility (e.g., from private to public) without proper permissions.

ParseAcceptLanguage in the Locale middleware causes a quadratic-time DoS on unauthenticated requests. Sending specially crafted Accept-Language headers can overload the server.

A vulnerability in Gitea LFS allows privilege escalation via deploy keys. A person with a deploy key can gain higher privileges than intended.

Private repository metadata remains accessible after access revocation. This means that information about the repository (e.g., name, description) may still be visible to users who lost permissions.

In code.gitea.io/gitea, there is missing authorization and authorization bypass through user-controlled key, incorrect permission assignment for critical resources, and exposure of sensitive information to an unauthorized actor.

The public-only API token restriction is not enforced on team API routes. This means a token intended for public access only can access team data that should be private.

The vulnerability allows bypassing the public-only scope of personal access tokens in organization and permission endpoints. This means a token intended only for public operations can access operations requiring broader privileges.

The vulnerability allows bypassing the release attachment extension allowlist via the web release edit form. This is a variant of CVE-2025-68939.

The vulnerability leaks the member list of private organizations via the /members API endpoint. This is an incomplete fix for PR #38145.

The vulnerability in OAuth token introspection returns metadata of tokens issued to other clients, violating section 4 of RFC 7662.

The vulnerability allows Local File Inclusion via file:// URI in the Migration Restore function. An attacker can read arbitrary files from the server's filesystem.

The vulnerability in the REST API exposes organization membership of private organizations to the public. Unauthorized individuals can obtain information about members of private organizations.

The vulnerability in Fork-PR Actions tasks allows reading a third private repository via the collaborative-owner branch. A missing fork-PR guard enables this.

Two Server-Side Request Forgery (SSRF) findings in Gitea 1.26.2. They allow an attacker to make requests from the server to internal resources.

The vulnerability enables cross-repository information disclosure via Org-Level Actions Run/Job APIs. An attacker can obtain data from other repositories.

The vulnerability in repository migration follows Git HTTP redirects after URL allow/block validation, enabling internal Git repository exfiltration.

The vulnerability allows re-linking attachments to issues/comments across repositories, potentially exposing private attachment content.