Gitea

Public-only personal access token scope enforcement in Gitea's REST API is inconsistently applied across two organization endpoints, allowing a token holder to enumerate private organization memberships and retrieve detailed permission data (ownership, admin status, write access, repository-creation capability) that the public-only restriction was explicitly designed to block. All Gitea versions prior to 1.27.0 are affected via GET /api/v1/user/orgs and GET /api/v1/users/{username}/orgs/{org}/permissions. Publicly available exploit code with full HTTP request/response traces is confirmed in the GHSA advisory; no CISA KEV listing exists, indicating no confirmed opportunistic mass exploitation at time of analysis.

SSRF protection bypass in Gitea versions prior to 1.27.0 allows attackers with admin or org-owner privileges to exfiltrate cloud instance metadata (AWS IMDSv1 credentials, GCP tokens) and read arbitrary local files including the app.ini configuration file containing database credentials, JWT signing secrets, and SMTP passwords. Three distinct code paths in modules/uri/uri.go, services/migrations/dump.go, and routers/web/auth/oauth.go use Go's raw http.DefaultClient instead of the hardened hostmatcher transport that protects webhook and clone operations. A detailed proof-of-concept is published in GHSA-2wm4-vwp6-v7xc; no active exploitation has been confirmed (not in CISA KEV at time of analysis).

Webhook authorization headers in Gitea are decrypted and returned as plaintext in API responses, exposing Bearer tokens, Basic auth credentials, and API keys to any repository admin who queries the webhook listing endpoints. All Gitea installations running versions prior to 1.27.0 are affected, confirmed by GitHub Advisory GHSA-3r5c-2xxx-h872 and verified against commit 19f0169. Although these secrets are encrypted at rest using the server's SecretKey, the ToHook() function strips that protection before serializing the API response - effectively converting a write-only secret into a readable credential. No public exploit has been identified and this vulnerability is not listed in CISA KEV, but the business impact of leaking third-party API keys in multi-admin environments exceeds what the CVSS 2.7 Low score implies.

Cross-repository information disclosure in Gitea's org-level Actions API exposes workflow run and job metadata from private repositories to any authenticated organization member, regardless of per-repository access rights. The endpoints GET /api/v1/orgs/{org}/actions/runs and GET /api/v1/orgs/{org}/actions/jobs bypass per-repo ACL checks entirely, allowing low-privileged org members with no team or repository assignments to enumerate private repo names, commit SHAs, branch names, workflow file paths, contributor identities, CI timing, and commit messages across the entire organization. No CISA KEV listing or separately published exploit tool has been identified, but the detailed advisory with curl reproduction commands substantially lowers the exploitation barrier.

Gitea's REST API path for making repositories private omits the ClearRepoWatches cleanup present in the web UI path, exposing private repository metadata to ex-watchers from v1.25.4 through v1.26.x. When the visibility transition occurs via PATCH /api/v1/repos/{owner}/{repo} - the canonical path used by terraform-gitea, official SDKs, and CI/CD automation - the updateRepository function clears stars but leaves watch records intact, allowing former watchers to retrieve the full Repository JSON payload (description, branch, language, topics, counts, mirror metadata) via GET /api/v1/user/subscriptions despite having no access to the repository. This is a confirmed incomplete fix relative to GHSA-8fwc-qjw5-rvgp; no public exploit identified at time of analysis, though the advisory provides complete reproduction steps directly derivable from static code analysis.

Incorrect authorization enforcement in Gitea's team API routes exposes private repository metadata and activity feed entries to public-only access tokens. Affected versions through 1.26.2 allow an authenticated team member holding a public-only scoped token to bypass the intended access restriction and retrieve private team repository listings and private activity feed data via /api/v1/teams/{id} endpoints. Publicly available exploit code (PoC) has been verified against Gitea 1.26.2 and nightly builds; no KEV listing at time of analysis. EPSS data not provided, but the CVSS score of 4.3 and limited confidentiality impact (metadata only, no code exfiltration) suggest moderate real-world risk.

