Gitea
Monthly
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).
Authenticated command injection in Dokploy (self-hostable PaaS) versions 0.29.3 through 0.29.12 lets a low-privileged user achieve arbitrary host command execution by storing a malicious Git branch value and triggering a deployment. The branch fields (customGitBranch, branch, gitlabBranch, bitbucketBranch, giteaBranch) were left without server-side validation because the earlier fix for CVE-2026-45628 was incomplete, so attacker-controlled input flows unescaped into shell-based git clone commands. No public exploit has been identified at time of analysis, but the flaw carries a CVSS of 9.9 and is fixed in 0.29.13.
SSRF protection bypass in Gitea prior to 1.27.0 exposes internal services, cloud instance-metadata endpoints (e.g., AWS IMDSv1 at 169.254.169.254), and local files - including the application configuration containing database credentials and signing secrets - to authenticated attackers. Three HTTP fetch code paths in the migration and OAuth avatar subsystems use Go's raw http.Get() rather than the hardened hostmatcher.NewDialContext() transport used elsewhere, completely circumventing Gitea's built-in SSRF defenses. A publicly available proof-of-concept is included in the GHSA advisory; no confirmed active exploitation (CISA KEV) has been identified at time of analysis.
Server-side request forgery in Gitea ≤1.26.4 allows privileged users to bypass the platform's own hostmatcher SSRF defenses via three unprotected raw http.Get() code paths in the migration and OAuth avatar subsystems, enabling retrieval of cloud instance metadata (AWS IMDSv1, GCP tokens), local file read (e.g., app.ini with database credentials and JWT secrets), and internal network scanning. A detailed proof-of-concept exploit is publicly available in the GitHub Security Advisory GHSA-2wm4-vwp6-v7xc. EPSS is low at 0.16% (6th percentile), consistent with the privilege requirements limiting opportunistic exploitation, but the disclosed PoC and the sensitivity of reachable data elevate real-world risk for cloud-hosted deployments. No active exploitation is confirmed in CISA KEV at time of analysis.
Private organization member enumeration in Gitea allows any authenticated user to retrieve the full member roster - including emails - of a private organization via the /api/v1/orgs/{org}/members endpoint. The root cause is an incomplete fix: PR #38145 added visibility guards to ListPublicMembers and IsPublicMember but omitted the same guard from ListMembers, leaving a single missing HasOrgOrUserVisible check in routers/api/v1/org/member.go. Proof-of-concept code is publicly available in the GitHub Security Advisory; no active exploitation has been confirmed in CISA KEV, and the EPSS score of 0.16% (5th percentile) indicates low probability of widespread automated exploitation.
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.
Unauthenticated denial of service in Gitea's Locale middleware allows any remote attacker to consume ~2 seconds of server CPU per HTTP request by crafting a ~1 MiB Accept-Language header composed of underscore separators, bypassing the existing CVE-2022-32149 guard in golang.org/x/text which only counts dash characters. All Gitea releases from 1.22.x through 1.26.x are affected because the middleware at modules/web/middleware/locale.go:38 passes the raw, unfiltered header directly to the quadratic-time ParseAcceptLanguage parser; ten concurrent attackers consuming ~10 MiB/s of upstream bandwidth can saturate all cores of a ten-core host indefinitely. Publicly available exploit code exists in the GHSA advisory; no active exploitation has been confirmed by CISA KEV at time of analysis.
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.
Identity-claim disclosure in Gitea (self-hosted Git server) before 1.27.0 lets any holder of a valid personal access token retrieve their email and organization/team membership from the OIDC userinfo endpoint (GET /login/oauth/userinfo) even when the token's scopes (e.g. only read:misc) would deny the equivalent REST API calls. The endpoint accepts API tokens as bearer credentials but skips the scope enforcement applied elsewhere, collapsing the authorization boundary that scoped tokens are meant to provide. Publicly available exploit code exists; the flaw is not in CISA KEV and EPSS is low (0.17%).
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 private organization membership through the `GET /orgs/{org}/public_members/{username}` endpoint, bypassing the visibility controls that correctly conceal this information in the web UI. All versions up to and including 1.26.4 are affected, permitting any user with a valid API token to confirm whether a specific user belongs to a hidden organization - data intentionally withheld from the web interface. No public exploit is confirmed in CISA KEV, though a detailed proof-of-concept with curl commands is documented in GHSA-jr5x-6h83-wrxf; EPSS stands at 0.16% (5th percentile), indicating low observed exploitation probability.
Gitea's Actions permission engine grants fork-PR task tokens unauthorized code-read access to third private repositories via a missing fork-PR discriminator in the collaborative-owner branch of `GetActionsUserRepoPermission`. All Gitea instances running versions up to and including 1.26.4 are affected when the collaborative-owner Actions feature is configured, as confirmed by vendor advisory GHSA-fj8v-hjwv-qm88 and EUVD-2026-58151. An attacker who has had at least one fork PR previously approved can exploit this to clone the full source of a private repository they were never authorized to access; impact is strictly read-only, with no write or code-execution capability. A functional PoC was included in the security advisory; this CVE is not in the CISA KEV catalog and no EPSS score was provided in the available data.
Broken authorization in Gitea (self-hosted Git server) versions before 1.27.0 lets a token scoped as public-only,write:repository push commits into a private pull-request head branch it should never touch. Because Gitea only evaluates the public-only restriction against the public base repository named in the route (POST /api/v1/repos/{owner}/{repo}/pulls/{index}/update) and never re-applies it to the private head repository, an attacker holding such a token can force a server-side write into the private repo and, where Actions is enabled, trigger its push workflow. This is CWE-863 incorrect authorization; a publicly available exploit code exists in the vendor advisory, EPSS is low at 0.24%, and it is not listed in CISA KEV.
Privilege escalation in Gitea's self-hosted Git service (all versions ≤ 1.26.4) lets an attacker holding a narrowly-scoped Personal Access Token mint a new token with any scope, including full 'all' access, without the account password. The POST /users/{username}/tokens endpoint is guarded by reqBasicOrRevProxyAuth, which is meant to force password auth, but supplying the token as Authorization: Basic base64(<token>:x-oauth-basic) tricks the guard into setting IsBasicAuth=true, and the token-creation handler enforces no scope ceiling. A working proof-of-concept integration test is published in the advisory, though there is no public exploit identified in the wild and EPSS is low (0.16%).
Persistent account takeover in Gitea (self-hosted Git service) versions up to and including 1.26.4 arises because a stolen Remember-Me cookie is never revoked after theft is detected. When the split-token (ID:Hash) design detects a hash mismatch - the canonical signal of a compromised token per the Paragonie remember-me guidance - CheckAuthToken only returns ErrAuthTokenInvalidHash and autoSignIn merely clears the victim's local cookie, leaving the attacker's rotated token live in the database. The result is indefinite attacker access to the victim's account. Fixed in 1.27.0; no public exploit identified at time of analysis, and EPSS is low at 0.16%.
Authorization bypass in Gitea before 1.27.0 lets a public-only Personal Access Token read internal content owned by Limited-visibility users and organizations, exceeding the reach the scope is meant to grant. The Repository and Package scope categories only test repo.IsPrivate / Owner.Visibility.IsPrivate(), which return false for VisibleTypeLimited, so an authenticated attacker with a public-only PAT can fetch READMEs, repo content, packages from all 24 registries, and even perform full git-upload-pack clones of instance-internal projects. A vendor-verified end-to-end Docker PoC exists (publicly available exploit code exists); it is not in CISA KEV and EPSS is low at 0.17% (6th percentile). This is the residual gap left after CVE-2026-25714 / PR #37118 fixed the sibling User/Org/ActivityPub cases.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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 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 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 before 1.16.7 does not escape git fetch remote. Rated high severity (CVSS 7.5), this vulnerability is remotely exploitable, no authentication required, low attack complexity. Public exploit code available.
The git hook feature in Gitea 1.1.0 through 1.12.5 might allow for authenticated remote code execution in customer environments where the documentation was not understood (e.g., one viewpoint is that. Rated high severity (CVSS 7.2), this vulnerability is remotely exploitable, low attack complexity. Public exploit code available and no vendor patch available.
Remote code execution in Gitea (self-hosted Git service) via a code-injection flaw (CWE-94) allows attackers to run arbitrary code on the server, with the issue fixed in Gitea 1.27.1 (Alpine package 1.27.1-r0). The vulnerability is confirmed actively exploited (CISA KEV) and publicly available exploit code exists, including a Nuclei detection template and a proof-of-concept repository. With a CVSS 9.8 network/no-auth vector, any internet-exposed unpatched Gitea instance is at immediate, high risk of full compromise.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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 (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.
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.
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.
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).
Authenticated command injection in Dokploy (self-hostable PaaS) versions 0.29.3 through 0.29.12 lets a low-privileged user achieve arbitrary host command execution by storing a malicious Git branch value and triggering a deployment. The branch fields (customGitBranch, branch, gitlabBranch, bitbucketBranch, giteaBranch) were left without server-side validation because the earlier fix for CVE-2026-45628 was incomplete, so attacker-controlled input flows unescaped into shell-based git clone commands. No public exploit has been identified at time of analysis, but the flaw carries a CVSS of 9.9 and is fixed in 0.29.13.
SSRF protection bypass in Gitea prior to 1.27.0 exposes internal services, cloud instance-metadata endpoints (e.g., AWS IMDSv1 at 169.254.169.254), and local files - including the application configuration containing database credentials and signing secrets - to authenticated attackers. Three HTTP fetch code paths in the migration and OAuth avatar subsystems use Go's raw http.Get() rather than the hardened hostmatcher.NewDialContext() transport used elsewhere, completely circumventing Gitea's built-in SSRF defenses. A publicly available proof-of-concept is included in the GHSA advisory; no confirmed active exploitation (CISA KEV) has been identified at time of analysis.
Server-side request forgery in Gitea ≤1.26.4 allows privileged users to bypass the platform's own hostmatcher SSRF defenses via three unprotected raw http.Get() code paths in the migration and OAuth avatar subsystems, enabling retrieval of cloud instance metadata (AWS IMDSv1, GCP tokens), local file read (e.g., app.ini with database credentials and JWT secrets), and internal network scanning. A detailed proof-of-concept exploit is publicly available in the GitHub Security Advisory GHSA-2wm4-vwp6-v7xc. EPSS is low at 0.16% (6th percentile), consistent with the privilege requirements limiting opportunistic exploitation, but the disclosed PoC and the sensitivity of reachable data elevate real-world risk for cloud-hosted deployments. No active exploitation is confirmed in CISA KEV at time of analysis.
Private organization member enumeration in Gitea allows any authenticated user to retrieve the full member roster - including emails - of a private organization via the /api/v1/orgs/{org}/members endpoint. The root cause is an incomplete fix: PR #38145 added visibility guards to ListPublicMembers and IsPublicMember but omitted the same guard from ListMembers, leaving a single missing HasOrgOrUserVisible check in routers/api/v1/org/member.go. Proof-of-concept code is publicly available in the GitHub Security Advisory; no active exploitation has been confirmed in CISA KEV, and the EPSS score of 0.16% (5th percentile) indicates low probability of widespread automated exploitation.
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.
Unauthenticated denial of service in Gitea's Locale middleware allows any remote attacker to consume ~2 seconds of server CPU per HTTP request by crafting a ~1 MiB Accept-Language header composed of underscore separators, bypassing the existing CVE-2022-32149 guard in golang.org/x/text which only counts dash characters. All Gitea releases from 1.22.x through 1.26.x are affected because the middleware at modules/web/middleware/locale.go:38 passes the raw, unfiltered header directly to the quadratic-time ParseAcceptLanguage parser; ten concurrent attackers consuming ~10 MiB/s of upstream bandwidth can saturate all cores of a ten-core host indefinitely. Publicly available exploit code exists in the GHSA advisory; no active exploitation has been confirmed by CISA KEV at time of analysis.
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.
Identity-claim disclosure in Gitea (self-hosted Git server) before 1.27.0 lets any holder of a valid personal access token retrieve their email and organization/team membership from the OIDC userinfo endpoint (GET /login/oauth/userinfo) even when the token's scopes (e.g. only read:misc) would deny the equivalent REST API calls. The endpoint accepts API tokens as bearer credentials but skips the scope enforcement applied elsewhere, collapsing the authorization boundary that scoped tokens are meant to provide. Publicly available exploit code exists; the flaw is not in CISA KEV and EPSS is low (0.17%).
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 private organization membership through the `GET /orgs/{org}/public_members/{username}` endpoint, bypassing the visibility controls that correctly conceal this information in the web UI. All versions up to and including 1.26.4 are affected, permitting any user with a valid API token to confirm whether a specific user belongs to a hidden organization - data intentionally withheld from the web interface. No public exploit is confirmed in CISA KEV, though a detailed proof-of-concept with curl commands is documented in GHSA-jr5x-6h83-wrxf; EPSS stands at 0.16% (5th percentile), indicating low observed exploitation probability.
Gitea's Actions permission engine grants fork-PR task tokens unauthorized code-read access to third private repositories via a missing fork-PR discriminator in the collaborative-owner branch of `GetActionsUserRepoPermission`. All Gitea instances running versions up to and including 1.26.4 are affected when the collaborative-owner Actions feature is configured, as confirmed by vendor advisory GHSA-fj8v-hjwv-qm88 and EUVD-2026-58151. An attacker who has had at least one fork PR previously approved can exploit this to clone the full source of a private repository they were never authorized to access; impact is strictly read-only, with no write or code-execution capability. A functional PoC was included in the security advisory; this CVE is not in the CISA KEV catalog and no EPSS score was provided in the available data.
Broken authorization in Gitea (self-hosted Git server) versions before 1.27.0 lets a token scoped as public-only,write:repository push commits into a private pull-request head branch it should never touch. Because Gitea only evaluates the public-only restriction against the public base repository named in the route (POST /api/v1/repos/{owner}/{repo}/pulls/{index}/update) and never re-applies it to the private head repository, an attacker holding such a token can force a server-side write into the private repo and, where Actions is enabled, trigger its push workflow. This is CWE-863 incorrect authorization; a publicly available exploit code exists in the vendor advisory, EPSS is low at 0.24%, and it is not listed in CISA KEV.
Privilege escalation in Gitea's self-hosted Git service (all versions ≤ 1.26.4) lets an attacker holding a narrowly-scoped Personal Access Token mint a new token with any scope, including full 'all' access, without the account password. The POST /users/{username}/tokens endpoint is guarded by reqBasicOrRevProxyAuth, which is meant to force password auth, but supplying the token as Authorization: Basic base64(<token>:x-oauth-basic) tricks the guard into setting IsBasicAuth=true, and the token-creation handler enforces no scope ceiling. A working proof-of-concept integration test is published in the advisory, though there is no public exploit identified in the wild and EPSS is low (0.16%).
Persistent account takeover in Gitea (self-hosted Git service) versions up to and including 1.26.4 arises because a stolen Remember-Me cookie is never revoked after theft is detected. When the split-token (ID:Hash) design detects a hash mismatch - the canonical signal of a compromised token per the Paragonie remember-me guidance - CheckAuthToken only returns ErrAuthTokenInvalidHash and autoSignIn merely clears the victim's local cookie, leaving the attacker's rotated token live in the database. The result is indefinite attacker access to the victim's account. Fixed in 1.27.0; no public exploit identified at time of analysis, and EPSS is low at 0.16%.
Authorization bypass in Gitea before 1.27.0 lets a public-only Personal Access Token read internal content owned by Limited-visibility users and organizations, exceeding the reach the scope is meant to grant. The Repository and Package scope categories only test repo.IsPrivate / Owner.Visibility.IsPrivate(), which return false for VisibleTypeLimited, so an authenticated attacker with a public-only PAT can fetch READMEs, repo content, packages from all 24 registries, and even perform full git-upload-pack clones of instance-internal projects. A vendor-verified end-to-end Docker PoC exists (publicly available exploit code exists); it is not in CISA KEV and EPSS is low at 0.17% (6th percentile). This is the residual gap left after CVE-2026-25714 / PR #37118 fixed the sibling User/Org/ActivityPub cases.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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 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 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 before 1.16.7 does not escape git fetch remote. Rated high severity (CVSS 7.5), this vulnerability is remotely exploitable, no authentication required, low attack complexity. Public exploit code available.
The git hook feature in Gitea 1.1.0 through 1.12.5 might allow for authenticated remote code execution in customer environments where the documentation was not understood (e.g., one viewpoint is that. Rated high severity (CVSS 7.2), this vulnerability is remotely exploitable, low attack complexity. Public exploit code available and no vendor patch available.
Remote code execution in Gitea (self-hosted Git service) via a code-injection flaw (CWE-94) allows attackers to run arbitrary code on the server, with the issue fixed in Gitea 1.27.1 (Alpine package 1.27.1-r0). The vulnerability is confirmed actively exploited (CISA KEV) and publicly available exploit code exists, including a Nuclei detection template and a proof-of-concept repository. With a CVSS 9.8 network/no-auth vector, any internet-exposed unpatched Gitea instance is at immediate, high risk of full compromise.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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 (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.
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.
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.