Gitea versions prior to 1.27.0 contain a vulnerability where repository visibility and template status can be manipulated via undocumented git push options by users with owner or admin collaborator access. This allows changing a repository from private to public or altering its template status without triggering audit logs, webhook events, notifications, or timestamp updates. The flaw enables stealthy visibility changes and template poisoning attacks, leaving no trace in the repository's activity feed or notifications.
Gitea versions prior to 1.27.0 have a vulnerability in the OAuth2 sign-in callback that causes administrator-deactivated user accounts to be reactivated when signing in via OAuth2 sources that do not issue refresh tokens, such as GitHub or OIDC/OAuth2 sources without offline_access. This occurs because the system incorrectly uses an empty refresh token as a signal to reactivate accounts, which is the normal state for these sources. As a result, a deactivated user can regain full account access and session without special privileges. Accounts disabled with the stronger 'Prohibit Login' setting remain unaffected. This issue is fixed in Gitea 1.27.0.
Gitea versions prior to 1.27.0 contain a privilege escalation vulnerability in the LFS deploy-key handling. The flaw arises because deploy keys are incorrectly represented as the repository owner in JWT tokens, allowing an attacker with a write deploy key on one repository to impersonate the owner and access LFS objects across all private repositories owned by that user. This breaks the intended isolation of deploy keys and can expose sensitive LFS data without requiring admin credentials or brute force.
Gitea versions up to 1.26.x contain a local file inclusion vulnerability in the restore-repo command. This flaw allows an attacker with operator-level access to supply a crafted archive containing a release.yml file with file:// URIs. The server reads arbitrary files from its filesystem and stores their contents as release attachments, which can then be retrieved via the Gitea API. Sensitive files such as configuration files, private keys, and credentials can be exfiltrated. The vulnerability is fixed in version 1.27.0.
A null pointer dereference vulnerability exists in Gitea's AddTime API endpoint. When a repository administrator specifies a non-existent user name, the API returns an error but continues execution, leading to a runtime panic due to dereferencing a nil user pointer. This causes an authenticated denial of service by crashing the server process handling the request.
Gitea's OIDC userinfo endpoint accepts API tokens but does not enforce token scopes before returning identity claims. This allows tokens with limited scopes, such as 'read:misc', to retrieve user identity information including email and group memberships, even though these tokens are denied access to user-related REST API endpoints. The vulnerability affects versions prior to 1.27.0 and has been fixed in version 1.27.0. The impact is limited to disclosure of identity information associated with the authenticated user and does not grant access to repositories or administrative functions.
A vulnerability in Gitea versions prior to 1.27.0 allows users who have been removed as collaborators from a private repository to continue accessing repository metadata via the starred repository API endpoint. Although direct repository access is denied after revocation, metadata such as repository name, description, and visibility status remain accessible and reflect updates made after access removal. This issue does not expose repository contents or sensitive data.
Gitea's internal API HTTP client hardcodes TLSClientConfig.InsecureSkipVerify=true without any configuration override, allowing it to accept any TLS certificate. This affects deployments where internal API communication uses HTTPS to a non-loopback target, enabling an attacker with network access to intercept the INTERNAL_TOKEN used for authentication of sensitive internal API endpoints. The vulnerability is rated high severity for split-host HTTPS deployments and low/informational for default single-host setups. A fix is available in Gitea version 1.27.0.
A vulnerability in Gitea versions prior to 1.27.0 allows unauthorized users with API access tokens to confirm membership of users in private organizations via a REST API endpoint. This membership information is otherwise hidden in the web interface for private organizations. The flaw is fixed in version 1.27.0.
Gitea versions prior to 1.27.0 have a vulnerability in their RSS/Atom feed handlers where API tokens with restricted scopes or marked as public-only can still access private repository content via feed routes. This bypasses the intended token scope and public-only confinement enforced on other download handlers. The issue allows tokens that should be blocked from private repo data to retrieve commit details, release notes, and private activity streams through various feed endpoints.
A vulnerability in Gitea's DeleteIssueLabel API endpoint allows authenticated users to enumerate label IDs across repositories they do not have access to. The API performs a global, unscoped lookup of label IDs and returns different HTTP status codes depending on whether the label ID exists anywhere on the instance. This information leak does not expose label names, colors, or allow cross-repository writes. The issue affects Gitea versions prior to 1.27.0 and has a low severity rating.
Gitea versions prior to 1.27.0 have a vulnerability where personal access tokens (PATs) or OAuth2 tokens without the required 'repository' scope can bypass scope enforcement on the repository home page route (GET /{owner}/{repo}). This allows unauthorized tokens to access private repository content such as the rendered README, file tree, description, language stats, license, and latest release information. Other repository content routes correctly enforce token scope restrictions, but the repository home page route lacks this check, leading to private data disclosure.
Gitea versions prior to 1.27.0 have a vulnerability where a public-only repository token with write permissions can update private pull request head branches via a public base repository route. This occurs because the public-only restriction is checked only against the public base repository, not the private head repository, allowing unauthorized updates to private branches. The issue is tracked as CVE-2026-58443 and has a high CVSS score of 9.6.
Gitea versions prior to 1.27.0 contain a server-side request forgery (SSRF) vulnerability in the repository migration feature. The vulnerability arises because the URL validation logic incorrectly accepts hostnames that resolve to multiple IP addresses if any one of those IPs is allowed, even if others are internal or blocked. This allows an authenticated low-privilege user to bypass restrictions and cause Gitea to connect to internal-only Git services, importing their contents into an attacker-controlled repository.
Gitea's restore-repo CLI command has a Server-Side Request Forgery (SSRF) vulnerability due to improper validation of the Head.CloneURL field in pull_request.yml during repository restoration. This allows an attacker to cause the Gitea server to fetch from an attacker-controlled URL or disclose local git repositories via file:// URLs. The issue arises because the safety check that should validate URLs is disabled by passing an empty base URL, making the check ineffective. This vulnerability affects versions prior to 1.27.0 and is fixed in version 1.27.0.
Gitea versions prior to 1.27.0 contain a cross-repository Insecure Direct Object Reference (IDOR) vulnerability in the issue dependency removal functionality. The RemoveDependency function lacks proper permission checks when deleting dependencies linked to issues in private repositories, allowing an attacker with write access to issues in one repository to remove dependencies and post comments on issues in private repositories they cannot access. This vulnerability does not disclose repository content but allows unauthorized modification of issue dependencies and injection of attacker-authored comments across repository boundaries. A fix is available in version 1.27.0.
Gitea Actions Artifacts V4 signed URLs suffer from an HMAC signature ambiguity that allows an attacker with permission to run a Gitea Actions job to rewrite signed URLs. This enables unauthorized reading of artifacts from other repository tasks and unauthorized writing to other task artifact upload staging areas, including private repositories. The vulnerability arises because the HMAC input concatenates multiple fields without delimiters, allowing different URL parameter combinations to produce the same signature. This flaw affects versions from 1.22.0 up to but not including 1.26.2.
Gitea Actions contains a vulnerability in the fork pull request workflow approval gate that allows an attacker with a single unprivileged account and one-time maintainer approval on a benign fork PR to permanently bypass approval for all future fork PR workflow runs from that user on the same repository. This bypass occurs because the approval check only verifies if the user has any previously approved run in the repository, without considering the pull request, commit, or workflow contents. The vulnerability affects all Gitea versions from v1.20.0 onward and remains unpatched as of this disclosure.
A vulnerability in Gitea's SSH LFS sub-verb handling allows any authenticated SSH user to bypass access controls and obtain valid LFS credentials for private repositories they do not have permission to access. This flaw enables unauthorized read access to all LFS objects in any private repository on the instance. The issue arises because unknown LFS sub-verbs cause the permission check to incorrectly grant access. This affects Gitea versions from 1.23.0 up to but not including 1.26.3. No official patch or fix has been confirmed yet.
Gitea versions prior to 1.26.4 contain a vulnerability in the CODEOWNERS feature where user-supplied regex patterns are compiled without sanitization or timeout, enabling a Regular Expression Denial of Service (ReDoS) attack. An attacker with a repository can craft malicious CODEOWNERS patterns and file names in pull requests that cause exponential regex backtracking, hanging the server during pull request processing. This results in database connections being held open, potentially exhausting the connection pool and making the Gitea instance unresponsive.