Private organization member enumeration in Gitea allows any authenticated user to retrieve the full member list - including emails - of a private organization via the /api/v1/orgs/{org}/members endpoint. All Gitea instances running v1.26.4 or earlier are affected; the flaw stems from an incomplete fix (PR #38145) that corrected ListPublicMembers and IsPublicMember but left ListMembers without the HasOrgOrUserVisible visibility gate. Publicly available exploit code exists in the form of a documented proof-of-concept curl command in the GHSA advisory. No KEV listing; exploitation is opportunistic rather than targeted given the low barrier to entry for any credentialed user.

Server-side request forgery in Gitea before 1.27.0 lets attackers coerce the server into HTTP requests against internal hosts because its outbound IP allow-list classifier (IsGlobalUnicast && !IsPrivate) fails to block CGNAT (100.64.0.0/10) and nine IPv6 transition prefixes. An authenticated user can point a webhook or repo migration at an internal CGNAT service and read the full response (status, headers, and up to 1 MB body) rendered back on the hook detail page; separately, when OpenID sign-in is enabled the unauthenticated /user/login/openid discovery fetch uses http.DefaultClient with no IP filtering, giving anonymous internet callers a blind SSRF primitive. Publicly available exploit code exists (bundled run_poc.sh reproduces all three primitives), but no active exploitation is confirmed.

Uncontrolled CPU consumption in Gitea (code.gitea.io/gitea, all versions < 1.27.0) lets a remote unauthenticated attacker stall the server by sending a single crafted Accept-Language header. The Locale middleware runs on every request - including the landing and sign-in pages - and passes the raw header into golang.org/x/text's ParseAcceptLanguage, whose quadratic-time scanner is reachable because the CVE-2022-32149 hardening only counts '-' separators while the scanner also treats '_' as a separator alias. A 1 MiB header of '_'-separated garbage tokens burns ~2 seconds of one CPU core per request while returning HTTP 200, and publicly available proof-of-concept code (bash one-liner plus a Go E2E driver) demonstrates the bypass; no active exploitation is reported.

Remote denial-of-service in Gitea versions prior to 1.27.0 allows any authenticated user to crash the server by exploiting an O(N²) string concatenation flaw in the RFC 4716 SSH key parser. Submitting a single crafted SSH2 public key with hundreds of thousands of short content lines forces quadratic heap allocation that exhausts CPU and RAM within seconds, taking the entire Gitea instance offline. A functional, Docker-packaged proof-of-concept is publicly available per the Gitea security advisory; no active exploitation has been confirmed in CISA KEV, but the trivially low barrier - any valid user account suffices - elevates real-world risk considerably.

Repository visibility and template status in Gitea (self-hosted Git service) before 1.27.0 can be silently toggled by any repository owner or admin-collaborator through undocumented git push options (repo.private, repo.template) processed by the post-receive hook, bypassing all audit logging, webhooks, and notifications. An insider can flip a private repository to public long enough to clone proprietary code, then revert it, leaving only two ordinary push events in the activity feed. No CISA KEV listing and no separately published exploit tool exist, but the GHSA advisory ships full working reproduction commands, and the CVSS 3.1 base score is 7.1 (High).

Improper authorization in Gitea before 1.27.0 lets an administrator-deactivated user (IsActive=false) silently reactivate their own account by signing in through an OAuth2/OIDC source that issues no refresh token - notably GitHub, or any OIDC source without offline_access. The reactivation gate added in PR #38009 uses an empty stored refresh token as its signal for 'disabled by auto-sync cron,' but for these sources every user has an empty refresh token, so an administrator's deliberate deactivation is indistinguishable from a cron disable and gets undone on the next login, granting a full session (including regained admin rights, since deactivation does not clear IsAdmin). No public exploit code is packaged, but a detailed, reproducible proof-of-concept is published in the vendor advisory; not listed in CISA KEV.

LFS deploy-key privilege escalation in Gitea (< 1.27.0) allows a holder of a write deploy key for any single repository owned by a victim to exfiltrate LFS objects from all private repositories that victim owns. The flaw originates in `routers/private/serv.go:275`, where Gitea embeds `repo.OwnerID` as the JWT `UserID` for deploy-key SSH sessions, causing the LFS batch handler at `services/lfs/server.go:268` to evaluate cross-repository authorization as if the repository owner - not the deploy key - were the requesting principal. If the victim is a Gitea site administrator, an unfiltered query in `models/git/lfs.go:226` exposes every LFS object on the entire instance. A public end-to-end PoC (poc.sh) is attached to the GitHub advisory; no CISA KEV listing exists at time of analysis.

Local file inclusion in Gitea's restore-repo CLI command allows operator-level attackers to exfiltrate arbitrary server-side files by embedding file:// URIs in release attachment DownloadURL fields within a crafted restore archive. Affected across all releases through v1.22.x (and unpatched master builds), with a fixed version available at 1.27.0. A working proof-of-concept was published by the reporting researchers; no active exploitation has been confirmed by CISA KEV, but successful exploitation yields direct access to high-value secrets including database credentials, SSH private keys, TLS certificates, and cloud provider tokens stored on the Gitea host.

Gitea's OIDC userinfo endpoint (`GET /login/oauth/userinfo`) bypasses API token scope enforcement, exposing email addresses and organization/team membership to any valid token holder regardless of assigned scopes. A token scoped exclusively to `read:misc` - which is correctly denied access to `/api/v1/user`, `/api/v1/user/emails`, and `/api/v1/user/orgs` - successfully retrieves identity claims through the OIDC endpoint. A public proof-of-concept exists; the issue is fixed in Gitea v1.27.0 and is not confirmed in the CISA KEV catalog.

Improper TLS certificate validation in Gitea versions prior to 1.27.0 lets an on-path attacker intercept the internal API channel and steal the static, high-privilege INTERNAL_TOKEN. The internal API HTTP client (modules/private/internal.go) hardcodes InsecureSkipVerify:true with no config override, so gitea serv / gitea hook subprocesses accept any certificate when LOCAL_ROOT_URL uses HTTPS to a non-loopback host. A detailed proof-of-concept is published in the vendor advisory, but there is no evidence of active exploitation; the token grants full control over every /api/internal/* endpoint, including server shutdown, SSH key authorization, and arbitrary git command execution.

Gitea's REST API leaks organization membership for private organizations through the GET /orgs/{org}/public_members/{username} endpoint, allowing any authenticated API user to enumerate whether a specific user belongs to a private organization. Affected versions are all releases prior to 1.27.0. The vulnerability bypasses the privacy controls enforced by the web interface, where private organization membership is intentionally hidden from non-members. No public exploit identified at time of analysis, though a detailed proof-of-concept is included in the GitHub security advisory GHSA-jr5x-6h83-wrxf.

RSS/Atom feed handlers in Gitea prior to v1.27.0 expose private repository content - commit metadata, release notes, tag names, and cross-repo activity streams - to holders of confined API tokens that are explicitly blocked from the same data via download routes. The bypass breaks the token-confinement guarantee introduced by PR #37698 for raw/archive/download handlers, which was never extended to the sibling feed endpoints despite those endpoints accepting identical token-based Basic auth. A working proof-of-concept is documented in the GHSA advisory verified against the official gitea/gitea:1.26.2 Docker image; the vulnerability is not confirmed in CISA KEV, and the primary realistic threat is a leaked or lower-trust token used in CI or third-party integrations circumventing its intended scope restrictions.

Gitea's Actions permission system (v1.26.2 and earlier) exposes full source code of third private repositories to untrusted fork-PR authors due to a missing fork-PR guard in the collaborative-owner permission branch of GetActionsUserRepoPermission. When a private target repo B configures a collaborative owner pointing to org/user A, an attacker with read access to any private repo under A can submit a fork PR, trigger the Actions workflow, and clone repo B's source code without authorization. A working proof-of-concept demonstrating the full git clone via crafted task-token HTTP Basic auth is included in advisory GHSA-fj8v-hjwv-qm88, but no active exploitation has been confirmed and this vulnerability is not listed in CISA KEV.

Denial of service in Gitea's NPM package registry API allows any authenticated user to crash the entire server process with a single HTTP request by exploiting an unbounded `io.ReadAll()` call in the `AddPackageTag` handler. Gitea versions up to and including v1.26.2 are confirmed vulnerable, with the fix shipped in v1.27.0. Because self-registration is enabled by default, external unauthenticated attackers can register a free account and immediately exploit this to take down all Gitea-hosted services including repositories, CI/CD pipelines, and issue tracking; a detailed proof-of-concept with video evidence is publicly available in the advisory.

Cross-repository label-ID enumeration oracle in Gitea through v1.26.3 allows any authenticated user with write:issue permission on any repository to probe label ID existence across all repositories and organizations on the instance - including private ones they cannot access. The flaw arises because the DELETE /repos/{owner}/{repo}/issues/{index}/labels/{id} API handler performs a global, unscoped label lookup and leaks existence via differential HTTP status codes (204 vs. 422). No label names, colors, repository associations, or content are disclosed, and no cross-repository writes occur; however, a working proof of concept was verified against v1.26.3 and a fix is available in v1.27.0. No public exploit identified at time of analysis beyond the verified PoC in the advisory.

Token scope enforcement is bypassed on Gitea's repository home page handler (`repo.Home`), exposing private repository README, root file/directory tree, description, language statistics, license, and latest-release data to any authenticated PAT or OAuth2 token that lacks the `repository` scope or is marked `public-only`. This is the third in a series of related incomplete fixes - CVE-2026-20706 and CVE-2026-27761 patched sibling routes (archive download and RSS/Atom feeds) but the home route was overlooked, leaving it without the `CheckRepoScopedToken` guard applied to every neighboring handler. Publicly available exploit code exists in the form of a self-contained Docker-based proof-of-concept published in the vendor advisory; no active exploitation has been confirmed by CISA KEV.

Broken authorization in Gitea before 1.27.0 lets a token scoped as public-only,write:repository push commits into a PRIVATE repository via the PR head-branch update endpoint, defeating the public-only restriction the token was granted. An attacker holding such a token (for an account with normal write access to the private head branch) uses the public base repo's route POST /api/v1/repos/{owner}/{repo}/pulls/{index}/update to force public base commits into the private head branch - a write the same token is denied when attempted directly. A detailed proof-of-concept is published in the vendor advisory; there is no public exploit identified as actively exploited in the wild.

Server-side request forgery in Gitea's repository migration feature allows authenticated low-privilege users to bypass the SSRF allow/block-list filter by supplying an attacker-controlled DNS hostname that returns both a permitted public IP and a blocked private or loopback IP. Because the pre-flight validation accepts the hostname if any single resolved IP is permitted (OR logic), and because the subsequent `git clone --mirror` subprocess performs an independent DNS resolution with no binding to the validated IP set, an attacker can cause Gitea to connect to internal-only Git services and exfiltrate their contents into an attacker-controlled repository. No public exploit identified at time of analysis, but a functional proof-of-concept reproducer is included in the advisory and has been confirmed by the reporter against a specific Gitea commit.

Server-Side Request Forgery in Gitea's `restore-repo` CLI command allows an attacker who can supply a malicious dump archive to a Gitea administrator to force the server to issue `git fetch` against arbitrary attacker-controlled or internal URLs, including cloud metadata endpoints and local filesystem paths via `file://`. The root cause is a Go language logic defect: `CheckAndEnsureSafePR` is invoked with an empty `commonCloneBaseURL` string, causing `strings.HasPrefix(anything, "")` to always return `true`, which silently disables the URL validation guard for `Head.CloneURL` in the restore path only. A detailed PoC is publicly documented in the GHSA advisory; no CISA KEV listing is present, indicating active exploitation is unconfirmed at time of analysis. Fix is available in Gitea v1.27.0.

Privilege escalation in Gitea versions prior to 1.27.0 lets any holder of a low-scope personal access token mint a fully-privileged token without the account password. Supplying a restricted token (e.g. write:user leaked from a CI secret) in the Authorization: Basic <token>:x-oauth-basic format fools the reqBasicOrRevProxyAuth middleware into treating the request as password-authenticated, and the CreateAccessToken handler then enforces no scope ceiling, so a caller can request the all scope and gain full account access. The vendor patched this in 1.27.0; publicly available exploit code exists as a working integration test, but there is no public exploit identified as being used in active attacks.

Denial of service in Gitea's Debian package registry (all versions before 1.27.0) lets any authenticated user with package write access crash the server with a single .deb upload. The parser's ParseControlFile decompresses control.tar.gz with no size limit and tees the entire stream into a strings.Builder, so an 83 MB payload expands to 16+ GB and exhausts memory; a companion O(N²) string concatenation on Description continuation lines can independently saturate a CPU core. A complete working proof-of-concept is published in the advisory, so publicly available exploit code exists, though there is no public exploit identified as used in active attacks and the issue is not in CISA KEV.

Private repository existence disclosure in Gitea allows fully unauthenticated remote attackers to confirm the existence, enumerate names, harvest clone URLs, and identify default branch names of private repositories by appending the `?go-get=1` query parameter to any repository-scoped URL. All Gitea instances running versions prior to 1.27.0 are affected regardless of repository visibility configuration. No public exploit identified at time of analysis as a dedicated exploit tool, though a detailed proof-of-concept with working `curl` and shell enumeration scripts is published in the GHSA advisory, making exploitation trivially repeatable.

Cross-repository attachment re-linking in Gitea exposes private issue and comment attachments to authenticated attackers who know a victim's attachment UUID. An attacker with issue-editing rights in any repository they can access can inject a victim UUID into the files[] parameter of an issue or comment edit request, causing Gitea to re-link that attachment into the attacker's authorization context; subsequent requests to /attachments/{uuid} then resolve access against the attacker's repository rather than the victim's, delivering the private file. No public exploit code has been identified at time of analysis, but the GHSA advisory (GHSA-6c6r-5xr4-cr5m) includes a detailed step-by-step reproduction runbook. The vendor-released fix is Gitea v1.27.0.

Blind server-side request forgery in Gitea's OAuth2 avatar synchronization path allows a low-privileged authenticated user to force the server to issue arbitrary outbound HTTP GET requests to attacker-controlled URLs. Gitea versions prior to 1.27.0, when configured with `[oauth2_client] UPDATE_AVATAR = true`, call Go's unrestricted `http.Get()` on the OIDC `picture` claim without applying the `hostmatcher.NewDialContext` restrictions used elsewhere in the codebase - enabling requests to loopback, RFC1918, and cloud metadata addresses such as `169.254.169.254`. No active exploitation is confirmed in CISA KEV, but a functional proof-of-concept is included in the vendor advisory, and the fix is available in Gitea v1.27.0.

OAuth token introspection in Gitea prior to v1.27.0 discloses token metadata - including active status, scope, username, and JWT registered claims - to any authenticated OAuth client regardless of whether that client is the token's intended audience, violating RFC 7662 section 4. Any registered OAuth application on the target instance can call `/login/oauth/introspect` with a token issued to a completely different client and receive a valid response. No public exploit is confirmed in CISA KEV, but a complete proof-of-concept reproduction script (`poc.sh`) is publicly attached to the GHSA advisory, making exploitation trivially reproducible by anyone with a registered OAuth client credential.

Gitea's Arch package registry allows authenticated users with package-publishing permissions to trigger severe resource amplification by uploading crafted `.pkg.tar.gz` archives containing large numbers of empty file entries. A 470 KB compressed archive can produce 4.5 MB of database-stored metadata and a repository index with 100,001 lines - approximately 45x amplification - affecting CPU, memory, database storage, and index generation. Publicly available exploit code exists (a complete Python POC is included in the advisory); no active exploitation is confirmed in CISA KEV. The vulnerability is patched in Gitea v1.27.0.

Persistent account takeover in Gitea versions prior to 1.27.0 arises because the Remember-Me (gitea_incredible) split-token design fails to revoke a compromised token after detecting hash-mismatch reuse. An attacker who has already stolen a victim's Remember-Me cookie authenticates, receives a rotated token under the same ID, and remains logged in indefinitely - because when the legitimate user's original token later triggers a detected hash mismatch, Gitea deletes only the victim's local cookie and never removes the compromised token row from the database. There is no public exploit identified at time of analysis, but the vendor has published GHSA-rgv6-xp99-6mgj and shipped a fix in 1.27.0.

Draft release attachment disclosure in Gitea exposes files uploaded to draft releases to unauthenticated network callers via UUID-based web endpoints, bypassing access controls that correctly gate the parallel API handlers. This is an incomplete fix for CVE-2026-27660: that advisory's PR #36659 added `canAccessReleaseDraft` checks to every API code path but left the web-side `ServeAttachment` handler ungated, allowing anyone who obtains an attachment UUID to download its contents with no authentication. A working proof-of-concept is documented in the advisory and confirmed against Gitea v1.27.0+dev; no public exploit identified at time of analysis beyond the advisory PoC, and the vulnerability does not appear in CISA KEV.

Release attachment extension allowlist bypass in Gitea before v1.27.0 lets any authenticated repository write-permission holder rename an existing release attachment to a forbidden extension (e.g., .exe, .html, .svg) via the web release edit form, silently defeating the operator-configured `Repository.Release.AllowedTypes` enforcement. This is a variant of CVE-2025-68939: the parent fix (PR #32151) patched the API edit endpoint but left the web `EditReleasePost` handler unguarded, constituting CWE-424 (Improper Protection of Alternate Path). A self-contained Python PoC (GITEA-R007) is publicly available demonstrating end-to-end exploitation; no CISA KEV listing at time of analysis.

Public-only PAT scope enforcement in Gitea is bypassed for Repository and Package categories when the resource owner has `Visibility = Limited` (instance-internal), allowing a low-privileged attacker with a public-only token to read internal content that exceeds anonymous reach. Affected are all API v1 Repository endpoints, all 24 native package registries, web download routes (/raw, /media, /attachments), and LFS routes in Gitea versions prior to 1.27.0. This is a residual authorization gap after CVE-2026-25714 / PR #37118; a verified proof-of-concept script exists, confirmed on gitea/gitea:1.26.2 as of 2026-06-05, and no public exploit has been confirmed as actively exploited in CISA KEV at time of analysis.

Branch protection bypass in Gitea versions prior to 1.27.0 allows a user with write (non-admin) access to merge unauthorized code into a protected branch by exploiting a stale approval flag. When a pull request is retargeted from an unprotected branch to a protected one via ChangeTargetBranch, Gitea fails to re-evaluate the stored official=true flag on existing approvals, so an approval that was never valid under the protected branch's whitelist still satisfies its required-approvals gate. Publicly available exploit code exists (a detailed step-by-step PoC in the GHSA advisory); no public exploit identified as actively used and it is not in CISA KEV.

Private repository metadata and issue titles leak to revoked Gitea users via two REST API endpoints that omit post-revocation authorization checks, constituting an incomplete fix relative to CVE-2026-20800. Former collaborators with a still-valid API token can call `GET /api/v1/user/starred` to receive full repository objects - including `clone_url` and `ssh_url` - for private repos they starred, and `GET /api/v1/user/times` to retrieve private issue titles and states for issues on which they logged time, indefinitely after repo access is revoked. Impact is metadata-only; no public exploit code has been identified at time of analysis and no CISA KEV listing exists.

Webhook persistence after collaborator revocation in Gitea (versions prior to 1.27.0) enables a former admin collaborator to receive ongoing real-time exfiltration of private repository content indefinitely after their access is removed. The `DeleteCollaboration()` function cleans watches and assignees but never removes or disables webhooks created by the departing user, and the webhook delivery subsystem fires payloads on every subsequent repository event without re-validating the creator's current access. The attack is invisible to the repository owner, requires no further action by the attacker post-revocation, and was runtime-confirmed on gitea/gitea:1.25.4; no public exploit has been identified at time of analysis.

Server-side request forgery and internal repository exfiltration in Gitea before 1.27.0 lets a low-privileged authenticated user bypass the migration URL allow/block list by supplying a permitted public Git URL that HTTP-redirects the server's git subprocess to an otherwise-blocked internal endpoint. Because Gitea validates only the originally submitted URL while git runs with its default http.followRedirects=initial, the redirected internal Git repository is cloned into an attacker-controlled repository, and pull mirrors keep re-fetching it on schedule. No public exploit identified at time of analysis; a vendor-authored local proof-of-concept confirmed the redirect is followed to 127.0.0.1, and EPSS/KEV data were not supplied.

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.

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.

Approval-gate bypass in Woodpecker CI before 3.15.0 lets an attacker who can open a merge request from a fork against a GitLab-backed repository run unapproved, attacker-controlled pipelines. Because the GitLab forge driver populates pipeline.Author from the spoofable git commit author name (commit.author.name) rather than the GitLab-validated user identity, an attacker simply sets the commit author to a name listed in ApprovalAllowedUsers, making needsApproval return false. This grants arbitrary CI step execution on a Woodpecker agent and exposure of CI secrets; there is no public exploit identified at time of analysis, but the issue was reported by VulnCheck and is trivially reproducible.

Container escape in Gitea act_runner (Docker backend, through act 0.262.0) lets an authenticated user with workflow-execution rights break out to the host as root even when privileged mode is disabled. The runner passes a workflow's container.options string straight into the Docker job container's HostConfig and only forces the Privileged flag off, leaving dangerous options like --pid=host, --cap-add, and --security-opt intact. Publicly available exploit code exists (reported by VulnCheck), though it is not listed in CISA KEV.

Open redirect in Gitea's login flow allows external domain hijacking by bypassing the `urlIsRelative` validation in `modules/httplib/url.go` through a combination of directory traversal sequences and a backslash in the `redirect_to` parameter. All Gitea instances running version 1.25.4 and below are affected; a working proof-of-concept is publicly available in the GitHub Security Advisory. Exploitation enables phishing via trusted Gitea domains, OAuth/SSO authorization code theft, Referer-header leakage of sensitive parameters, and potential cache poisoning — no public exploit identified as confirmed actively exploited (CISA KEV absent).

Stored cross-site scripting in Gitea 1.25.x affects the built-in 3D file viewer (Online3DViewer integration) where a crafted .gltf file with an unsupported extension name in extensionsRequired is rendered into the DOM via innerHTML without sanitization. Any low-privileged user who can push a file to a repository (including a public fork) can compromise the session of any user who later views the file, enabling token theft and full account takeover. Publicly available exploit code exists (a working PoC is included in the GHSA-9cpj-qc93-vw8v advisory); no public exploit identified at time of analysis in CISA KEV.

Authorization bypass in Gitea versions 1.22.3 through 1.26.1 allows holders of `public-only` access tokens or OAuth grants to read and modify private account resources via `/api/v1/user/...` self routes, despite the public-only flag being designed to restrict tokens to public data. The flaw is a systemic scope-boundary failure across many self routes (SSH keys, emails, OAuth apps, Actions secrets/variables/runners, private repos, webhooks), publicly available exploit code exists in the form of reproducible Go PoCs in the advisory, and the issue represents an incomplete fix of CVE-2025-68941 in a different route family.

Authorization bypass in Gitea versions prior to 1.26.0 lets a read-only organization member create repositories in the organization namespace via the API fork endpoint, despite a team configuration that denies repository creation (can_create_org_repo=false). Because the fork creator receives admin rights on the resulting repo, the attacker can enable Actions and push a workflow that exfiltrates all organization-level CI/CD secrets (deploy keys, cloud credentials, API tokens). Publicly available exploit code exists in the GHSA advisory with a full step-by-step PoC; no public exploit identified at time of analysis beyond the reporter's reproduction.

Missing repository-unit authorization on three Gitea API endpoints allows authenticated users with only non-Code unit access (e.g., an Issues-only organization team member) to read `.gitea/ISSUE_TEMPLATE/*` and `issue_config.yaml` files from the Code default branch of a private repository. The CVSS score of 4.3 (PR:L, C:L) accurately reflects the narrow scope: exploitation is limited to those specific configuration files, not arbitrary source code. A proof of concept is publicly documented in the vendor advisory (GHSA-3fwp-p5rj-2pxf); no active exploitation is confirmed in the CISA KEV catalog at time of analysis.

Public-only scoped API tokens in Gitea bypass their declared scope constraints and expose private organization membership data through two distinct code defects in `routers/api/v1/api.go`: the `/user/orgs` route omits the `checkTokenPublicOnly()` middleware entirely, and the `checkTokenPublicOnly` function contains a Go switch-case logic flaw that skips the user-visibility check on multi-category routes. This is an incomplete remediation of CVE-2025-68941 introduced by PR #32204, affecting all Gitea instances running version 1.26.1 and earlier. No public exploit code or active exploitation (CISA KEV) has been identified at time of analysis, but the attack is trivially reproducible from the published advisory steps.

Authorization bypass in Gitea versions up to and including 1.26.1 allows any authenticated user with mere read access to push arbitrary commits directly to any repository they can view, including all public repositories on the instance. The flaw stems from the 'Allow edits from maintainers' pull request flag being trusted without verifying the PR submitter actually owns write access on the HEAD side, enabling reverse-fork PRs to grant unauthorized push rights to upstream targets. Publicly available exploit code exists (a working poc.py is attached to the advisory), and the issue is fixed in Gitea 1.26.2.

OAuth2 scope enforcement bypass in Gitea <= 1.26.1 allows any OAuth2 access token to perform write actions far beyond its granted scope when submitted via HTTP Basic authentication instead of as a Bearer token. A token issued with only `read:user` can modify user settings, add attacker-controlled emails, and create or delete the user's repositories, effectively nullifying the entire OAuth2 scope model for Basic-auth requests. No public exploit identified at time of analysis, but the advisory itself contains a full working PoC.

Authorization scope bypass in Gitea v1.26.1 and earlier allows authenticated users to use OAuth2/PAT Bearer tokens to perform Git Smart HTTP clone, fetch, and push operations on private repositories without holding the required read:repository or write:repository token scopes. The flaw stems from CheckRepoScopedToken() short-circuiting unless ctx.IsBasicAuth is true, while the same route accepts Bearer authentication. No public exploit identified at time of analysis beyond the reporter's PoC test in the GHSA advisory.

Gitea fails to validate repository ownership when linking attachments to releases, allowing users to attach files from one repository to releases in another.

Gitea's OpenID URI visibility controls lack proper ownership validation, allowing authenticated users to modify the visibility settings of other users' OpenID identities. This integrity bypass affects any Gitea instance where multiple users manage OpenID configurations, enabling account enumeration or information disclosure through unauthorized visibility changes. A patch is available to remediate this medium-severity vulnerability.

Gitea fails to validate repository ownership when deleting Git LFS locks, allowing users with write access to one repo to delete LFS locks in other repositories.

Gitea fails to enforce proper authorization checks when users attempt to cancel scheduled auto-merges through the web interface, allowing any user with pull request read access to cancel merge operations initiated by other users. This authorization bypass could disrupt automated workflows and merge processes across repositories. A patch is available to address this vulnerability.

Gitea's stopwatch API fails to re-validate repository access permissions, allowing revoked users to access sensitive information through active stopwatch sessions. An authenticated attacker with prior access to a private repository can enumerate issue titles and repository names even after their permissions have been removed. A patch is available to enforce proper access control validation.

Gitea's notification API fails to re-validate repository access permissions when retrieving notification details, allowing users with revoked access to private repositories to continue viewing issue and pull request titles through cached notifications. An authenticated attacker can exploit this to maintain visibility into sensitive repository content after their access has been removed. A patch is available.

Gitea does not properly validate project ownership in organization operations, allowing users with project write access to manipulate projects belonging to other organizations.

Gitea fails to properly validate repository ownership when processing attachment deletion requests, allowing an authenticated attacker to delete files from repositories they no longer have access to by routing deletion requests through a different accessible repository. This authorization bypass affects all users who have uploaded attachments to shared repositories and could result in loss of critical project documentation or resources. A patch is available to address this improper access control vulnerability.

Gitea may send release notification emails for private repositories to users whose access has been revoked. [CVSS 3.5 LOW]

In Gitea before 1.25.2, /api/v1/user has different responses for failed authentication depending on whether a username exists. [CVSS 5.3 MEDIUM]

Improper Neutralization of Input During Web Page Generation (XSS or 'Cross-site Scripting') vulnerability in Gitea Gitea Open Source Git Server allows Stored XSS.22.0. Rated critical severity (CVSS 10.0), this vulnerability is remotely exploitable, no authentication required, low attack complexity. No vendor patch available.

Open Redirect in GitHub repository go-gitea/gitea prior to 1.19.4. Rated medium severity (CVSS 4.4), this vulnerability is remotely exploitable. Public exploit code available.

In Jenkins Gitea Plugin 1.4.4 and earlier, the implementation of Gitea personal access tokens did not support credentials masking, potentially exposing them through the build log. Rated medium severity (CVSS 4.3), this vulnerability is remotely exploitable, low attack complexity. No vendor patch available.

Gitea before 1.17.3 does not sanitize and escape refs in the git backend. Rated critical severity (CVSS 9.8), this vulnerability is remotely exploitable, no authentication required, low attack complexity.