Gitea Open Source Git Server

Privilege escalation in Gitea Open Source Git Server before 1.25.5 allows an attacker holding a leaked read-only API token to mint a runner registration token and register a malicious Actions runner against the instance. The root cause is that the runner registration-token endpoints - at the user, organization, repository, and admin levels - are classified as read-only by the API scope middleware solely because they use the HTTP GET method, despite creating a token if none exists. With a valid registration token, the attacker can register a self-hosted runner that executes CI/CD workflow jobs, gaining access to repository secrets and source code. No public exploit code has been identified at time of analysis, and the EPSS score of 0.16% (6th percentile) indicates low observed exploitation probability.

Server-side request forgery in Gitea Open Source Git Server (all versions through 1.26.4) lets attackers abuse the repository migration and mirror features to reach internal network resources. Two distinct weaknesses are involved: a DNS-rebinding bypass where a hostname resolves to a permitted address during validation and to an internal address when the actual request is made, and a missing re-validation flaw where redirect or subsequent fetch targets are not re-checked against the allow/deny policy. No public exploit was identified at time of analysis, EPSS is low (0.15%), and it is not in CISA KEV, but the vendor rates technical impact as total and the issue is fixed in 1.27.0.

Broken access control in Gitea (self-hosted Git service) versions up to and including 1.26.4 lets the team-repository linking endpoint ignore the RepoAdminChangeTeamAccess organization setting, so repository administrators can grant or alter team access to repositories even when an org owner has explicitly restricted that ability. This CWE-862 missing-authorization flaw undermines an intended org-level guardrail, exposing private repository contents (C:H) and permitting unauthorized permission changes (I:H). No public exploit has been identified at time of analysis, and the EPSS probability is low (0.15%, 5th percentile).

Gitea's Email Management API allows authenticated users to bypass access controls enforced by the ManageCredentials feature, enabling unauthorized credential-related actions on affected instances. All Gitea Open Source Git Server versions up to and including 1.26.4 are affected. An authenticated low-privileged user can exploit this to read or modify credential-related data beyond their intended permissions, with a fix delivered in v1.27.0.

Cross-repository information disclosure and cross-task tampering in Gitea's self-hosted Git server (fixed in v1.26.2) arises from an HMAC signature ambiguity in the Actions Artifacts V4 signed-URL scheme, letting an authenticated low-privilege user reuse a validly signed URL outside its intended repository or task context. An attacker with access to a single Actions task can read private artifacts belonging to other repositories and write upload-state for tasks they do not own, crossing the repository trust boundary (CVSS 9.6, scope-changed). There is no public exploit identified at time of analysis, and it is not listed in CISA KEV.

Authorization bypass in Gitea's Gitea Actions fork pull-request approval gate lets a low-privileged contributor permanently defeat the maintainer approval step that normally guards workflow execution on fork PRs, so that after the initial gate is subverted the attacker's workflow code runs against the repository's CI runners and secrets. CVSS is 8.9 (high) with a scope change and high integrity/availability impact; no public exploit has been identified at time of analysis, but a vendor patch (v1.26.4) is available. The flaw is classed as CWE-285 (Improper Authorization) and was self-reported by the Gitea project.

Authentication bypass in Gitea's Git LFS (Large File Storage) SSH handling allows a low-privileged authenticated user to read files from private repositories they should not access by supplying a malformed SSH sub-verb, per the Gitea security advisory GHSA-7wvc-rvp7-w99x. Because the flaw crosses a security boundary (CVSS scope change) it exposes confidential repository contents without any integrity or availability impact. No public exploit has been identified at time of analysis, and it is not listed in CISA KEV, but a vendor patch is available in Gitea 1.26.4.

Authorization bypass in Gitea Open Source Git Server (versions up to and including 1.26.1) allows a user whose account was deliberately disabled by an administrator to silently regain access simply by signing in through a linked OAuth provider. The OAuth sign-in callback fails to honor the administrator's 'disabled' flag, effectively reversing an intended access-revocation action. EPSS is low (0.16%, 6th percentile) and there is no public exploit identified at time of analysis, but the flaw undermines a core account-lifecycle control on a widely self-hosted platform.

Denial of service in Gitea, the self-hosted open-source Git service, allows a remote unauthenticated attacker to exhaust server CPU by triggering catastrophic backtracking in the regular-expression engine that evaluates CODEOWNERS pattern matching. All versions prior to the fixed 1.26.3/1.26.4 releases are affected, and the CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N, A:H only) confirms network-reachable, low-complexity, no-authentication abuse with availability-only impact. There is no public exploit identified at time of analysis and EPSS is low (0.16%, 6th percentile), so exploitation risk is real but not yet widespread.

