Gitea
Monthly
Argument injection in Gitea's configurable external markup renderer lets a low-privilege authenticated user smuggle extra command-line arguments into the renderer process by way of attacker-influenced values (such as repository ref or branch names) that were substituted into the configured renderer command string before it was parsed, potentially yielding code execution and access to repository content at the renderer's privilege level. Only instances that have explicitly configured one or more external renderers in app.ini are exposed, and exploitation further depends on crafting input that survives the pre-fix string substitution, which is why the vendor-derived vector carries AC:H despite the high confidentiality and integrity impact. Fixed upstream in Gitea 1.27.2 and packaged for Alpine Linux as gitea 1.27.3-r0; no public exploit code has been identified at time of analysis and EPSS is low (0.26%, 16th percentile), so this is a conditional, patch-now issue rather than a mass-exploitation emergency.
Gitea, the self-hosted Git service, received a security fix in Alpine Linux package version 1.27.3-r0. The upstream Gitea version addressed is 1.27.3. No vulnerability description, CVSS score, CWE classification, or exploitation details are available from the provided intelligence sources, making independent impact assessment impossible at this time. Security teams running Gitea on Alpine Linux should treat this as a security-relevant update and upgrade promptly.
Missing per-user authorization middleware on seven Gitea API routes lets any authenticated account holding an API token with read-user scope enumerate the followers, following list, starred and watched repositories, and public SSH/GPG keys of individual users whose profile is set to 'limited' or 'private' visibility, which should otherwise be hidden from them. It affects Gitea up to and including 1.27.2 and is fixed in 1.27.3 and 28.0.0, with the disclosure shipped alongside the 28.2.0 release; exploitation requires a valid account and token (PR:L) and only works against non-public users, so the practical impact is moderate information disclosure rather than a critical exposure. There is no CISA KEV listing and no public exploit identified at time of analysis, and EPSS is 0.16% (5th percentile), consistent with a low-urgency bug that is nonetheless trivially scriptable once an account is obtained.
Incorrect authorization in Gitea's label-deletion logic lets an authenticated user with write access to a repository's issues delete issue labels belonging to an unrelated organization whose numeric ID happens to match that repository's ID. Exploitation requires the coincidental ID collision between a repository and an organization, cannot be chosen by the attacker, and yields only limited integrity impact (deleted labels) with no confidentiality or availability loss; Gitea instances through 28.1.0 are affected and 28.2.0 fixes the flaw. Risk is low: EPSS is 0.15% (4th percentile), SSVC marks exploitation as none and non-automatable, and no public exploit code was identified at time of analysis.
Gitea before 28.2.0 allows a user with write access to a repository's releases to link an existing issue or comment attachment into a release by supplying its UUID, because the release attachment-linking routine validated the repository and release association but not whether the attachment was already bound to an issue or comment. This exposes the attachment's file name, size and download count and lets the attacker rename or delete it. The flaw is limited to the same repository and requires knowledge of a non-enumerable UUID, and no public exploit or active exploitation has been identified at time of analysis (EPSS ~0.15%).
Authenticated users on a Gitea instance can harvest private-profile information - full name, location, website, and free-text description - from other accounts by sending requests to the POST /{username} follow and unfollow endpoint, because the profile visibility check was applied only to GET requests while the POST handler merely required a signed-in session. Anyone holding a valid account on Gitea 1.22.0 through 28.0.0 (self-registration, where enabled, is enough) can pull these fields from the response for any target whose profile visibility is set to private; public profiles expose nothing new. The vendor fixed the flaw in 28.1.0 and disclosed it alongside the 28.2.0 release; there is no public exploit code identified at time of analysis, it is not in CISA KEV, and EPSS is low at roughly 0.16% (4th percentile), so this is a genuine but modest-priority information-disclosure issue.
Information disclosure in Gitea 1.22.0 through 28.1.0 allows an authenticated low-privileged user who can create a draft release to obtain attachment metadata from repositories they cannot read, as well as metadata for abandoned uploads. The draft-release API path builds an assets list from an unsaved release whose ID is 0, causing the attachment lookup to return file name, UUID, upload time, size, and download count, but not attachment contents. CISA SSVC reports exploitation: none, no public exploit was identified at time of analysis, and EPSS is 0.16% (4th percentile).
Gitea leaks private repository metadata to users whose access has since been revoked: the GET /api/v1/user/subscriptions and /api/v1/user/starred endpoints returned name, description, clone URLs, owner and counters for every watched or starred private repo without re-checking current permissions, so a user who starred a private repo while authorized and later lost access (for example via a team permission downgrade or collaborator removal) could keep reading that metadata with an otherwise valid account. The flaw is fixed in 1.27.0 and 28.0.0 and was disclosed with 28.2.0; EPSS is only 0.15% (4th percentile), there is no KEV listing and no public exploit code identified at time of analysis, and the CVSS 4.3 vector (AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N) reflects that an attacker must already be authenticated and must previously have held legitimate access, with only metadata - not repository contents - exposed.
Signed-in Gitea users can bypass the interaction restriction of a locked issue by adding or removing emoji reactions on the issue and its comments through the web UI, even though they lack write access and the REST API correctly refuses the same operation. The gap affects Gitea through 28.1.0 and is limited to reaction toggling - no issue text, comment content, labels, or repository state can be altered - so the practical consequence is cosmetic noise and notification churn on issues maintainers deliberately froze. There is no public exploit identified at time of analysis, CISA SSVC records no known exploitation, and EPSS is 0.18% (7th percentile), consistent with a low-severity authorization inconsistency rather than a high-impact access-control failure; the vendor-released fix is Gitea 28.2.0.
Memory exhaustion in Gitea's Actions artifact v4 (Twirp) service lets an authenticated user who can run a workflow crash the server process by sending an oversized request body to the artifact handlers. The handlers called io.ReadAll on the request body without any size cap, so a single large POST from a run's runner token can consume all available memory and terminate the Gitea process, denying service to all users. The issue is rated CVSS 6.5 (availability-only, PR:L - authenticated, no user interaction), affects Gitea 1.22.0 through 28.1.0, and is fixed in 28.2.0; no public exploit code was identified and EPSS is only 0.16% (4th percentile), consistent with an SSVC assessment of no observed exploitation and low automatability.
Unauthenticated requests to Gitea's organization home route can trigger a nil-pointer panic and HTTP 500 when the path segment resolves to an individual user instead of an organization. The issue affects Gitea through 28.1.0 and is fixed in 28.2.0; it requires no authentication or special configuration, but each request causes only per-request availability degradation (error response and logged panic), not a full service crash. EPSS is 0.19% (8th percentile) and no public exploit has been identified at time of analysis.
Account takeover in Gitea 0 through 28.1.0 via the OpenID association callback, which accepts a positive OpenID 2.0 assertion without verifying that the signed-in victim initiated the linking. A remote unauthenticated attacker who controls an OpenID provider can trick a signed-in user into opening a crafted link, link the attacker's identity to the victim's account, and then sign in as the victim through OpenID login, bypassing local TOTP/WebAuthn checks. Exploitation requires OpenID login/association to be enabled and user interaction; no public exploit code has been identified, EPSS is 0.11% (1st percentile), and the vendor has released Gitea 28.2.0 to fix it.
Gitea instances that have OpenID sign-in enabled can be coerced into sending an outbound HTTP POST to an attacker-chosen OpenID provider endpoint, letting the attacker use the server as a blind SSRF proxy into internal networks. The vulnerability affects Gitea 0 through 1.26.4 and requires no authentication or user interaction (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N, 5.3), but exploitation is gated on the non-default OpenID feature being explicitly turned on, and because the response is never returned to the attacker the impact is limited to the reachability and side effects of internal HTTP services. Multiple signals converge on this being a genuine but moderate-priority issue rather than an emergency: EPSS is only 0.17% (6th percentile), there is no CISA KEV designation, and no public exploit code was identified at time of analysis.
Server-side request forgery in Gitea lets an unauthenticated remote attacker cause the server to contact loopback or private-network HTTP services by supplying a crafted OpenID URL when OpenID sign-in is enabled. Affected deployments are vulnerable Gitea releases such as 1.25.4 (CPE wildcard all versions) that have deliberately enabled ENABLE_OPENID_SIGNIN and lack destination restrictions; the vendor patch changes that setting to default false and adds a built-in blocklist for localhost, loopback, private ranges, and IPv6 link-local addresses. Publicly available exploit code exists and the issue is automatable, but no CISA KEV active-exploitation confirmation is present, and the assessed CVSS is 5.3 with only low confidentiality impact.
Gitea through 28.0.0 fails to apply profile visibility checks when a profile page is requested through content negotiation, allowing unauthenticated remote attackers to confirm the existence of limited or private users and private organizations and to read their profile details and public activity feed. A simple GET request to /{username} carrying an 'Accept: application/rss+xml' or 'Accept: application/atom+xml' header bypasses the checks used by the normal profile page and the explicit .rss/.atom routes, and the bypass also works when the '[other] ENABLE_FEED' setting is turned off; activity in private repositories is not disclosed. There is no public exploit code and no indication of active exploitation (EPSS 0.15%, 3rd percentile), so real-world risk is low, and the issue is fixed in Gitea 28.1.0.
Gitea versions through 28.0.0 allow repository administrators to create new push mirrors through the API even when the site administrator has enabled the [mirror] DISABLE_NEW_PUSH restriction that the web UI honors. This is an authenticated, repository-admin-only authorization bypass (CVSS PR:H) that only crosses the intended security boundary on instances where that restriction is configured; on default configurations push mirrors are permitted, so the API behavior is not a violation. EPSS is 0.16% (5th percentile), no public exploit identified at time of analysis, and no CISA KEV activity is reported; the vendor fixed the issue in 28.1.0. The independent assessment rates this as a genuinely low-priority issue with assessed vector CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:L/I:N/A:N.
Stored cross-site scripting in Gitea's raw media API endpoint (GET /api/v1/repos/{owner}/{repo}/media/{filepath}) lets an authenticated user with push access to a repository have HTML files of up to 1 KiB rendered by the browser on the Gitea origin, executing JavaScript in the session of any victim who opens the media URL and acting with that victim's permissions. The flaw affects Gitea versions up to and including 28.0.0 and arises because the handler in routers/api/v1/repo/file.go wrote non-LFS file content directly to the HTTP response without the content-type and content-disposition headers Gitea normally applies to user-supplied content. Exploitation requires prior repository write access and mandatory victim interaction (the target must open the crafted media URL while authenticated), and a vendor fix is available in Gitea 28.1.0. EPSS is low at 0.17% (6th percentile), CISA SSVC records no observed exploitation and no automatable exploitation path, and no public exploit code was identified at time of analysis.
Gitea instances configured with the non-default setting `[repository] FORCE_PRIVATE = true` can be made to host public repositories in violation of that instance-wide policy: an authenticated user with repository-creation rights who creates a repository via git push can supply the `repo.private=false` push option and have it honored on the freshly created empty repository. Only versions 1.27.0 through 28.0.0 are affected, the default configuration is explicitly not exposed, and the exposure is limited to a confidentiality/integrity policy bypass (CVSS 5.4, PR:L) rather than code execution or data theft. No public exploit code has been identified at time of analysis, and there is no CISA KEV listing; the issue is a genuine but modest-priority authorization-logic defect that matters most to operators who deliberately enforce repository privacy by policy.
Authorization bypass in Gitea's issue attachment API (CVE-2026-105268) lets an authenticated user who authored an issue rename or delete attachments that other users posted in comments on that same issue, because the endpoint `/api/v1/repos/{owner}/{repo}/issues/{index}/assets/{attachment_id}` failed to exclude comment-owned attachments from the set the issue author is allowed to manage. Only metadata operations (rename/delete) are possible - attachment contents cannot be altered (C:N), and no data outside the attacker's own repository scope is reachable. Rated CVSS 4.3 (AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N) with an EPSS of 0.15% (3rd percentile) and an SSVC assessment of Exploitation:none / Automatable:no / Technical Impact:partial, so no public exploit was identified at time of analysis; this is a low-priority integrity/data-destruction defect, not a confidentiality or code-execution issue.
Repository migration in Gitea through 28.0.0 can be driven into an unbounded paginated download loop that consumes server memory until exhaustion, denying service to other users. The flaw is reachable by an authenticated user holding repository-migration rights (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H) who directs a migration at a source server they control and that reports max_response_items as 0, which Gitea treats as the loop's termination condition. Exploitation is not known to be active - no public exploit code identified at time of analysis - and EPSS is low at 0.17% (5th percentile), making this a genuine but moderate-priority availability issue; a vendor-released patch exists in Gitea 28.1.0.
Gitea through 1.27.3 grants the named recipient of a private-repository transfer temporary read collaborator access so they can review the repository, but rejecting or cancelling that transfer never revokes the collaboration, leaving the recipient with persistent read access to the private repository's code, issues, pull requests and wiki, including the ability to clone it, without any notification to the repository owner. Exploitation requires the repository owner to initiate a transfer of a private repository to a specific authenticated Gitea user who lacks prior access, and the affected party is that designated recipient rather than an arbitrary user; it is not attacker-initiated against default configurations. Severity is moderate (assessed CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N; published base score 4.3) with no public exploit identified at time of analysis and a low EPSS of 0.27% (17th percentile). Vendor-released patch: Gitea 28.0.0.
Server-side request forgery in Gitea's repository migration feature lets an authenticated user who is permitted to start migrations force the Gitea server to connect to reserved or link-local addresses, including the cloud metadata endpoint 169.254.169.254. The flaw only manifests in a non-default configuration where the administrator has set [migrations] ALLOWED_DOMAINS to a wildcard such as `*` or a hostname wildcard, which bypasses the intended ALLOW_LOCALNETWORKS = false protection because the local-network block list omitted reserved/link-local ranges and hostname allow-list matching was accepted irrespective of the resolved IP. Impact is bounded to reachability and read-style access from the server (no code execution or data modification), authentication is required per the CVSS vector (PR:L), and no public exploit has been identified at time of analysis, so this is a low-to-moderate priority issue whose real-world severity rises mainly where a reachable instance metadata service exists on the Gitea host.
Algorithmic complexity denial-of-service in Gitea 1.27.3 and earlier allows an authenticated user with permission to create issues or post comments to stall a server process by submitting a crafted ~1 MB body containing many Markdown links, keeping a CPU core busy for minutes while holding a database transaction open. The flaw is a quadratic rescan of preceding text for close/reopen keywords such as "closes" or "fixes" performed once per link (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H, score 6.5). It is authentication-gated and no public exploit code has been identified at time of analysis; EPSS is low at 0.16% (4th percentile) and CISA SSVC records Exploitation: none.
Stored cross-site scripting in the Gitea container registry (versions through 1.27.3) lets any user with permission to push container images publish a blob whose manifest declares a text/html media type, which Gitea then serves back verbatim as the blob's Content-Type with no Content-Disposition header and no restrictive Content-Security-Policy - so the embedded JavaScript executes on the Gitea origin when an authenticated victim opens the blob URL. Impact is bounded but real: the attacker must already hold registry push rights and the victim must be induced to open the crafted URL directly, but success allows same-origin actions as the victim such as creating API tokens. The flaw is rated 5.4 (CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:L/I:L/A:N), carries EPSS 0.18% (7th percentile), shows CISA SSVC exploitation of 'none', and has no public exploit identified at time of analysis; exploitation requires an account with image-push permission (authenticated, PR:L) and victim interaction (UI:R).
Authenticated low-privileged users on self-hosted Gitea through 1.27.3 can bypass the repository migration and pull-mirror egress checks by supplying a hostname with multiple DNS answers, so the address Gitea validates is not necessarily the address Git later connects to. This lets an attacker with migration or mirror creation rights reach internal Git or HTTP endpoints on the server's network, with limited read and write impact (assessed CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:L/I:L/A:N), and internal response content may additionally leak through migration and mirror error messages (CWE-209). Exploitation is non-deterministic and depends on winning a multi-answer DNS race plus a reachable internal target, and no public exploit code was identified at time of analysis; EPSS is 0.12% (2nd percentile), CISA SSVC rates exploitation as none and the issue as not automatable.
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.
Insecure direct object reference (IDOR) in Gitea's issue time-tracking feature allows authenticated users to delete tracked-time entries belonging to issues other than the one specified in the request URL. Affected are all Gitea Open Source Git Server versions before 1.25.5. The root cause is that `GetTrackedTimeByID` performed a database lookup using only the time entry's numeric ID, without filtering by the issue ID present in the URL path, enabling cross-issue data manipulation. No public exploit has been identified at time of analysis, and CISA KEV does not list this vulnerability.
Unauthorized read access to tracked time entries in Gitea before 1.25.5 exposes private repository metadata to unauthenticated network actors due to missing repository-level permission checks during API serialization (CWE-284). The flaw exists in the `ToStopWatches` and `ToTrackedTimeList` conversion functions in `services/convert/issue.go`, which iterated over and returned time entries without verifying the requesting user held read access to the underlying repository. No public exploit has been identified and CISA has not added this to KEV; however, the SSVC assessment designates the flaw as automatable, meaning it can be scripted at scale against all exposed Gitea instances running affected versions.
Open redirect in Gitea's login flow allows external domain hijacking by bypassing the `urlIsRelative` validation in `modules/httplib/url.go` through a combination of directory traversal sequences and a backslash in the `redirect_to` parameter. All Gitea instances running version 1.25.4 and below are affected; a working proof-of-concept is publicly available in the GitHub Security Advisory. Exploitation enables phishing via trusted Gitea domains, OAuth/SSO authorization code theft, Referer-header leakage of sensitive parameters, and potential cache poisoning — no public exploit identified as confirmed actively exploited (CISA KEV absent).
Missing repository-unit authorization on three Gitea API endpoints allows authenticated users with only non-Code unit access (e.g., an Issues-only organization team member) to read `.gitea/ISSUE_TEMPLATE/*` and `issue_config.yaml` files from the Code default branch of a private repository. The CVSS score of 4.3 (PR:L, C:L) accurately reflects the narrow scope: exploitation is limited to those specific configuration files, not arbitrary source code. A proof of concept is publicly documented in the vendor advisory (GHSA-3fwp-p5rj-2pxf); no active exploitation is confirmed in the CISA KEV catalog at time of analysis.
Public-only scoped API tokens in Gitea bypass their declared scope constraints and expose private organization membership data through two distinct code defects in `routers/api/v1/api.go`: the `/user/orgs` route omits the `checkTokenPublicOnly()` middleware entirely, and the `checkTokenPublicOnly` function contains a Go switch-case logic flaw that skips the user-visibility check on multi-category routes. This is an incomplete remediation of CVE-2025-68941 introduced by PR #32204, affecting all Gitea instances running version 1.26.1 and earlier. No public exploit code or active exploitation (CISA KEV) has been identified at time of analysis, but the attack is trivially reproducible from the published advisory steps.
Gitea's OpenID URI visibility controls lack proper ownership validation, allowing authenticated users to modify the visibility settings of other users' OpenID identities. This integrity bypass affects any Gitea instance where multiple users manage OpenID configurations, enabling account enumeration or information disclosure through unauthorized visibility changes. A patch is available to remediate this medium-severity vulnerability.
Gitea fails to enforce proper authorization checks when users attempt to cancel scheduled auto-merges through the web interface, allowing any user with pull request read access to cancel merge operations initiated by other users. This authorization bypass could disrupt automated workflows and merge processes across repositories. A patch is available to address this vulnerability.
Gitea's stopwatch API fails to re-validate repository access permissions, allowing revoked users to access sensitive information through active stopwatch sessions. An authenticated attacker with prior access to a private repository can enumerate issue titles and repository names even after their permissions have been removed. A patch is available to enforce proper access control validation.
Gitea's notification API fails to re-validate repository access permissions when retrieving notification details, allowing users with revoked access to private repositories to continue viewing issue and pull request titles through cached notifications. An authenticated attacker can exploit this to maintain visibility into sensitive repository content after their access has been removed. A patch is available.
Gitea may send release notification emails for private repositories to users whose access has been revoked. [CVSS 3.5 LOW]
In Gitea before 1.25.2, /api/v1/user has different responses for failed authentication depending on whether a username exists. [CVSS 5.3 MEDIUM]
Stored cross-site scripting in Gitea before 1.20.1 allows an attacker with a low-privilege account to embed links using forbidden URL schemes - notably javascript:, and by extension vbscript: and data: - in user-generated Markdown such as issues, comments, pull request descriptions, wiki pages, or repository files; when a victim clicks the crafted link, script executes in the context of the Gitea instance. The vulnerability carries a moderate CVSS of 5.4 (AV:N/AC:L/PR:L/UI:R/S:C/C:L/I:L/A:N) and requires victim interaction, with authentication requirements not confirmed as unauthenticated - the assessed vector (PR:L) indicates an authenticated, low-privilege attacker. No public exploit code or confirmed active exploitation was identified at time of analysis, and EPSS is low at 0.25% (15th percentile); a vendor fix is available in Gitea 1.20.1.
Unauthenticated information disclosure in Gitea before 1.21.2 lets an anonymous remote visitor view the projects page of a private (or otherwise non-public) individual user account. Per the CVSS vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N, exploitation requires no authentication and no user interaction: a single anonymous HTTP GET to a route such as /{user}/-/projects returns data that should be restricted, because individual user permissions were never checked after org assignment. Impact is limited to confidentiality (C:L) with no integrity or availability effect; EPSS is 0.36% (27th percentile) and no public exploit has been identified at time of analysis, and the issue is fixed in 1.21.2 (Vendor-released patch: 1.21.2), which returns HTTP 404 to anonymous and non-owner, non-admin requesters.
Gitea before 1.22.2 improperly validates access token scopes in its Conan, Container, and NuGet package registries, allowing an authenticated attacker who holds a valid token lacking package permissions to obtain a package authorization token and perform unauthorized read/write operations on packages (confused deputy, CWE-441). The flaw requires the attacker to already possess a valid Gitea access token and only affects instances where package registries are enabled; it does not enable anonymous access or full repository compromise. No public exploit code or active exploitation has been identified, and with an EPSS of 0.28% (18th percentile), the real-world priority is low.
Gitea instances running versions before 1.21.8 expose users' last-login timestamps to anyone who can reach the public explore listings, because the /explore/users endpoint accepted sort values such as lastlogin and reverselastlogin (and activity-leaking variants like leastupdate and reverseleastupdate) that were never intended to be user-selectable. The issue is network-reachable, requires no authentication and no user interaction (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N, CVSS 5.3, CWE-497), and the only impact is limited confidentiality loss - no credentials, repository content, or state modification is exposed. No public exploit code has been identified at time of analysis and the CVE is not in CISA KEV; EPSS is low at 0.36% (27th percentile), consistent with a low-value reconnaissance/enumeration bug rather than an active campaign. Exploitation simply requires issuing a crafted sort query parameter against an instance whose explore pages are publicly accessible or reachable from an internal network.
Authenticated cross-site scripting (XSS) in Gitea before 1.22.2 allows a user with repository branch/tag creation access to inject HTML through a crafted search term that is rendered with v-html in the RepoBranchTagSelector component; a victim must view or interact with the resulting prompt (UI:R). The issue is a moderate-severity CWE-79 flaw confirmed by an upstream patch, with EPSS 0.25% (15th percentile) and no public exploit identified at time of analysis, so it is a genuine but not urgent risk.
Broken authorization in Gitea before 1.22.3 causes API tokens scoped only to public resources to be honored when the request targets private resources, allowing an authenticated holder of such a token to read private repositories, organizations, users, packages, issues, notifications, and ActivityPub data. The attacker must already possess a valid Gitea API access token whose scope is explicitly limited to public resources (e.g., public-only repository, issue, organization, user, package, notification, or ActivityPub scopes) and must point it at a private resource on the same instance, so this is an authenticated privilege-scope bypass rather than an anonymous exposure. Impact is confined to read-only information disclosure with no integrity or availability effect; EPSS is 0.26% (17th percentile) and no public exploit code has been identified at time of analysis.
Gitea before 1.22.5 allows an authenticated user with pull-request merge rights to delete the pull request head branch without branch-deletion permission when merging with the delete-branch-after-merge option. This is a CWE-863 incorrect authorization flaw that is assessed as a modest-severity, low-priority issue: it can cause unauthorized branch removal but does not grant code execution or data disclosure, applies only to the PR head branch, and does not affect agit-flow references. The EPSS score is low at 0.27 percent (18th percentile), no public exploit identified at time of analysis, and the vendor released a patch in Gitea 1.22.5.
Gitea deployments running releases before 1.23.0 let an authenticated user who holds rights to modify an existing issue, comment, or release attachment rename that attachment to a forbidden file extension, bypassing the instance's configured AllowedTypes allow-list. Because the extension/type check was enforced only on the upload path and not on the attachment-name update path, an attacker can first upload a permitted file and then rename it through the attachment API (the issue, issue-comment, or release asset endpoints), causing Gitea to store and serve a file type that the operator intended to block. The fix in 1.23.0 routes renames through the same verification service and returns HTTP 422 for a forbidden extension. Exploitation requires API access plus attachment-management privileges rather than fully anonymous access, only matters where administrators actually rely on AllowedTypes to restrict extensions (default AllowedTypes is unrestricted in many deployments), and the outcome is storing/serving a disallowed file type rather than server-side code execution. EPSS is 0.33% (24th percentile) and no public exploit has been identified at time of analysis.
Authorization bypass in Gitea before 1.25.2 allows a user without proper release-management permission on a repository to delete releases, resulting in loss of release data. The flaw is a medium-severity incorrect authorization issue (CWE-863, CVSS 5.3) with a low EPSS score of 0.38% (30th percentile); no public exploit code or confirmed active exploitation has been identified. Exploitation requires a valid Gitea account and API/web access to the target repository, and impact is limited to release deletion for repositories reachable by that account.
Improper Neutralization of Input During Web Page Generation (XSS or 'Cross-site Scripting') vulnerability in Gitea Gitea Open Source Git Server allows Stored XSS.22.0. Rated critical severity (CVSS 10.0), this vulnerability is remotely exploitable, no authentication required, low attack complexity. No vendor patch available.
Open Redirect in GitHub repository go-gitea/gitea prior to 1.19.4. Rated medium severity (CVSS 4.4), this vulnerability is remotely exploitable. Public exploit code available.
In Jenkins Gitea Plugin 1.4.4 and earlier, the implementation of Gitea personal access tokens did not support credentials masking, potentially exposing them through the build log. Rated medium severity (CVSS 4.3), this vulnerability is remotely exploitable, low attack complexity. No vendor patch available.
Gitea before 1.17.3 does not sanitize and escape refs in the git backend. Rated critical severity (CVSS 9.8), this vulnerability is remotely exploitable, no authentication required, low attack complexity.
In Gitea before 1.16.9, it was possible for users to add existing issues to projects. Rated medium severity (CVSS 6.5), this vulnerability is remotely exploitable, low attack complexity. No vendor patch available.
Cross-site Scripting (XSS) - Stored in GitHub repository go-gitea/gitea prior to 1.16.9. Rated medium severity (CVSS 5.4), this vulnerability is remotely exploitable, low attack complexity. Public exploit code available.
An arbitrary file deletion vulnerability in Gitea v1.16.3 allows attackers to cause a Denial of Service (DoS) via deleting the configuration file. Rated high severity (CVSS 7.5), this vulnerability is remotely exploitable, no authentication required, low attack complexity.
Open Redirect on login in GitHub repository go-gitea/gitea prior to 1.16.5. Rated medium severity (CVSS 6.1), this vulnerability is remotely exploitable, no authentication required, low attack complexity. Public exploit code available.
Missing Authorization in GitHub repository go-gitea/gitea prior to 1.16.4. Rated high severity (CVSS 7.1), this vulnerability is remotely exploitable, low attack complexity. Public exploit code available.
In all versions of GitLab CE/EE since version 8.15, a DNS rebinding vulnerability in Gitea Importer may be exploited by an attacker to trigger Server Side Request Forgery (SSRF) attacks. Rated high severity (CVSS 8.1), this vulnerability is remotely exploitable, low attack complexity. No vendor patch available.
Gitea 1.12.x and 1.13.x before 1.13.4 allows XSS via certain issue data in some situations. Rated medium severity (CVSS 5.4), this vulnerability is remotely exploitable, low attack complexity. Public exploit code available.
Stack buffer overflow vulnerability in gitea 1.9.0 through 1.13.1 allows remote attackers to cause a denial of service (crash) via vectors related to a file path. Rated high severity (CVSS 7.5), this vulnerability is remotely exploitable, no authentication required, low attack complexity. No vendor patch available.
Gitea 0.9.99 through 1.12.x before 1.12.6 does not prevent a git protocol path that specifies a TCP port number and also contains newlines (with URL encoding) in ParseRemoteAddr in. Rated critical severity (CVSS 9.8), this vulnerability is remotely exploitable, no authentication required, low attack complexity.
An issue was discovered in Gitea through 1.11.5. Rated high severity (CVSS 7.5), this vulnerability is remotely exploitable, no authentication required, low attack complexity. Public exploit code available.
Gitea 1.7.0 and earlier is affected by: Cross Site Scripting (XSS). Rated medium severity (CVSS 6.1), this vulnerability is remotely exploitable, no authentication required, low attack complexity. This Cross-Site Scripting (XSS) vulnerability could allow attackers to inject malicious scripts into web pages viewed by other users.
Gitea 1.7.2, 1.7.3 is affected by: Cross Site Scripting (XSS). Rated medium severity (CVSS 6.1), this vulnerability is remotely exploitable, no authentication required, low attack complexity. No vendor patch available.
Argument injection in Gitea's configurable external markup renderer lets a low-privilege authenticated user smuggle extra command-line arguments into the renderer process by way of attacker-influenced values (such as repository ref or branch names) that were substituted into the configured renderer command string before it was parsed, potentially yielding code execution and access to repository content at the renderer's privilege level. Only instances that have explicitly configured one or more external renderers in app.ini are exposed, and exploitation further depends on crafting input that survives the pre-fix string substitution, which is why the vendor-derived vector carries AC:H despite the high confidentiality and integrity impact. Fixed upstream in Gitea 1.27.2 and packaged for Alpine Linux as gitea 1.27.3-r0; no public exploit code has been identified at time of analysis and EPSS is low (0.26%, 16th percentile), so this is a conditional, patch-now issue rather than a mass-exploitation emergency.
Gitea, the self-hosted Git service, received a security fix in Alpine Linux package version 1.27.3-r0. The upstream Gitea version addressed is 1.27.3. No vulnerability description, CVSS score, CWE classification, or exploitation details are available from the provided intelligence sources, making independent impact assessment impossible at this time. Security teams running Gitea on Alpine Linux should treat this as a security-relevant update and upgrade promptly.
Missing per-user authorization middleware on seven Gitea API routes lets any authenticated account holding an API token with read-user scope enumerate the followers, following list, starred and watched repositories, and public SSH/GPG keys of individual users whose profile is set to 'limited' or 'private' visibility, which should otherwise be hidden from them. It affects Gitea up to and including 1.27.2 and is fixed in 1.27.3 and 28.0.0, with the disclosure shipped alongside the 28.2.0 release; exploitation requires a valid account and token (PR:L) and only works against non-public users, so the practical impact is moderate information disclosure rather than a critical exposure. There is no CISA KEV listing and no public exploit identified at time of analysis, and EPSS is 0.16% (5th percentile), consistent with a low-urgency bug that is nonetheless trivially scriptable once an account is obtained.
Incorrect authorization in Gitea's label-deletion logic lets an authenticated user with write access to a repository's issues delete issue labels belonging to an unrelated organization whose numeric ID happens to match that repository's ID. Exploitation requires the coincidental ID collision between a repository and an organization, cannot be chosen by the attacker, and yields only limited integrity impact (deleted labels) with no confidentiality or availability loss; Gitea instances through 28.1.0 are affected and 28.2.0 fixes the flaw. Risk is low: EPSS is 0.15% (4th percentile), SSVC marks exploitation as none and non-automatable, and no public exploit code was identified at time of analysis.
Gitea before 28.2.0 allows a user with write access to a repository's releases to link an existing issue or comment attachment into a release by supplying its UUID, because the release attachment-linking routine validated the repository and release association but not whether the attachment was already bound to an issue or comment. This exposes the attachment's file name, size and download count and lets the attacker rename or delete it. The flaw is limited to the same repository and requires knowledge of a non-enumerable UUID, and no public exploit or active exploitation has been identified at time of analysis (EPSS ~0.15%).
Authenticated users on a Gitea instance can harvest private-profile information - full name, location, website, and free-text description - from other accounts by sending requests to the POST /{username} follow and unfollow endpoint, because the profile visibility check was applied only to GET requests while the POST handler merely required a signed-in session. Anyone holding a valid account on Gitea 1.22.0 through 28.0.0 (self-registration, where enabled, is enough) can pull these fields from the response for any target whose profile visibility is set to private; public profiles expose nothing new. The vendor fixed the flaw in 28.1.0 and disclosed it alongside the 28.2.0 release; there is no public exploit code identified at time of analysis, it is not in CISA KEV, and EPSS is low at roughly 0.16% (4th percentile), so this is a genuine but modest-priority information-disclosure issue.
Information disclosure in Gitea 1.22.0 through 28.1.0 allows an authenticated low-privileged user who can create a draft release to obtain attachment metadata from repositories they cannot read, as well as metadata for abandoned uploads. The draft-release API path builds an assets list from an unsaved release whose ID is 0, causing the attachment lookup to return file name, UUID, upload time, size, and download count, but not attachment contents. CISA SSVC reports exploitation: none, no public exploit was identified at time of analysis, and EPSS is 0.16% (4th percentile).
Gitea leaks private repository metadata to users whose access has since been revoked: the GET /api/v1/user/subscriptions and /api/v1/user/starred endpoints returned name, description, clone URLs, owner and counters for every watched or starred private repo without re-checking current permissions, so a user who starred a private repo while authorized and later lost access (for example via a team permission downgrade or collaborator removal) could keep reading that metadata with an otherwise valid account. The flaw is fixed in 1.27.0 and 28.0.0 and was disclosed with 28.2.0; EPSS is only 0.15% (4th percentile), there is no KEV listing and no public exploit code identified at time of analysis, and the CVSS 4.3 vector (AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N) reflects that an attacker must already be authenticated and must previously have held legitimate access, with only metadata - not repository contents - exposed.
Signed-in Gitea users can bypass the interaction restriction of a locked issue by adding or removing emoji reactions on the issue and its comments through the web UI, even though they lack write access and the REST API correctly refuses the same operation. The gap affects Gitea through 28.1.0 and is limited to reaction toggling - no issue text, comment content, labels, or repository state can be altered - so the practical consequence is cosmetic noise and notification churn on issues maintainers deliberately froze. There is no public exploit identified at time of analysis, CISA SSVC records no known exploitation, and EPSS is 0.18% (7th percentile), consistent with a low-severity authorization inconsistency rather than a high-impact access-control failure; the vendor-released fix is Gitea 28.2.0.
Memory exhaustion in Gitea's Actions artifact v4 (Twirp) service lets an authenticated user who can run a workflow crash the server process by sending an oversized request body to the artifact handlers. The handlers called io.ReadAll on the request body without any size cap, so a single large POST from a run's runner token can consume all available memory and terminate the Gitea process, denying service to all users. The issue is rated CVSS 6.5 (availability-only, PR:L - authenticated, no user interaction), affects Gitea 1.22.0 through 28.1.0, and is fixed in 28.2.0; no public exploit code was identified and EPSS is only 0.16% (4th percentile), consistent with an SSVC assessment of no observed exploitation and low automatability.
Unauthenticated requests to Gitea's organization home route can trigger a nil-pointer panic and HTTP 500 when the path segment resolves to an individual user instead of an organization. The issue affects Gitea through 28.1.0 and is fixed in 28.2.0; it requires no authentication or special configuration, but each request causes only per-request availability degradation (error response and logged panic), not a full service crash. EPSS is 0.19% (8th percentile) and no public exploit has been identified at time of analysis.
Account takeover in Gitea 0 through 28.1.0 via the OpenID association callback, which accepts a positive OpenID 2.0 assertion without verifying that the signed-in victim initiated the linking. A remote unauthenticated attacker who controls an OpenID provider can trick a signed-in user into opening a crafted link, link the attacker's identity to the victim's account, and then sign in as the victim through OpenID login, bypassing local TOTP/WebAuthn checks. Exploitation requires OpenID login/association to be enabled and user interaction; no public exploit code has been identified, EPSS is 0.11% (1st percentile), and the vendor has released Gitea 28.2.0 to fix it.
Gitea instances that have OpenID sign-in enabled can be coerced into sending an outbound HTTP POST to an attacker-chosen OpenID provider endpoint, letting the attacker use the server as a blind SSRF proxy into internal networks. The vulnerability affects Gitea 0 through 1.26.4 and requires no authentication or user interaction (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N, 5.3), but exploitation is gated on the non-default OpenID feature being explicitly turned on, and because the response is never returned to the attacker the impact is limited to the reachability and side effects of internal HTTP services. Multiple signals converge on this being a genuine but moderate-priority issue rather than an emergency: EPSS is only 0.17% (6th percentile), there is no CISA KEV designation, and no public exploit code was identified at time of analysis.
Server-side request forgery in Gitea lets an unauthenticated remote attacker cause the server to contact loopback or private-network HTTP services by supplying a crafted OpenID URL when OpenID sign-in is enabled. Affected deployments are vulnerable Gitea releases such as 1.25.4 (CPE wildcard all versions) that have deliberately enabled ENABLE_OPENID_SIGNIN and lack destination restrictions; the vendor patch changes that setting to default false and adds a built-in blocklist for localhost, loopback, private ranges, and IPv6 link-local addresses. Publicly available exploit code exists and the issue is automatable, but no CISA KEV active-exploitation confirmation is present, and the assessed CVSS is 5.3 with only low confidentiality impact.
Gitea through 28.0.0 fails to apply profile visibility checks when a profile page is requested through content negotiation, allowing unauthenticated remote attackers to confirm the existence of limited or private users and private organizations and to read their profile details and public activity feed. A simple GET request to /{username} carrying an 'Accept: application/rss+xml' or 'Accept: application/atom+xml' header bypasses the checks used by the normal profile page and the explicit .rss/.atom routes, and the bypass also works when the '[other] ENABLE_FEED' setting is turned off; activity in private repositories is not disclosed. There is no public exploit code and no indication of active exploitation (EPSS 0.15%, 3rd percentile), so real-world risk is low, and the issue is fixed in Gitea 28.1.0.
Gitea versions through 28.0.0 allow repository administrators to create new push mirrors through the API even when the site administrator has enabled the [mirror] DISABLE_NEW_PUSH restriction that the web UI honors. This is an authenticated, repository-admin-only authorization bypass (CVSS PR:H) that only crosses the intended security boundary on instances where that restriction is configured; on default configurations push mirrors are permitted, so the API behavior is not a violation. EPSS is 0.16% (5th percentile), no public exploit identified at time of analysis, and no CISA KEV activity is reported; the vendor fixed the issue in 28.1.0. The independent assessment rates this as a genuinely low-priority issue with assessed vector CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:L/I:N/A:N.
Stored cross-site scripting in Gitea's raw media API endpoint (GET /api/v1/repos/{owner}/{repo}/media/{filepath}) lets an authenticated user with push access to a repository have HTML files of up to 1 KiB rendered by the browser on the Gitea origin, executing JavaScript in the session of any victim who opens the media URL and acting with that victim's permissions. The flaw affects Gitea versions up to and including 28.0.0 and arises because the handler in routers/api/v1/repo/file.go wrote non-LFS file content directly to the HTTP response without the content-type and content-disposition headers Gitea normally applies to user-supplied content. Exploitation requires prior repository write access and mandatory victim interaction (the target must open the crafted media URL while authenticated), and a vendor fix is available in Gitea 28.1.0. EPSS is low at 0.17% (6th percentile), CISA SSVC records no observed exploitation and no automatable exploitation path, and no public exploit code was identified at time of analysis.
Gitea instances configured with the non-default setting `[repository] FORCE_PRIVATE = true` can be made to host public repositories in violation of that instance-wide policy: an authenticated user with repository-creation rights who creates a repository via git push can supply the `repo.private=false` push option and have it honored on the freshly created empty repository. Only versions 1.27.0 through 28.0.0 are affected, the default configuration is explicitly not exposed, and the exposure is limited to a confidentiality/integrity policy bypass (CVSS 5.4, PR:L) rather than code execution or data theft. No public exploit code has been identified at time of analysis, and there is no CISA KEV listing; the issue is a genuine but modest-priority authorization-logic defect that matters most to operators who deliberately enforce repository privacy by policy.
Authorization bypass in Gitea's issue attachment API (CVE-2026-105268) lets an authenticated user who authored an issue rename or delete attachments that other users posted in comments on that same issue, because the endpoint `/api/v1/repos/{owner}/{repo}/issues/{index}/assets/{attachment_id}` failed to exclude comment-owned attachments from the set the issue author is allowed to manage. Only metadata operations (rename/delete) are possible - attachment contents cannot be altered (C:N), and no data outside the attacker's own repository scope is reachable. Rated CVSS 4.3 (AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N) with an EPSS of 0.15% (3rd percentile) and an SSVC assessment of Exploitation:none / Automatable:no / Technical Impact:partial, so no public exploit was identified at time of analysis; this is a low-priority integrity/data-destruction defect, not a confidentiality or code-execution issue.
Repository migration in Gitea through 28.0.0 can be driven into an unbounded paginated download loop that consumes server memory until exhaustion, denying service to other users. The flaw is reachable by an authenticated user holding repository-migration rights (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H) who directs a migration at a source server they control and that reports max_response_items as 0, which Gitea treats as the loop's termination condition. Exploitation is not known to be active - no public exploit code identified at time of analysis - and EPSS is low at 0.17% (5th percentile), making this a genuine but moderate-priority availability issue; a vendor-released patch exists in Gitea 28.1.0.
Gitea through 1.27.3 grants the named recipient of a private-repository transfer temporary read collaborator access so they can review the repository, but rejecting or cancelling that transfer never revokes the collaboration, leaving the recipient with persistent read access to the private repository's code, issues, pull requests and wiki, including the ability to clone it, without any notification to the repository owner. Exploitation requires the repository owner to initiate a transfer of a private repository to a specific authenticated Gitea user who lacks prior access, and the affected party is that designated recipient rather than an arbitrary user; it is not attacker-initiated against default configurations. Severity is moderate (assessed CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N; published base score 4.3) with no public exploit identified at time of analysis and a low EPSS of 0.27% (17th percentile). Vendor-released patch: Gitea 28.0.0.
Server-side request forgery in Gitea's repository migration feature lets an authenticated user who is permitted to start migrations force the Gitea server to connect to reserved or link-local addresses, including the cloud metadata endpoint 169.254.169.254. The flaw only manifests in a non-default configuration where the administrator has set [migrations] ALLOWED_DOMAINS to a wildcard such as `*` or a hostname wildcard, which bypasses the intended ALLOW_LOCALNETWORKS = false protection because the local-network block list omitted reserved/link-local ranges and hostname allow-list matching was accepted irrespective of the resolved IP. Impact is bounded to reachability and read-style access from the server (no code execution or data modification), authentication is required per the CVSS vector (PR:L), and no public exploit has been identified at time of analysis, so this is a low-to-moderate priority issue whose real-world severity rises mainly where a reachable instance metadata service exists on the Gitea host.
Algorithmic complexity denial-of-service in Gitea 1.27.3 and earlier allows an authenticated user with permission to create issues or post comments to stall a server process by submitting a crafted ~1 MB body containing many Markdown links, keeping a CPU core busy for minutes while holding a database transaction open. The flaw is a quadratic rescan of preceding text for close/reopen keywords such as "closes" or "fixes" performed once per link (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H, score 6.5). It is authentication-gated and no public exploit code has been identified at time of analysis; EPSS is low at 0.16% (4th percentile) and CISA SSVC records Exploitation: none.
Stored cross-site scripting in the Gitea container registry (versions through 1.27.3) lets any user with permission to push container images publish a blob whose manifest declares a text/html media type, which Gitea then serves back verbatim as the blob's Content-Type with no Content-Disposition header and no restrictive Content-Security-Policy - so the embedded JavaScript executes on the Gitea origin when an authenticated victim opens the blob URL. Impact is bounded but real: the attacker must already hold registry push rights and the victim must be induced to open the crafted URL directly, but success allows same-origin actions as the victim such as creating API tokens. The flaw is rated 5.4 (CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:L/I:L/A:N), carries EPSS 0.18% (7th percentile), shows CISA SSVC exploitation of 'none', and has no public exploit identified at time of analysis; exploitation requires an account with image-push permission (authenticated, PR:L) and victim interaction (UI:R).
Authenticated low-privileged users on self-hosted Gitea through 1.27.3 can bypass the repository migration and pull-mirror egress checks by supplying a hostname with multiple DNS answers, so the address Gitea validates is not necessarily the address Git later connects to. This lets an attacker with migration or mirror creation rights reach internal Git or HTTP endpoints on the server's network, with limited read and write impact (assessed CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:L/I:L/A:N), and internal response content may additionally leak through migration and mirror error messages (CWE-209). Exploitation is non-deterministic and depends on winning a multi-answer DNS race plus a reachable internal target, and no public exploit code was identified at time of analysis; EPSS is 0.12% (2nd percentile), CISA SSVC rates exploitation as none and the issue as not automatable.
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.
Insecure direct object reference (IDOR) in Gitea's issue time-tracking feature allows authenticated users to delete tracked-time entries belonging to issues other than the one specified in the request URL. Affected are all Gitea Open Source Git Server versions before 1.25.5. The root cause is that `GetTrackedTimeByID` performed a database lookup using only the time entry's numeric ID, without filtering by the issue ID present in the URL path, enabling cross-issue data manipulation. No public exploit has been identified at time of analysis, and CISA KEV does not list this vulnerability.
Unauthorized read access to tracked time entries in Gitea before 1.25.5 exposes private repository metadata to unauthenticated network actors due to missing repository-level permission checks during API serialization (CWE-284). The flaw exists in the `ToStopWatches` and `ToTrackedTimeList` conversion functions in `services/convert/issue.go`, which iterated over and returned time entries without verifying the requesting user held read access to the underlying repository. No public exploit has been identified and CISA has not added this to KEV; however, the SSVC assessment designates the flaw as automatable, meaning it can be scripted at scale against all exposed Gitea instances running affected versions.
Open redirect in Gitea's login flow allows external domain hijacking by bypassing the `urlIsRelative` validation in `modules/httplib/url.go` through a combination of directory traversal sequences and a backslash in the `redirect_to` parameter. All Gitea instances running version 1.25.4 and below are affected; a working proof-of-concept is publicly available in the GitHub Security Advisory. Exploitation enables phishing via trusted Gitea domains, OAuth/SSO authorization code theft, Referer-header leakage of sensitive parameters, and potential cache poisoning — no public exploit identified as confirmed actively exploited (CISA KEV absent).
Missing repository-unit authorization on three Gitea API endpoints allows authenticated users with only non-Code unit access (e.g., an Issues-only organization team member) to read `.gitea/ISSUE_TEMPLATE/*` and `issue_config.yaml` files from the Code default branch of a private repository. The CVSS score of 4.3 (PR:L, C:L) accurately reflects the narrow scope: exploitation is limited to those specific configuration files, not arbitrary source code. A proof of concept is publicly documented in the vendor advisory (GHSA-3fwp-p5rj-2pxf); no active exploitation is confirmed in the CISA KEV catalog at time of analysis.
Public-only scoped API tokens in Gitea bypass their declared scope constraints and expose private organization membership data through two distinct code defects in `routers/api/v1/api.go`: the `/user/orgs` route omits the `checkTokenPublicOnly()` middleware entirely, and the `checkTokenPublicOnly` function contains a Go switch-case logic flaw that skips the user-visibility check on multi-category routes. This is an incomplete remediation of CVE-2025-68941 introduced by PR #32204, affecting all Gitea instances running version 1.26.1 and earlier. No public exploit code or active exploitation (CISA KEV) has been identified at time of analysis, but the attack is trivially reproducible from the published advisory steps.
Gitea's OpenID URI visibility controls lack proper ownership validation, allowing authenticated users to modify the visibility settings of other users' OpenID identities. This integrity bypass affects any Gitea instance where multiple users manage OpenID configurations, enabling account enumeration or information disclosure through unauthorized visibility changes. A patch is available to remediate this medium-severity vulnerability.
Gitea fails to enforce proper authorization checks when users attempt to cancel scheduled auto-merges through the web interface, allowing any user with pull request read access to cancel merge operations initiated by other users. This authorization bypass could disrupt automated workflows and merge processes across repositories. A patch is available to address this vulnerability.
Gitea's stopwatch API fails to re-validate repository access permissions, allowing revoked users to access sensitive information through active stopwatch sessions. An authenticated attacker with prior access to a private repository can enumerate issue titles and repository names even after their permissions have been removed. A patch is available to enforce proper access control validation.
Gitea's notification API fails to re-validate repository access permissions when retrieving notification details, allowing users with revoked access to private repositories to continue viewing issue and pull request titles through cached notifications. An authenticated attacker can exploit this to maintain visibility into sensitive repository content after their access has been removed. A patch is available.
Gitea may send release notification emails for private repositories to users whose access has been revoked. [CVSS 3.5 LOW]
In Gitea before 1.25.2, /api/v1/user has different responses for failed authentication depending on whether a username exists. [CVSS 5.3 MEDIUM]
Stored cross-site scripting in Gitea before 1.20.1 allows an attacker with a low-privilege account to embed links using forbidden URL schemes - notably javascript:, and by extension vbscript: and data: - in user-generated Markdown such as issues, comments, pull request descriptions, wiki pages, or repository files; when a victim clicks the crafted link, script executes in the context of the Gitea instance. The vulnerability carries a moderate CVSS of 5.4 (AV:N/AC:L/PR:L/UI:R/S:C/C:L/I:L/A:N) and requires victim interaction, with authentication requirements not confirmed as unauthenticated - the assessed vector (PR:L) indicates an authenticated, low-privilege attacker. No public exploit code or confirmed active exploitation was identified at time of analysis, and EPSS is low at 0.25% (15th percentile); a vendor fix is available in Gitea 1.20.1.
Unauthenticated information disclosure in Gitea before 1.21.2 lets an anonymous remote visitor view the projects page of a private (or otherwise non-public) individual user account. Per the CVSS vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N, exploitation requires no authentication and no user interaction: a single anonymous HTTP GET to a route such as /{user}/-/projects returns data that should be restricted, because individual user permissions were never checked after org assignment. Impact is limited to confidentiality (C:L) with no integrity or availability effect; EPSS is 0.36% (27th percentile) and no public exploit has been identified at time of analysis, and the issue is fixed in 1.21.2 (Vendor-released patch: 1.21.2), which returns HTTP 404 to anonymous and non-owner, non-admin requesters.
Gitea before 1.22.2 improperly validates access token scopes in its Conan, Container, and NuGet package registries, allowing an authenticated attacker who holds a valid token lacking package permissions to obtain a package authorization token and perform unauthorized read/write operations on packages (confused deputy, CWE-441). The flaw requires the attacker to already possess a valid Gitea access token and only affects instances where package registries are enabled; it does not enable anonymous access or full repository compromise. No public exploit code or active exploitation has been identified, and with an EPSS of 0.28% (18th percentile), the real-world priority is low.
Gitea instances running versions before 1.21.8 expose users' last-login timestamps to anyone who can reach the public explore listings, because the /explore/users endpoint accepted sort values such as lastlogin and reverselastlogin (and activity-leaking variants like leastupdate and reverseleastupdate) that were never intended to be user-selectable. The issue is network-reachable, requires no authentication and no user interaction (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N, CVSS 5.3, CWE-497), and the only impact is limited confidentiality loss - no credentials, repository content, or state modification is exposed. No public exploit code has been identified at time of analysis and the CVE is not in CISA KEV; EPSS is low at 0.36% (27th percentile), consistent with a low-value reconnaissance/enumeration bug rather than an active campaign. Exploitation simply requires issuing a crafted sort query parameter against an instance whose explore pages are publicly accessible or reachable from an internal network.
Authenticated cross-site scripting (XSS) in Gitea before 1.22.2 allows a user with repository branch/tag creation access to inject HTML through a crafted search term that is rendered with v-html in the RepoBranchTagSelector component; a victim must view or interact with the resulting prompt (UI:R). The issue is a moderate-severity CWE-79 flaw confirmed by an upstream patch, with EPSS 0.25% (15th percentile) and no public exploit identified at time of analysis, so it is a genuine but not urgent risk.
Broken authorization in Gitea before 1.22.3 causes API tokens scoped only to public resources to be honored when the request targets private resources, allowing an authenticated holder of such a token to read private repositories, organizations, users, packages, issues, notifications, and ActivityPub data. The attacker must already possess a valid Gitea API access token whose scope is explicitly limited to public resources (e.g., public-only repository, issue, organization, user, package, notification, or ActivityPub scopes) and must point it at a private resource on the same instance, so this is an authenticated privilege-scope bypass rather than an anonymous exposure. Impact is confined to read-only information disclosure with no integrity or availability effect; EPSS is 0.26% (17th percentile) and no public exploit code has been identified at time of analysis.
Gitea before 1.22.5 allows an authenticated user with pull-request merge rights to delete the pull request head branch without branch-deletion permission when merging with the delete-branch-after-merge option. This is a CWE-863 incorrect authorization flaw that is assessed as a modest-severity, low-priority issue: it can cause unauthorized branch removal but does not grant code execution or data disclosure, applies only to the PR head branch, and does not affect agit-flow references. The EPSS score is low at 0.27 percent (18th percentile), no public exploit identified at time of analysis, and the vendor released a patch in Gitea 1.22.5.
Gitea deployments running releases before 1.23.0 let an authenticated user who holds rights to modify an existing issue, comment, or release attachment rename that attachment to a forbidden file extension, bypassing the instance's configured AllowedTypes allow-list. Because the extension/type check was enforced only on the upload path and not on the attachment-name update path, an attacker can first upload a permitted file and then rename it through the attachment API (the issue, issue-comment, or release asset endpoints), causing Gitea to store and serve a file type that the operator intended to block. The fix in 1.23.0 routes renames through the same verification service and returns HTTP 422 for a forbidden extension. Exploitation requires API access plus attachment-management privileges rather than fully anonymous access, only matters where administrators actually rely on AllowedTypes to restrict extensions (default AllowedTypes is unrestricted in many deployments), and the outcome is storing/serving a disallowed file type rather than server-side code execution. EPSS is 0.33% (24th percentile) and no public exploit has been identified at time of analysis.
Authorization bypass in Gitea before 1.25.2 allows a user without proper release-management permission on a repository to delete releases, resulting in loss of release data. The flaw is a medium-severity incorrect authorization issue (CWE-863, CVSS 5.3) with a low EPSS score of 0.38% (30th percentile); no public exploit code or confirmed active exploitation has been identified. Exploitation requires a valid Gitea account and API/web access to the target repository, and impact is limited to release deletion for repositories reachable by that account.
Improper Neutralization of Input During Web Page Generation (XSS or 'Cross-site Scripting') vulnerability in Gitea Gitea Open Source Git Server allows Stored XSS.22.0. Rated critical severity (CVSS 10.0), this vulnerability is remotely exploitable, no authentication required, low attack complexity. No vendor patch available.
Open Redirect in GitHub repository go-gitea/gitea prior to 1.19.4. Rated medium severity (CVSS 4.4), this vulnerability is remotely exploitable. Public exploit code available.
In Jenkins Gitea Plugin 1.4.4 and earlier, the implementation of Gitea personal access tokens did not support credentials masking, potentially exposing them through the build log. Rated medium severity (CVSS 4.3), this vulnerability is remotely exploitable, low attack complexity. No vendor patch available.
Gitea before 1.17.3 does not sanitize and escape refs in the git backend. Rated critical severity (CVSS 9.8), this vulnerability is remotely exploitable, no authentication required, low attack complexity.
In Gitea before 1.16.9, it was possible for users to add existing issues to projects. Rated medium severity (CVSS 6.5), this vulnerability is remotely exploitable, low attack complexity. No vendor patch available.
Cross-site Scripting (XSS) - Stored in GitHub repository go-gitea/gitea prior to 1.16.9. Rated medium severity (CVSS 5.4), this vulnerability is remotely exploitable, low attack complexity. Public exploit code available.
An arbitrary file deletion vulnerability in Gitea v1.16.3 allows attackers to cause a Denial of Service (DoS) via deleting the configuration file. Rated high severity (CVSS 7.5), this vulnerability is remotely exploitable, no authentication required, low attack complexity.
Open Redirect on login in GitHub repository go-gitea/gitea prior to 1.16.5. Rated medium severity (CVSS 6.1), this vulnerability is remotely exploitable, no authentication required, low attack complexity. Public exploit code available.
Missing Authorization in GitHub repository go-gitea/gitea prior to 1.16.4. Rated high severity (CVSS 7.1), this vulnerability is remotely exploitable, low attack complexity. Public exploit code available.
In all versions of GitLab CE/EE since version 8.15, a DNS rebinding vulnerability in Gitea Importer may be exploited by an attacker to trigger Server Side Request Forgery (SSRF) attacks. Rated high severity (CVSS 8.1), this vulnerability is remotely exploitable, low attack complexity. No vendor patch available.
Gitea 1.12.x and 1.13.x before 1.13.4 allows XSS via certain issue data in some situations. Rated medium severity (CVSS 5.4), this vulnerability is remotely exploitable, low attack complexity. Public exploit code available.
Stack buffer overflow vulnerability in gitea 1.9.0 through 1.13.1 allows remote attackers to cause a denial of service (crash) via vectors related to a file path. Rated high severity (CVSS 7.5), this vulnerability is remotely exploitable, no authentication required, low attack complexity. No vendor patch available.
Gitea 0.9.99 through 1.12.x before 1.12.6 does not prevent a git protocol path that specifies a TCP port number and also contains newlines (with URL encoding) in ParseRemoteAddr in. Rated critical severity (CVSS 9.8), this vulnerability is remotely exploitable, no authentication required, low attack complexity.
An issue was discovered in Gitea through 1.11.5. Rated high severity (CVSS 7.5), this vulnerability is remotely exploitable, no authentication required, low attack complexity. Public exploit code available.
Gitea 1.7.0 and earlier is affected by: Cross Site Scripting (XSS). Rated medium severity (CVSS 6.1), this vulnerability is remotely exploitable, no authentication required, low attack complexity. This Cross-Site Scripting (XSS) vulnerability could allow attackers to inject malicious scripts into web pages viewed by other users.
Gitea 1.7.2, 1.7.3 is affected by: Cross Site Scripting (XSS). Rated medium severity (CVSS 6.1), this vulnerability is remotely exploitable, no authentication required, low attack complexity. No vendor patch available.