Information disclosure in Gitea Open Source Git Server (through 1.26.2) allows a user whose repository access has been revoked to continue viewing private issue metadata via the Notification API, because notification records are not purged or re-authorized when permissions change. The CVSS 3.1 base score is 7.5 (C:H) and the vendor (Gitea) fixed it in 1.26.3/1.26.4. No public exploit identified at time of analysis, and EPSS is low (0.17%, 7th percentile), indicating limited near-term exploitation likelihood.

Server-Side Request Forgery (SSRF) via HTTP redirect in Gitea's repository migration feature affects all versions through 1.25.4, allowing an authenticated attacker to coerce the Gitea server into issuing HTTP requests to arbitrary internal network destinations by supplying a crafted migration URL that redirects to an internal address. The CVSS score of 6.5 (C:H) reflects that successful exploitation can expose sensitive internal service responses - including cloud metadata endpoints, internal APIs, or other intranet services - to the attacker. No public exploit or CISA KEV listing has been identified at time of analysis; a vendor patch is available in v1.26.3 and v1.26.4.

Broken authorization in Gitea (self-hosted Git service) versions up to and including 1.26.2 lets a user who holds general repository access but has NOT been granted the Code unit permission read private source content by reusing Git LFS objects to authorize otherwise-restricted source objects. The flaw (CWE-639, tracked as GHSA-2m9v-5q2g-58vq) enables horizontal privilege escalation to confidential code within a repository. There is no public exploit identified at time of analysis and it is not listed in CISA KEV, but a vendor patch shipped in 1.26.3.

Path traversal in Gitea's release asset dump functionality (all versions before 1.25.5) allows attackers who can create releases with malicious tag or asset names to influence where dump output files are written on the server filesystem. The root cause - confirmed by reviewed PR diffs - is that dump.go passed user-controlled release.TagName and asset.Name directly into filepath.Join() without sanitization. No public exploit or active exploitation has been identified; EPSS is 0.18% (8th percentile) and SSVC confirms exploitation status as none.

Branch-protection bypass in Gitea's self-hosted Git server (all versions before 1.26.0) allows a user with push access to circumvent pre-receive hook enforcement by supplying oversized hook input that trips a bufio.Scanner error the code fails to handle safely. Because Gitea does not fail closed on the scanner error, the protection check is silently skipped and the push is accepted. No public exploit identified at time of analysis; EPSS is low (0.17%, 7th percentile) and this is not in CISA KEV, but a vendor patch (v1.26.0) is available.

Canonical URL spoofing in Gitea before 1.25.5 lets remote attackers inject malformed X-Forwarded-Proto values that the server trusts when computing its public-facing URL, causing it to emit attacker-controlled canonical links (e.g. in emails, redirects, and generated absolute URLs). No public exploit identified at time of analysis, and the low EPSS score (0.17%, 6th percentile) reflects minimal in-the-wild interest, but a vendor patch is available in v1.25.5. Note that the published CVSS vector claims availability impact (A:H) while the description describes URL spoofing (an integrity concern), a discrepancy worth verifying with the vendor.

Privilege escalation in Gitea 1.25.5 lets a user holding a per-branch maintainer-edit grant reuse that write permission against other refs and obtain full repository write access. The flaw stems from a branch-specific permission result being cached and incorrectly reused across multiple refs within a single pre-receive hook session. It is an authenticated authorization-bypass (CWE-863) fixed in Gitea 1.26.3; no public exploit has been identified and EPSS exploitation probability is low (0.20%).

Broken access control in Gitea's Composer package registry (versions up to and including 1.26.1) lets remote attackers read private or internal Composer package source links they should not be authorized to see, leaking internal repository/source metadata. The flaw is a missing-authorization (CWE-862) issue reported by the Gitea project itself and fixed in v1.26.2; no public exploit identified at time of analysis, and it is not listed in CISA KEV. With a CVSS 3.0 base score of 8.2 driven by high confidentiality impact, the practical effect is unauthorized disclosure of otherwise-private package sourcing information.

Gitea's repository RSS and Atom feed endpoints fail to enforce API token scope checks, exposing private repository commit metadata to any holder of a valid but under-privileged API token. Versions up to and including 1.26.2 are affected; the flaw is classified as CWE-863 (Incorrect Authorization) with a CVSS score of 4.3. No public exploit code or CISA KEV listing exists at time of analysis; vendor-released patches are available in v1.26.3 and v1.26.4.

Broken access control in Gitea before 1.25.5 lets clients retrieve draft release metadata and their attached files through the REST API without holding the repository write permission those drafts are meant to require. The flaw stems from the API omitting a token-scope/write-access check on draft release and attachment endpoints, so read-scoped tokens (and, on publicly readable repositories, unauthenticated callers) can enumerate and download unpublished release content. There is no public exploit identified at time of analysis, EPSS risk is low (0.17%, 6th percentile), and it is not on CISA KEV.

Broken object-level authorization (IDOR) in Gitea before 1.25.5 lets an authenticated user manipulate the primary email address of an arbitrary other account by supplying an email row ID they do not own. The account-settings 'make primary' handler looked up the target email by ID alone without verifying ownership, so a logged-in attacker can alter another user's primary email - an integrity impact with account-hijack and notification-redirection potential. There is no public exploit or active exploitation, EPSS is low (0.17%), and Gitea has shipped a fix in 1.25.5.

Uncontrolled resource consumption in Gitea before 1.25.5 allows remote attackers to exhaust server CPU by triggering unbounded 'git grep' code searches that ran without any execution timeout. Because the search endpoint is network-reachable and the CVSS vector (PR:N) indicates no authentication is required, an attacker can repeatedly submit expensive regex/pattern searches against hosted repositories to degrade or deny service. No public exploit identified at time of analysis, and EPSS is low (0.18%), but SSVC marks the flaw as automatable with partial technical impact.

Migration transport protections in Gitea are bypassed for Git LFS operations, affecting all self-hosted instances before version 1.25.5. Because LFS push and sync-mirror requests instantiated their client with a nil HTTP transport (lfs.NewClient(endpoint, nil)) instead of the hardened migration transport, LFS traffic escaped the allowlist/SSRF restrictions the migration transport enforces, letting a user who can configure a repository mirror direct LFS requests to otherwise-blocked destinations. There is no public exploit identified at time of analysis and EPSS is low (0.17%), but SSVC rates technical impact as total and automatable, and a vendor patch is available.

OAuth2 PKCE protection bypass in Gitea before 1.25.5 allows remote attackers to complete an authorization-code token exchange without a valid code verifier because the server fails to persist the S256 challenge method during authorization. Rated CVSS 9.1 with SSVC technical impact of 'total', though EPSS is low (0.17%, 6th percentile) and there is no public exploit identified at time of analysis. The fix is confirmed in release v1.25.5 (PRs 36462 and 36477), which was reported by the Gitea project itself.

Authentication bypass via OAuth2 authorization code replay in Gitea before 1.25.5, where the server fails to consistently enforce code expiry and single-use during the token-exchange step, letting an attacker who obtains a valid authorization code redeem it (potentially more than once, and after it should have expired) to mint access tokens for a victim's account. The source fix confirms authorization codes previously had no enforced 10-minute validity window and that double-redemption was not reliably detected. EPSS is low (0.17%, 6th percentile) and CISA SSVC lists exploitation status as none, but SSVC rates the technical impact as total and marks it automatable; no public exploit identified at time of analysis.

Insecure direct object reference (IDOR) in Gitea's issue time-tracking feature allows authenticated users to delete tracked-time entries belonging to issues other than the one specified in the request URL. Affected are all Gitea Open Source Git Server versions before 1.25.5. The root cause is that `GetTrackedTimeByID` performed a database lookup using only the time entry's numeric ID, without filtering by the issue ID present in the URL path, enabling cross-issue data manipulation. No public exploit has been identified at time of analysis, and CISA KEV does not list this vulnerability.

Arbitrary file read and write in Gitea before 1.25.5 arises when the template repository generation feature resolves paths through symlinks or other non-regular file types instead of restricting itself to regular files within the target root. An attacker who controls a template repository can plant symlinked or special paths so that generation reads sensitive files or writes attacker-controlled data outside the intended boundary, yielding high confidentiality and integrity impact (CVSS 9.1). There is no public exploit identified at time of analysis, the EPSS probability is low (0.17%, 7th percentile), and CISA SSVC records exploitation as 'none', but the flaw is automatable with total technical impact.

Improper access control in Gitea's organization permission API (all releases before 1.25.5) lets an authenticated API caller query permission and membership details for hidden organization members and private organizations they should not be able to see. The root cause is a visibility check performed against the target user instead of the requesting user, disclosing metadata that reveals otherwise-concealed org membership and permission levels. This is an information-disclosure/access-control issue (CWE-284) with no public exploit identified at time of analysis, a low EPSS (0.16%, 5th percentile), and SSVC exploitation status of 'none'.

Information disclosure in the Gitea 1.26.2 self-hosted Git service allows non-members to read the labels of private organizations via the Organization Labels API, exposing label metadata (id, name, description, color, url) that should be restricted to org members. The authorization gap affects GET /api/v1/orgs/{org}/labels and .../labels/{id} only, while organization info, teams, hooks, and secrets endpoints correctly returned 404 to the same user. Publicly available exploit code exists in the vendor GHSA advisory, though EPSS risk is low (0.20%, 10th percentile) and it is not on CISA KEV.

Improper access control in Gitea before 1.25.5 allows users to update or rebase pull request head branches without holding the write/force-push permissions those actions require, letting them push base-branch commits or rewrite history on branches they should not control. The flaw stems from the IsUserAllowedToUpdate logic in services/pull/update.go, which failed to properly re-check repository push and branch-protection permissions on the head branch. This is an integrity-only issue (CVSS 7.5, I:H) with no confidentiality or availability impact; SSVC lists exploitation as none and EPSS is low (0.16%), and no public exploit identified at time of analysis.

Information disclosure in Gitea 1.26.2 lets a fork owner keep pulling commits from a parent repository via the merge-upstream API even after the parent was switched from public to private, exposing content the fork should no longer be authorized to see. The flaw stems from the synchronization endpoint failing to re-check the parent's current visibility, so data added during the private period leaks into a fork whose owner can no longer directly access the parent. A working proof-of-concept is publicly published and CISA SSVC rates exploitation automatable, but the issue is not on CISA KEV and EPSS is low (0.20%); it is fixed in Gitea 1.26.3.

Server-side request forgery in Gitea versions up to and including 1.26.2 lets authenticated users abuse incomplete allow-list filtering in the webhook and repository-migration features to coerce the server into making requests to internal or otherwise restricted network destinations. Because the existing SSRF protection is incomplete rather than absent, attackers can craft addresses that bypass the allow-list checks to reach services that should be unreachable from outside. No public exploit identified at time of analysis, and the flaw is not listed in CISA KEV; a vendor patch is available in Gitea 1.26.3.

Improper input validation in Gitea Open Source Git Server before 1.25.5 lets authenticated users submit repository-creation requests with unbounded template fields (issue labels, license, readme, fork branch) and unsupported trust-model or object-format values. The upstream fix (PRs 36671/36757) adds MaxSize length constraints and rejects any ObjectFormatName that is not sha1 or sha256. Rated CVSS 9.1 by the reporter, but no public exploit was identified, EPSS is only 0.17% (6th percentile), and CISA SSVC records exploitation status as none.

Unauthorized read access to tracked time entries in Gitea before 1.25.5 exposes private repository metadata to unauthenticated network actors due to missing repository-level permission checks during API serialization (CWE-284). The flaw exists in the `ToStopWatches` and `ToTrackedTimeList` conversion functions in `services/convert/issue.go`, which iterated over and returned time entries without verifying the requesting user held read access to the underlying repository. No public exploit has been identified and CISA has not added this to KEV; however, the SSVC assessment designates the flaw as automatable, meaning it can be scripted at scale against all exposed Gitea instances running affected versions.

Reverse-proxy authentication bypass in the official Gitea Docker image (versions up to and including 1.26.2) allows any source IP to impersonate arbitrary users because the image ships with REVERSE_PROXY_TRUSTED_PROXIES=* by default. When an operator enables reverse-proxy header authentication (e.g. X-WEBAUTH-USER), the wildcard trust list means Gitea accepts those identity headers from any client rather than only from a trusted front-end proxy, granting full account takeover including administrator access. No public exploit has been identified at time of analysis, and the issue is patched in Gitea 1.26.3.

TOTP two-factor authentication replay in Gitea 1.5.0 through 1.26.2 lets a captured valid one-time code be accepted multiple times instead of being invalidated after first use, weakening 2FA on both the web login flow and the Basic Auth X-Gitea-OTP header path. An attacker who observes a legitimate TOTP code (via interception, shoulder-surfing, or logging) can replay it within its validity window to authenticate as the victim. There is no public exploit identified at time of analysis and it is not listed in CISA KEV; the flaw is fixed in Gitea 1.26.3.