Gitea
Monthly
Cross-site request forgery on the repository-topics endpoint in Gitea 28.1.0 and earlier allows a third-party site to silently overwrite or clear the topic tags of a repository, because the POST /{owner}/{repo}/topics route was registered without the sign-in middleware that performs Gitea's cross-origin check. A repository administrator who is logged in to Gitea and visits a malicious page can have their repository's topics changed; no other repository settings are reachable through this route, and there is no data disclosure. The attacker needs no account (unauthenticated, per the CVSS vector PR:N) but exploitation depends on the victim's interaction (UI:R), and only the topics field is affected, which is materially narrower than the supplied 8.1 score implies. EPSS is low at 0.16% (4th percentile), there is no CISA KEV listing, and no public exploit code was identified at time of analysis; prioritized as remediation work for this week, with a vendor-released fix in Gitea 28.2.0.
Authentication bypass and user impersonation in Gitea through 28.1.0 let an authenticated low-privilege attacker assume another user's identity when the instance trusts a user SSH certificate authority and allows arbitrary principals. The flaw is highly configuration-dependent: only deployments with SSH_TRUSTED_USER_CA_KEYS set and SSH_AUTHORIZED_PRINCIPALS_ALLOW=anything are exposed, and Gitea states instances that do not trust a user CA are unaffected. No public exploit has been identified at time of analysis; EPSS is 0.10% (1st percentile) and CISA SSVC records exploitation none and automatable no, while the vendor has released Gitea 28.2.0.
Broken access control in Gitea's push-mirror API (CVE-2026-86684) lets an authenticated repository administrator push a repository's refs into an existing Git repository located on the server's local filesystem, using the permissions of the Gitea process rather than the caller's own privilege. Exploitation requires three conditions to hold simultaneously: the instance must be configured with [security] IMPORT_LOCAL_PATHS = true (not a default setting), the attacker must hold repository-administrator rights on a repository whose owner holds the AllowImportLocal permission (the owner's permission is what the flawed check inspected), and a writable Git repository must already exist at the chosen path. The integrity-only impact (CVSS 3.1 7.1, AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:N as independently assessed) and non-default prerequisites mean real-world risk is lower than the headline score implies; no public exploit code or confirmed active exploitation was identified at time of analysis, and EPSS is 0.15% (3rd percentile).
Broken access control in Gitea up to and including 28.0.0 allows an authenticated repository collaborator who holds write access to the Code unit (but not Releases write access) to permanently delete published releases and their attachments by sending a single POST to /{owner}/{repo}/tags/delete against the release's tag. The flaw is rated CVSS 8.1 (AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:H per the assessed vector), reflecting high integrity and availability impact with no confidentiality loss, and exploitation requires the attacker to already be a trusted collaborator on the target repository rather than an anonymous outsider. There is no public exploit code identified at time of analysis, CISA KEV does not list it, SSVC rates exploitation as none and automatable as no, and EPSS is low at 0.17% (6th percentile).
OAuth2 token-endpoint misuse in Gitea 28.0.0 and earlier allows anyone holding a valid, unexpired OAuth2 access token to submit it under the refresh_token grant and receive a brand-new access token plus refresh token, effectively extending access past the credential's original expiry. Exploitation requires a pre-existing valid access token issued for the same OAuth2 application and grant, so this is a persistence/escalation-of-lifetime flaw rather than an entry point for an unauthenticated outsider; the assessed vector is CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N (NVD rates it 9.1 with PR:N). Multi-source signals conflict: NVD's score and CISA's SSVC rating of total technical impact are severe, while EPSS is only 0.17% (6th percentile) and SSVC lists exploitation as none - no public exploit code has been identified at time of analysis and the issue is not in CISA KEV.
Denial of service in Gitea affects instances running 1.27.3 and earlier that have Actions enabled: a user who can open a pull request from a fork can submit a small workflow file whose static strategy.matrix expands to an enormous number of job combinations, exhausting server memory and potentially killing the Gitea process. Because the Cartesian-product expansion occurs at run-creation time, before the fork pull-request approval gate is enforced, no maintainer approval and no self-hosted runner are required to trigger the resource consumption. Gitea 28.0.0 rejects static matrices exceeding 256 combinations before expansion; EPSS is 0.16% (4th percentile), there is no CISA KEV entry, and no public exploit code has been identified at time of analysis. This is a moderate, not top-tier, priority.
Unauthenticated attackers who can reach Gitea's web installer on an instance whose INSTALL_LOCK has been reset to false (or is otherwise unset) can obtain a fully authenticated session for any existing account - including an administrator - simply by submitting the install form with a username that matches that account, with no password verification whatsoever. Full administrative takeover follows, allowing the attacker to change the account's password and control the instance. The bypass only exists while the installer is network-reachable against a database that already contains users; the default hardened post-install state (INSTALL_LOCK=true) is not affected. Independent assessment rates this CVSS 8.1 (AV:N/AC:H/PR:N/UI:N, C:H/I:H/A:H); EPSS is low at 0.16% (4th percentile) and no public exploit code has been identified at time of analysis.
Gitea instances up to and including 1.27.3 can be crashed by a repository administrator who configures an external issue tracker link format whose regular expression uses alternation with separate capture groups; the resulting invalid slice index triggers a Go runtime panic that terminates the Gitea process, and because rendering is triggered on later page views (for example a README containing matching text), the crash hits every user of the instance, not just the configurator. Exploitation requires an actor able to edit a repository's external issue tracker settings - on instances that permit self-service repository creation this effectively means any authenticated user on their own repository - so the practical barrier is configuration privilege rather than anonymity. Independent signals are moderate and partly conflicting: EPSS is only 0.16% (4th percentile), CISA SSVC rates exploitation as 'none' with partial technical impact, no CISA KEV listing or public exploit code has been identified at time of analysis, and a vendor fix ships in Gitea 28.0.0.
Duplicate-name tree entries pushed to Gitea ≤1.27.3 are stored and served inconsistently: the web diff and file views resolve such a path to the first entry, while `git checkout`, Gitea Actions and generated release archives resolve it to the last, so a contributor can open a pull request that looks benign to reviewers but runs or delivers attacker-controlled content at the same commit. Exploitation requires the ability to push a branch or open a pull request (contributor access, or a public instance allowing registration and fork-based PRs) and is only consequential where a consumer resolves the commit differently - CI auto-running on the PR, a developer checking it out, or a release tarball being built; there is no confirmed active exploitation and no public exploit code identified at time of analysis, with EPSS at 0.16% (4th percentile). Critically, upgrading fixes only new incoming objects - existing repositories are not rescanned, so a malicious tree already stored stays exploitable after the patch.
Fork-originated Gitea Actions workflows can run on a base repository's registered runners without the required approval when a repository maintainer performs ordinary pull request triage, such as adding a label, because the approval decision was keyed to the user who triggered the event rather than the fork pull request author, allowing fork-controlled workflow code to execute in the base repository's CI context. Gitea versions up to and including 1.27.3 are affected when Actions is enabled and a matching runner is registered; the issue is fixed in Gitea 28.0.0. No public exploit code was identified at time of analysis and EPSS is low (0.15%, 3rd percentile), but exploitation is not autonomous: the assessed vector (CVSS:3.1/AV:N/AC:H/PR:L/UI:R/S:U/C:H/I:H/A:H) requires an attacker-submitted fork pull request plus a privileged maintainer action, and CISA SSVC rates the technical impact as total, so the outcome when the prerequisite chain is met is full compromise of confidentiality, integrity, and availability of the workflow execution environment.
Push mirror synchronization in Gitea 1.27.3 and earlier reuses a remote address that was validated against the [migrations] allow/block lists only once, at mirror-creation time, so a hostname that later resolves to a blocked or internal address is still handed to git push - a time-of-check/time-of-use flaw (CWE-367). An authenticated user who administers a repository (which includes any repository they create themselves) can therefore aim a push mirror at an internal Git service and force-push the repository's contents to it, assuming attacker influence over name resolution and a network-reachable internal endpoint. The assessed severity is high (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:N) because scope changes and both confidentiality and integrity of internal Git services are affected, but no public exploit code has been identified at time of analysis and EPSS is low (0.12%, 2nd percentile), with SSVC recording no observed exploitation and a non-automatable attack path - a real but bounded risk rather than a mass-exploitation emergency.
Gitea 1.27.3 and earlier misattributes the pushing identity to the repository owner whenever a git push is authenticated with a repository deploy key, causing the pre-receive hook pipeline to evaluate permissions against the owner rather than the deploy key. An attacker holding a write-enabled deploy key can therefore create protected tags despite not being on the tag allow list, or flip repository visibility (for example private to public) through git push options, and pull requests created via the AGit flow are likewise attributed to the owner. Access is gated: a read-only deploy key is insufficient, exploitation requires an authenticated push (CVSS PR:L), no public exploit code has been identified at time of analysis, EPSS is only 0.15% (3rd percentile), and CISA SSVC rates exploitation as none with partial technical impact.
Server-side request forgery in Gitea 1.27.3 and earlier lets a user who can start a repository migration or mirror reach blocked internal addresses: Gitea validates the destination hostname against its egress allow/block lists before invoking Git, but the Git subprocess resolves the hostname independently when it actually connects, so an attacker who controls the destination's DNS can re-point the name from an allowed address to an internal one between validation and connection. Exploitation requires both the ability to initiate a migration (on a default install this means a logged-in account, and instances with open registration make it effectively unauthenticated) and control of authoritative DNS with suitably short TTLs, which is why the independent assessment rates it CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:L/I:N/A:N rather than the vendor's 7.5. No public exploit code has been identified at time of analysis, EPSS is only 0.15% (3rd percentile), and SSVC records Exploitation: none with partial technical impact; the vendor-released fix is Gitea 28.0.0.
Server-side request forgery in Gitea (versions up to and including 1.27.3) lets a repository administrator bypass the configured outbound host policy: Gitea validates the initial remote URL for push mirrors, wiki remote checks, and migrated pull-request heads, but the raw Git operation that follows will chase an HTTP redirect to an address the policy would otherwise block, causing the server's Git client to reach internal services. Exploitation is meaningfully constrained - it requires repository-administrator privileges, a restrictive egress allow-list must actually be configured, and the attacker must control or locate an allow-listed endpoint that redirects to the desired internal target - so the realized impact is bounded by which internal services are reachable from the Gitea host. EPSS is 0.15% (3rd percentile), no public exploit identified at time of analysis, and there is no CISA KEV listing, so exploitation appears opportunistic and low-volume rather than confirmed actively exploited. Note that the published CVSS vector (7.5, PR:N) overstates the privilege requirement; our assessment rates it PR:L with limited confidentiality and integrity impact.
Gitea Actions in versions up to and including 1.27.3 can execute workflow code from an untrusted fork pull request head on the repository's runners without the maintainer approval that the first-time-contributor gate is supposed to require. An authenticated user holding Actions write permission can cancel a run that is still awaiting approval and then re-run it; the rerun path recreated the attempt's jobs as waiting instead of blocked while the run still recorded that approval was required, so the jobs were released without an approval decision. Signals point to a genuine but not emergency-grade issue: exploitation requires Actions enabled, a registered matching runner, a fork pull request from a first-time contributor, and Actions write access (CVSS PR:L), no public exploit code was identified at time of analysis, and EPSS is low at 0.16% (4th percentile).
Fork-controlled workflow code execution is possible in Gitea (through 1.27.3) when Actions is enabled and a repository runs a shared run-level concurrency group: an attacker who can open a fork pull request plants workflow content in an approval-gated run, a sibling run in the same concurrency group cancels the blocked job and drives the run terminal while it still carries the approval flag, and a later maintainer approval re-queues the already-cancelled job so a matching runner claims and executes it. The independent assessment rates this CVSS:3.1/AV:N/AC:H/PR:L/UI:R/S:U/C:H/I:H/A:H - lower than the 8.8 base figure because the decisive step is a human maintainer approval plus a race against a sibling run and an available accepting runner - and no public exploit code has been identified at time of analysis. No public exploit identified at time of analysis; EPSS is 0.16% (4th percentile) and CISA SSVC records Exploitation: none, Automatable: no, Technical Impact: total.
Authenticated users who are able to open a pull request from a fork can cancel trusted, in-progress Gitea Actions runs in the base repository when those runs share a workflow-level concurrency group with cancel-in-progress enabled, because the cancellation logic does not check whether the newer run still needs approval before terminating the older ones. The attacker runs no code and gains no data access, but on self-hosted runners the interruption can abort an in-flight deployment and leave partial state behind. No public exploit code has been identified at time of analysis and EPSS is low at 0.16% (4th percentile), consistent with a targeted, configuration-dependent CI-disruption issue rather than a broad default-config exposure.
Authentication bypass in Gitea's built-in SSH server (affected releases up to and including 1.27.3) lets a remote attacker authenticate as another user by presenting a case-variant of that user's registered RSA public key. Three conditions must all hold: the built-in SSH server must be enabled via START_SSH_SERVER = true (non-default on many deployments), the backing database must perform case-insensitive text comparison (the default SQLite qualifies), and the attacker must possess or derive a working RSA private key whose public key differs from the victim's only by letter case, which is cryptographically very hard and is why the effort is assessed as high complexity rather than the low complexity of the published vendor vector. No public exploit code identified at time of analysis; EPSS is 0.16% (4th percentile) and the CISA SSVC assessment records exploitation: none. The flaw is fixed in v28.0.0 by matching keys on their SHA256 fingerprint instead of encoded content.
Server-side request forgery in Gitea 1.27.3 and earlier allows an authenticated user with permission to start repository migrations to reach internal services by pointing an allow-listed migration hostname at a loopback or private address, bypassing the ALLOW_LOCALNETWORKS=false restriction. Exploitation requires the optional [migrations] ALLOWED_DOMAINS allow-list to be configured (default installations are unaffected by this specific bypass), valid migration rights (CVSS PR:L, authenticated), and attacker control over DNS resolution for a hostname already present in that allow-list. No public exploit code or confirmed active exploitation was identified at time of analysis; the root-cause class is network-restriction bypass (SSRF-style) rather than an authentication bypass, despite that tag in the source data.
Account takeover in Plane (makeplane) versions prior to 1.4.0 allows remote unauthenticated attackers to log in as existing users by exploiting OAuth email trust in Gitea and self-managed GitLab deployments where email confirmation is disabled. The vulnerability (CWE-287) stems from Plane matching the email returned by the OAuth provider to a local account without verifying provider-side ownership; an attacker can set an OAuth identity's unverified email to the victim's address and authenticate as them without knowing the password, as confirmed by the provided independent assessment. Deployments using GitHub, GitLab.com, or Google OAuth are not affected because those providers return verified emails; no public exploit identified at time of analysis, and the flaw is gated by deployment configuration rather than being universally exploitable.
Server-side request forgery in Plane, the open-source project management tool, allows a low-privilege user of a connected Gitea instance to make the Plane server issue HTTP requests to internal or private addresses. The flaw affects versions prior to 1.4.0 and only manifests when an administrator has explicitly enabled Gitea OAuth and pointed GITEA_HOST at a legitimate Gitea deployment (the feature is off by default); an authenticated Gitea user then sets an internal URL as their profile avatar and logs in through OAuth, causing Plane to fetch that attacker-chosen target without validation. The result is a largely blind SSRF primitive, since the avatar handler only accepts image Content-Types and enforces a size cap, and no public exploit code or active exploitation has been identified at time of analysis.
Workflow-supplied container options in Gitea act_runner (versions before 3.0.0) are merged straight into the Docker HostConfig of the job container, letting a workflow author request host PID/IPC namespaces, CapAdd=ALL and unconfined seccomp/apparmor and then escape to the runner host as root. The twist is that the flaw is exploitable precisely when runner privileged mode is disabled: that code path forces only Privileged=false while preserving namespace, capability, device and security-profile flags from workflow YAML, so the control administrators rely on does not contain the attack. Only the Docker job-container backend is affected, and exploitation requires the ability to submit or trigger a workflow on a repository served by that runner (authenticated, push or pull-request privileges per the PR:L vector), with impact changing scope to the underlying host; no public exploit identified at time of analysis, and EPSS is low at 0.20% (9th percentile), though real-world risk is severe for shared runners open to untrusted workflow authors.
Dokploy instances running versions prior to 0.29.13 disclose stored Git provider secrets - GitHub App private keys, OAuth tokens and client secrets, webhook secrets, and Gitea/Bitbucket access tokens, refresh tokens, and app passwords - to authenticated organization members who were never granted access to those providers. The protected tRPC procedures github.one, gitlab.one, gitea.one, and bitbucket.one return full provider rows without applying getAccessibleGitProviderIds or an organization check, and application.one returns the same secrets as nested relations from findApplicationById even when hasGitProviderAccess is false. Exploitation requires an authenticated Dokploy account (PR:L) holding application read access or knowledge of a provider identifier, and the practical impact is confidentiality: a restricted member can use the leaked credentials to read private repositories or manipulate external CI/CD and webhook workflows. No public exploit code has been identified at time of analysis.
Server-side request forgery in Gitea Open Source Git Server (all versions through 1.26.4) lets attackers abuse the repository migration and mirror features to reach internal network resources. Two distinct weaknesses are involved: a DNS-rebinding bypass where a hostname resolves to a permitted address during validation and to an internal address when the actual request is made, and a missing re-validation flaw where redirect or subsequent fetch targets are not re-checked against the allow/deny policy. No public exploit was identified at time of analysis, EPSS is low (0.15%), and it is not in CISA KEV, but the vendor rates technical impact as total and the issue is fixed in 1.27.0.
Broken access control in Gitea (self-hosted Git service) versions up to and including 1.26.4 lets the team-repository linking endpoint ignore the RepoAdminChangeTeamAccess organization setting, so repository administrators can grant or alter team access to repositories even when an org owner has explicitly restricted that ability. This CWE-862 missing-authorization flaw undermines an intended org-level guardrail, exposing private repository contents (C:H) and permitting unauthorized permission changes (I:H). No public exploit has been identified at time of analysis, and the EPSS probability is low (0.15%, 5th percentile).
Authenticated command injection in Dokploy (self-hostable PaaS) versions 0.29.3 through 0.29.12 lets a low-privileged user achieve arbitrary host command execution by storing a malicious Git branch value and triggering a deployment. The branch fields (customGitBranch, branch, gitlabBranch, bitbucketBranch, giteaBranch) were left without server-side validation because the earlier fix for CVE-2026-45628 was incomplete, so attacker-controlled input flows unescaped into shell-based git clone commands. No public exploit has been identified at time of analysis, but the flaw carries a CVSS of 9.9 and is fixed in 0.29.13.
SSRF protection bypass in Gitea prior to 1.27.0 exposes internal services, cloud instance-metadata endpoints (e.g., AWS IMDSv1 at 169.254.169.254), and local files - including the application configuration containing database credentials and signing secrets - to authenticated attackers. Three HTTP fetch code paths in the migration and OAuth avatar subsystems use Go's raw http.Get() rather than the hardened hostmatcher.NewDialContext() transport used elsewhere, completely circumventing Gitea's built-in SSRF defenses. A publicly available proof-of-concept is included in the GHSA advisory; no confirmed active exploitation (CISA KEV) has been identified at time of analysis.
Server-side request forgery in Gitea ≤1.26.4 allows privileged users to bypass the platform's own hostmatcher SSRF defenses via three unprotected raw http.Get() code paths in the migration and OAuth avatar subsystems, enabling retrieval of cloud instance metadata (AWS IMDSv1, GCP tokens), local file read (e.g., app.ini with database credentials and JWT secrets), and internal network scanning. A detailed proof-of-concept exploit is publicly available in the GitHub Security Advisory GHSA-2wm4-vwp6-v7xc. EPSS is low at 0.16% (6th percentile), consistent with the privilege requirements limiting opportunistic exploitation, but the disclosed PoC and the sensitivity of reachable data elevate real-world risk for cloud-hosted deployments. No active exploitation is confirmed in CISA KEV at time of analysis.
Private organization member enumeration in Gitea allows any authenticated user to retrieve the full member roster - including emails - of a private organization via the /api/v1/orgs/{org}/members endpoint. The root cause is an incomplete fix: PR #38145 added visibility guards to ListPublicMembers and IsPublicMember but omitted the same guard from ListMembers, leaving a single missing HasOrgOrUserVisible check in routers/api/v1/org/member.go. Proof-of-concept code is publicly available in the GitHub Security Advisory; no active exploitation has been confirmed in CISA KEV, and the EPSS score of 0.16% (5th percentile) indicates low probability of widespread automated exploitation.
Server-side request forgery in Gitea before 1.27.0 lets attackers coerce the server into HTTP requests against internal hosts because its outbound IP allow-list classifier (IsGlobalUnicast && !IsPrivate) fails to block CGNAT (100.64.0.0/10) and nine IPv6 transition prefixes. An authenticated user can point a webhook or repo migration at an internal CGNAT service and read the full response (status, headers, and up to 1 MB body) rendered back on the hook detail page; separately, when OpenID sign-in is enabled the unauthenticated /user/login/openid discovery fetch uses http.DefaultClient with no IP filtering, giving anonymous internet callers a blind SSRF primitive. Publicly available exploit code exists (bundled run_poc.sh reproduces all three primitives), but no active exploitation is confirmed.
Unauthenticated denial of service in Gitea's Locale middleware allows any remote attacker to consume ~2 seconds of server CPU per HTTP request by crafting a ~1 MiB Accept-Language header composed of underscore separators, bypassing the existing CVE-2022-32149 guard in golang.org/x/text which only counts dash characters. All Gitea releases from 1.22.x through 1.26.x are affected because the middleware at modules/web/middleware/locale.go:38 passes the raw, unfiltered header directly to the quadratic-time ParseAcceptLanguage parser; ten concurrent attackers consuming ~10 MiB/s of upstream bandwidth can saturate all cores of a ten-core host indefinitely. Publicly available exploit code exists in the GHSA advisory; no active exploitation has been confirmed by CISA KEV at time of analysis.
Repository visibility and template status in Gitea (self-hosted Git service) before 1.27.0 can be silently toggled by any repository owner or admin-collaborator through undocumented git push options (repo.private, repo.template) processed by the post-receive hook, bypassing all audit logging, webhooks, and notifications. An insider can flip a private repository to public long enough to clone proprietary code, then revert it, leaving only two ordinary push events in the activity feed. No CISA KEV listing and no separately published exploit tool exist, but the GHSA advisory ships full working reproduction commands, and the CVSS 3.1 base score is 7.1 (High).
Improper authorization in Gitea before 1.27.0 lets an administrator-deactivated user (IsActive=false) silently reactivate their own account by signing in through an OAuth2/OIDC source that issues no refresh token - notably GitHub, or any OIDC source without offline_access. The reactivation gate added in PR #38009 uses an empty stored refresh token as its signal for 'disabled by auto-sync cron,' but for these sources every user has an empty refresh token, so an administrator's deliberate deactivation is indistinguishable from a cron disable and gets undone on the next login, granting a full session (including regained admin rights, since deactivation does not clear IsAdmin). No public exploit code is packaged, but a detailed, reproducible proof-of-concept is published in the vendor advisory; not listed in CISA KEV.
Identity-claim disclosure in Gitea (self-hosted Git server) before 1.27.0 lets any holder of a valid personal access token retrieve their email and organization/team membership from the OIDC userinfo endpoint (GET /login/oauth/userinfo) even when the token's scopes (e.g. only read:misc) would deny the equivalent REST API calls. The endpoint accepts API tokens as bearer credentials but skips the scope enforcement applied elsewhere, collapsing the authorization boundary that scoped tokens are meant to provide. Publicly available exploit code exists; the flaw is not in CISA KEV and EPSS is low (0.17%).
Improper TLS certificate validation in Gitea versions prior to 1.27.0 lets an on-path attacker intercept the internal API channel and steal the static, high-privilege INTERNAL_TOKEN. The internal API HTTP client (modules/private/internal.go) hardcodes InsecureSkipVerify:true with no config override, so gitea serv / gitea hook subprocesses accept any certificate when LOCAL_ROOT_URL uses HTTPS to a non-loopback host. A detailed proof-of-concept is published in the vendor advisory, but there is no evidence of active exploitation; the token grants full control over every /api/internal/* endpoint, including server shutdown, SSH key authorization, and arbitrary git command execution.
Gitea's REST API leaks private organization membership through the `GET /orgs/{org}/public_members/{username}` endpoint, bypassing the visibility controls that correctly conceal this information in the web UI. All versions up to and including 1.26.4 are affected, permitting any user with a valid API token to confirm whether a specific user belongs to a hidden organization - data intentionally withheld from the web interface. No public exploit is confirmed in CISA KEV, though a detailed proof-of-concept with curl commands is documented in GHSA-jr5x-6h83-wrxf; EPSS stands at 0.16% (5th percentile), indicating low observed exploitation probability.
Gitea's Actions permission engine grants fork-PR task tokens unauthorized code-read access to third private repositories via a missing fork-PR discriminator in the collaborative-owner branch of `GetActionsUserRepoPermission`. All Gitea instances running versions up to and including 1.26.4 are affected when the collaborative-owner Actions feature is configured, as confirmed by vendor advisory GHSA-fj8v-hjwv-qm88 and EUVD-2026-58151. An attacker who has had at least one fork PR previously approved can exploit this to clone the full source of a private repository they were never authorized to access; impact is strictly read-only, with no write or code-execution capability. A functional PoC was included in the security advisory; this CVE is not in the CISA KEV catalog and no EPSS score was provided in the available data.
Broken authorization in Gitea (self-hosted Git server) versions before 1.27.0 lets a token scoped as public-only,write:repository push commits into a private pull-request head branch it should never touch. Because Gitea only evaluates the public-only restriction against the public base repository named in the route (POST /api/v1/repos/{owner}/{repo}/pulls/{index}/update) and never re-applies it to the private head repository, an attacker holding such a token can force a server-side write into the private repo and, where Actions is enabled, trigger its push workflow. This is CWE-863 incorrect authorization; a publicly available exploit code exists in the vendor advisory, EPSS is low at 0.24%, and it is not listed in CISA KEV.
Privilege escalation in Gitea's self-hosted Git service (all versions ≤ 1.26.4) lets an attacker holding a narrowly-scoped Personal Access Token mint a new token with any scope, including full 'all' access, without the account password. The POST /users/{username}/tokens endpoint is guarded by reqBasicOrRevProxyAuth, which is meant to force password auth, but supplying the token as Authorization: Basic base64(<token>:x-oauth-basic) tricks the guard into setting IsBasicAuth=true, and the token-creation handler enforces no scope ceiling. A working proof-of-concept integration test is published in the advisory, though there is no public exploit identified in the wild and EPSS is low (0.16%).
Persistent account takeover in Gitea (self-hosted Git service) versions up to and including 1.26.4 arises because a stolen Remember-Me cookie is never revoked after theft is detected. When the split-token (ID:Hash) design detects a hash mismatch - the canonical signal of a compromised token per the Paragonie remember-me guidance - CheckAuthToken only returns ErrAuthTokenInvalidHash and autoSignIn merely clears the victim's local cookie, leaving the attacker's rotated token live in the database. The result is indefinite attacker access to the victim's account. Fixed in 1.27.0; no public exploit identified at time of analysis, and EPSS is low at 0.16%.
Authorization bypass in Gitea before 1.27.0 lets a public-only Personal Access Token read internal content owned by Limited-visibility users and organizations, exceeding the reach the scope is meant to grant. The Repository and Package scope categories only test repo.IsPrivate / Owner.Visibility.IsPrivate(), which return false for VisibleTypeLimited, so an authenticated attacker with a public-only PAT can fetch READMEs, repo content, packages from all 24 registries, and even perform full git-upload-pack clones of instance-internal projects. A vendor-verified end-to-end Docker PoC exists (publicly available exploit code exists); it is not in CISA KEV and EPSS is low at 0.17% (6th percentile). This is the residual gap left after CVE-2026-25714 / PR #37118 fixed the sibling User/Org/ActivityPub cases.
Branch protection bypass in Gitea versions prior to 1.27.0 allows a user with write (non-admin) access to merge unauthorized code into a protected branch by exploiting a stale approval flag. When a pull request is retargeted from an unprotected branch to a protected one via ChangeTargetBranch, Gitea fails to re-evaluate the stored official=true flag on existing approvals, so an approval that was never valid under the protected branch's whitelist still satisfies its required-approvals gate. Publicly available exploit code exists (a detailed step-by-step PoC in the GHSA advisory); no public exploit identified as actively used and it is not in CISA KEV.
Server-side request forgery and internal repository exfiltration in Gitea before 1.27.0 lets a low-privileged authenticated user bypass the migration URL allow/block list by supplying a permitted public Git URL that HTTP-redirects the server's git subprocess to an otherwise-blocked internal endpoint. Because Gitea validates only the originally submitted URL while git runs with its default http.followRedirects=initial, the redirected internal Git repository is cloned into an attacker-controlled repository, and pull mirrors keep re-fetching it on schedule. No public exploit identified at time of analysis; a vendor-authored local proof-of-concept confirmed the redirect is followed to 127.0.0.1, and EPSS/KEV data were not supplied.
Cross-repository information disclosure and cross-task tampering in Gitea's self-hosted Git server (fixed in v1.26.2) arises from an HMAC signature ambiguity in the Actions Artifacts V4 signed-URL scheme, letting an authenticated low-privilege user reuse a validly signed URL outside its intended repository or task context. An attacker with access to a single Actions task can read private artifacts belonging to other repositories and write upload-state for tasks they do not own, crossing the repository trust boundary (CVSS 9.6, scope-changed). There is no public exploit identified at time of analysis, and it is not listed in CISA KEV.
Authorization bypass in Gitea's Gitea Actions fork pull-request approval gate lets a low-privileged contributor permanently defeat the maintainer approval step that normally guards workflow execution on fork PRs, so that after the initial gate is subverted the attacker's workflow code runs against the repository's CI runners and secrets. CVSS is 8.9 (high) with a scope change and high integrity/availability impact; no public exploit has been identified at time of analysis, but a vendor patch (v1.26.4) is available. The flaw is classed as CWE-285 (Improper Authorization) and was self-reported by the Gitea project.
Authentication bypass in Gitea's Git LFS (Large File Storage) SSH handling allows a low-privileged authenticated user to read files from private repositories they should not access by supplying a malformed SSH sub-verb, per the Gitea security advisory GHSA-7wvc-rvp7-w99x. Because the flaw crosses a security boundary (CVSS scope change) it exposes confidential repository contents without any integrity or availability impact. No public exploit has been identified at time of analysis, and it is not listed in CISA KEV, but a vendor patch is available in Gitea 1.26.4.
Authorization bypass in Gitea Open Source Git Server (versions up to and including 1.26.1) allows a user whose account was deliberately disabled by an administrator to silently regain access simply by signing in through a linked OAuth provider. The OAuth sign-in callback fails to honor the administrator's 'disabled' flag, effectively reversing an intended access-revocation action. EPSS is low (0.16%, 6th percentile) and there is no public exploit identified at time of analysis, but the flaw undermines a core account-lifecycle control on a widely self-hosted platform.
Denial of service in Gitea, the self-hosted open-source Git service, allows a remote unauthenticated attacker to exhaust server CPU by triggering catastrophic backtracking in the regular-expression engine that evaluates CODEOWNERS pattern matching. All versions prior to the fixed 1.26.3/1.26.4 releases are affected, and the CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N, A:H only) confirms network-reachable, low-complexity, no-authentication abuse with availability-only impact. There is no public exploit identified at time of analysis and EPSS is low (0.16%, 6th percentile), so exploitation risk is real but not yet widespread.
Information disclosure in Gitea Open Source Git Server (through 1.26.2) allows a user whose repository access has been revoked to continue viewing private issue metadata via the Notification API, because notification records are not purged or re-authorized when permissions change. The CVSS 3.1 base score is 7.5 (C:H) and the vendor (Gitea) fixed it in 1.26.3/1.26.4. No public exploit identified at time of analysis, and EPSS is low (0.17%, 7th percentile), indicating limited near-term exploitation likelihood.
Broken authorization in Gitea (self-hosted Git service) versions up to and including 1.26.2 lets a user who holds general repository access but has NOT been granted the Code unit permission read private source content by reusing Git LFS objects to authorize otherwise-restricted source objects. The flaw (CWE-639, tracked as GHSA-2m9v-5q2g-58vq) enables horizontal privilege escalation to confidential code within a repository. There is no public exploit identified at time of analysis and it is not listed in CISA KEV, but a vendor patch shipped in 1.26.3.
Branch-protection bypass in Gitea's self-hosted Git server (all versions before 1.26.0) allows a user with push access to circumvent pre-receive hook enforcement by supplying oversized hook input that trips a bufio.Scanner error the code fails to handle safely. Because Gitea does not fail closed on the scanner error, the protection check is silently skipped and the push is accepted. No public exploit identified at time of analysis; EPSS is low (0.17%, 7th percentile) and this is not in CISA KEV, but a vendor patch (v1.26.0) is available.
Canonical URL spoofing in Gitea before 1.25.5 lets remote attackers inject malformed X-Forwarded-Proto values that the server trusts when computing its public-facing URL, causing it to emit attacker-controlled canonical links (e.g. in emails, redirects, and generated absolute URLs). No public exploit identified at time of analysis, and the low EPSS score (0.17%, 6th percentile) reflects minimal in-the-wild interest, but a vendor patch is available in v1.25.5. Note that the published CVSS vector claims availability impact (A:H) while the description describes URL spoofing (an integrity concern), a discrepancy worth verifying with the vendor.
Privilege escalation in Gitea 1.25.5 lets a user holding a per-branch maintainer-edit grant reuse that write permission against other refs and obtain full repository write access. The flaw stems from a branch-specific permission result being cached and incorrectly reused across multiple refs within a single pre-receive hook session. It is an authenticated authorization-bypass (CWE-863) fixed in Gitea 1.26.3; no public exploit has been identified and EPSS exploitation probability is low (0.20%).
Broken access control in Gitea's Composer package registry (versions up to and including 1.26.1) lets remote attackers read private or internal Composer package source links they should not be authorized to see, leaking internal repository/source metadata. The flaw is a missing-authorization (CWE-862) issue reported by the Gitea project itself and fixed in v1.26.2; no public exploit identified at time of analysis, and it is not listed in CISA KEV. With a CVSS 3.0 base score of 8.2 driven by high confidentiality impact, the practical effect is unauthorized disclosure of otherwise-private package sourcing information.
Broken access control in Gitea before 1.25.5 lets clients retrieve draft release metadata and their attached files through the REST API without holding the repository write permission those drafts are meant to require. The flaw stems from the API omitting a token-scope/write-access check on draft release and attachment endpoints, so read-scoped tokens (and, on publicly readable repositories, unauthenticated callers) can enumerate and download unpublished release content. There is no public exploit identified at time of analysis, EPSS risk is low (0.17%, 6th percentile), and it is not on CISA KEV.
Broken object-level authorization (IDOR) in Gitea before 1.25.5 lets an authenticated user manipulate the primary email address of an arbitrary other account by supplying an email row ID they do not own. The account-settings 'make primary' handler looked up the target email by ID alone without verifying ownership, so a logged-in attacker can alter another user's primary email - an integrity impact with account-hijack and notification-redirection potential. There is no public exploit or active exploitation, EPSS is low (0.17%), and Gitea has shipped a fix in 1.25.5.
Uncontrolled resource consumption in Gitea before 1.25.5 allows remote attackers to exhaust server CPU by triggering unbounded 'git grep' code searches that ran without any execution timeout. Because the search endpoint is network-reachable and the CVSS vector (PR:N) indicates no authentication is required, an attacker can repeatedly submit expensive regex/pattern searches against hosted repositories to degrade or deny service. No public exploit identified at time of analysis, and EPSS is low (0.18%), but SSVC marks the flaw as automatable with partial technical impact.
Migration transport protections in Gitea are bypassed for Git LFS operations, affecting all self-hosted instances before version 1.25.5. Because LFS push and sync-mirror requests instantiated their client with a nil HTTP transport (lfs.NewClient(endpoint, nil)) instead of the hardened migration transport, LFS traffic escaped the allowlist/SSRF restrictions the migration transport enforces, letting a user who can configure a repository mirror direct LFS requests to otherwise-blocked destinations. There is no public exploit identified at time of analysis and EPSS is low (0.17%), but SSVC rates technical impact as total and automatable, and a vendor patch is available.
OAuth2 PKCE protection bypass in Gitea before 1.25.5 allows remote attackers to complete an authorization-code token exchange without a valid code verifier because the server fails to persist the S256 challenge method during authorization. Rated CVSS 9.1 with SSVC technical impact of 'total', though EPSS is low (0.17%, 6th percentile) and there is no public exploit identified at time of analysis. The fix is confirmed in release v1.25.5 (PRs 36462 and 36477), which was reported by the Gitea project itself.
Authentication bypass via OAuth2 authorization code replay in Gitea before 1.25.5, where the server fails to consistently enforce code expiry and single-use during the token-exchange step, letting an attacker who obtains a valid authorization code redeem it (potentially more than once, and after it should have expired) to mint access tokens for a victim's account. The source fix confirms authorization codes previously had no enforced 10-minute validity window and that double-redemption was not reliably detected. EPSS is low (0.17%, 6th percentile) and CISA SSVC lists exploitation status as none, but SSVC rates the technical impact as total and marks it automatable; no public exploit identified at time of analysis.
Arbitrary file read and write in Gitea before 1.25.5 arises when the template repository generation feature resolves paths through symlinks or other non-regular file types instead of restricting itself to regular files within the target root. An attacker who controls a template repository can plant symlinked or special paths so that generation reads sensitive files or writes attacker-controlled data outside the intended boundary, yielding high confidentiality and integrity impact (CVSS 9.1). There is no public exploit identified at time of analysis, the EPSS probability is low (0.17%, 7th percentile), and CISA SSVC records exploitation as 'none', but the flaw is automatable with total technical impact.
Improper access control in Gitea's organization permission API (all releases before 1.25.5) lets an authenticated API caller query permission and membership details for hidden organization members and private organizations they should not be able to see. The root cause is a visibility check performed against the target user instead of the requesting user, disclosing metadata that reveals otherwise-concealed org membership and permission levels. This is an information-disclosure/access-control issue (CWE-284) with no public exploit identified at time of analysis, a low EPSS (0.16%, 5th percentile), and SSVC exploitation status of 'none'.
Information disclosure in the Gitea 1.26.2 self-hosted Git service allows non-members to read the labels of private organizations via the Organization Labels API, exposing label metadata (id, name, description, color, url) that should be restricted to org members. The authorization gap affects GET /api/v1/orgs/{org}/labels and .../labels/{id} only, while organization info, teams, hooks, and secrets endpoints correctly returned 404 to the same user. Publicly available exploit code exists in the vendor GHSA advisory, though EPSS risk is low (0.20%, 10th percentile) and it is not on CISA KEV.
Improper access control in Gitea before 1.25.5 allows users to update or rebase pull request head branches without holding the write/force-push permissions those actions require, letting them push base-branch commits or rewrite history on branches they should not control. The flaw stems from the IsUserAllowedToUpdate logic in services/pull/update.go, which failed to properly re-check repository push and branch-protection permissions on the head branch. This is an integrity-only issue (CVSS 7.5, I:H) with no confidentiality or availability impact; SSVC lists exploitation as none and EPSS is low (0.16%), and no public exploit identified at time of analysis.
Information disclosure in Gitea 1.26.2 lets a fork owner keep pulling commits from a parent repository via the merge-upstream API even after the parent was switched from public to private, exposing content the fork should no longer be authorized to see. The flaw stems from the synchronization endpoint failing to re-check the parent's current visibility, so data added during the private period leaks into a fork whose owner can no longer directly access the parent. A working proof-of-concept is publicly published and CISA SSVC rates exploitation automatable, but the issue is not on CISA KEV and EPSS is low (0.20%); it is fixed in Gitea 1.26.3.
Server-side request forgery in Gitea versions up to and including 1.26.2 lets authenticated users abuse incomplete allow-list filtering in the webhook and repository-migration features to coerce the server into making requests to internal or otherwise restricted network destinations. Because the existing SSRF protection is incomplete rather than absent, attackers can craft addresses that bypass the allow-list checks to reach services that should be unreachable from outside. No public exploit identified at time of analysis, and the flaw is not listed in CISA KEV; a vendor patch is available in Gitea 1.26.3.
Improper input validation in Gitea Open Source Git Server before 1.25.5 lets authenticated users submit repository-creation requests with unbounded template fields (issue labels, license, readme, fork branch) and unsupported trust-model or object-format values. The upstream fix (PRs 36671/36757) adds MaxSize length constraints and rejects any ObjectFormatName that is not sha1 or sha256. Rated CVSS 9.1 by the reporter, but no public exploit was identified, EPSS is only 0.17% (6th percentile), and CISA SSVC records exploitation status as none.
Reverse-proxy authentication bypass in the official Gitea Docker image (versions up to and including 1.26.2) allows any source IP to impersonate arbitrary users because the image ships with REVERSE_PROXY_TRUSTED_PROXIES=* by default. When an operator enables reverse-proxy header authentication (e.g. X-WEBAUTH-USER), the wildcard trust list means Gitea accepts those identity headers from any client rather than only from a trusted front-end proxy, granting full account takeover including administrator access. No public exploit has been identified at time of analysis, and the issue is patched in Gitea 1.26.3.
TOTP two-factor authentication replay in Gitea 1.5.0 through 1.26.2 lets a captured valid one-time code be accepted multiple times instead of being invalidated after first use, weakening 2FA on both the web login flow and the Basic Auth X-Gitea-OTP header path. An attacker who observes a legitimate TOTP code (via interception, shoulder-surfing, or logging) can replay it within its validity window to authenticate as the victim. There is no public exploit identified at time of analysis and it is not listed in CISA KEV; the flaw is fixed in Gitea 1.26.3.
Approval-gate bypass in Woodpecker CI before 3.15.0 lets an attacker who can open a merge request from a fork against a GitLab-backed repository run unapproved, attacker-controlled pipelines. Because the GitLab forge driver populates pipeline.Author from the spoofable git commit author name (commit.author.name) rather than the GitLab-validated user identity, an attacker simply sets the commit author to a name listed in ApprovalAllowedUsers, making needsApproval return false. This grants arbitrary CI step execution on a Woodpecker agent and exposure of CI secrets; there is no public exploit identified at time of analysis, but the issue was reported by VulnCheck and is trivially reproducible.
Container escape in Gitea act_runner (Docker backend, through act 0.262.0) lets an authenticated user with workflow-execution rights break out to the host as root even when privileged mode is disabled. The runner passes a workflow's container.options string straight into the Docker job container's HostConfig and only forces the Privileged flag off, leaving dangerous options like --pid=host, --cap-add, and --security-opt intact. Publicly available exploit code exists (reported by VulnCheck), though it is not listed in CISA KEV.
Stored cross-site scripting in Gitea 1.25.x affects the built-in 3D file viewer (Online3DViewer integration) where a crafted .gltf file with an unsupported extension name in extensionsRequired is rendered into the DOM via innerHTML without sanitization. Any low-privileged user who can push a file to a repository (including a public fork) can compromise the session of any user who later views the file, enabling token theft and full account takeover. Publicly available exploit code exists (a working PoC is included in the GHSA-9cpj-qc93-vw8v advisory); no public exploit identified at time of analysis in CISA KEV.
Authorization bypass in Gitea versions 1.22.3 through 1.26.1 allows holders of `public-only` access tokens or OAuth grants to read and modify private account resources via `/api/v1/user/...` self routes, despite the public-only flag being designed to restrict tokens to public data. The flaw is a systemic scope-boundary failure across many self routes (SSH keys, emails, OAuth apps, Actions secrets/variables/runners, private repos, webhooks), publicly available exploit code exists in the form of reproducible Go PoCs in the advisory, and the issue represents an incomplete fix of CVE-2025-68941 in a different route family.
Authorization bypass in Gitea versions prior to 1.26.0 lets a read-only organization member create repositories in the organization namespace via the API fork endpoint, despite a team configuration that denies repository creation (can_create_org_repo=false). Because the fork creator receives admin rights on the resulting repo, the attacker can enable Actions and push a workflow that exfiltrates all organization-level CI/CD secrets (deploy keys, cloud credentials, API tokens). Publicly available exploit code exists in the GHSA advisory with a full step-by-step PoC; no public exploit identified at time of analysis beyond the reporter's reproduction.
Authorization bypass in Gitea versions up to and including 1.26.1 allows any authenticated user with mere read access to push arbitrary commits directly to any repository they can view, including all public repositories on the instance. The flaw stems from the 'Allow edits from maintainers' pull request flag being trusted without verifying the PR submitter actually owns write access on the HEAD side, enabling reverse-fork PRs to grant unauthorized push rights to upstream targets. Publicly available exploit code exists (a working poc.py is attached to the advisory), and the issue is fixed in Gitea 1.26.2.
OAuth2 scope enforcement bypass in Gitea <= 1.26.1 allows any OAuth2 access token to perform write actions far beyond its granted scope when submitted via HTTP Basic authentication instead of as a Bearer token. A token issued with only `read:user` can modify user settings, add attacker-controlled emails, and create or delete the user's repositories, effectively nullifying the entire OAuth2 scope model for Basic-auth requests. No public exploit identified at time of analysis, but the advisory itself contains a full working PoC.
Authorization scope bypass in Gitea v1.26.1 and earlier allows authenticated users to use OAuth2/PAT Bearer tokens to perform Git Smart HTTP clone, fetch, and push operations on private repositories without holding the required read:repository or write:repository token scopes. The flaw stems from CheckRepoScopedToken() short-circuiting unless ctx.IsBasicAuth is true, while the same route accepts Bearer authentication. No public exploit identified at time of analysis beyond the reporter's PoC test in the GHSA advisory.
Gitea fails to validate repository ownership when linking attachments to releases, allowing users to attach files from one repository to releases in another.
Gitea fails to validate repository ownership when deleting Git LFS locks, allowing users with write access to one repo to delete LFS locks in other repositories.
Gitea does not properly validate project ownership in organization operations, allowing users with project write access to manipulate projects belonging to other organizations.
Gitea fails to properly validate repository ownership when processing attachment deletion requests, allowing an authenticated attacker to delete files from repositories they no longer have access to by routing deletion requests through a different accessible repository. This authorization bypass affects all users who have uploaded attachments to shared repositories and could result in loss of critical project documentation or resources. A patch is available to address this improper access control vulnerability.
Gitea before 1.16.7 does not escape git fetch remote. Rated high severity (CVSS 7.5), this vulnerability is remotely exploitable, no authentication required, low attack complexity. Public exploit code available.
The git hook feature in Gitea 1.1.0 through 1.12.5 might allow for authenticated remote code execution in customer environments where the documentation was not understood (e.g., one viewpoint is that. Rated high severity (CVSS 7.2), this vulnerability is remotely exploitable, low attack complexity. Public exploit code available and no vendor patch available.
Gitea on Alpine Linux received a security fix packaged as gitea-1.27.3-r0, indicating an unspecified vulnerability was patched in this self-hosted Git service. The nature of the flaw, attack vector, and achievable impact are entirely undisclosed in available intelligence - only the corrected Alpine package version is confirmed. No CVSS score, CWE class, or vulnerability description accompanies this entry, making meaningful risk characterization impossible without additional vendor disclosure.
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.
Gitea versions 1.16.0 through 1.27.1 contain an authentication-logic flaw in which the sign-in, OAuth2 account-linking, and OpenID connect flows enforce a second factor by checking only for TOTP enrollment (HasTwoFactorByUID) and ignoring registered WebAuthn/passkey credentials, so an attacker who already holds valid primary credentials for a WebAuthn-only account can complete login or link an external identity without ever satisfying the second factor. Because exploitation presupposes a compromised password or a linkable external OAuth2/OpenID identity and only affects accounts whose sole second factor is WebAuthn with no TOTP enrolled, this is a second-factor bypass rather than a standalone remote takeover, which is consistent with the independently assessed CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H (high complexity) rather than the headline 9.8. There is no CISA KEV entry and no public exploit identified at time of analysis, and EPSS is low at 0.17% (6th percentile), so the practical risk is concentrated in deployments that rely exclusively on passkeys for MFA and in environments where primary credentials are already exposed.
Code injection in Gitea's Actions workflow handling can let a low-privileged authenticated user who can open a pull request cause workflow content to be executed from the wrong commit in pull_request_target runs, potentially running attacker-influenced workflow code in a privileged context. Gitea 1.19.0 through 1.27.1 are affected; fixed releases are Gitea 1.27.2 and Alpine package 1.27.3-r0. Exploitation is gated on Gitea Actions being enabled and a repository defining a pull_request_target workflow, EPSS is low at 0.22% (12th percentile), and no public exploit was identified at time of analysis.
Incorrect privilege assignment in Gitea (all versions through 1.26.4) causes scoped API/OAuth2/basic-auth/HTTP-signature tokens to be trusted beyond the scope they were issued for, so any authenticated user who can mint a token can read and modify resources the token was never meant to reach, including private-release drafts, package-registry endpoints, go-get and git-over-HTTP repository access. The CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:N/C:H/I:H/A:N, 8.1) confirms the attacker must already hold a valid account and credential, and the flaw is a silent authorization bypass rather than a pre-authentication compromise. Upstream patched the token-scope plumbing in Gitea 1.27.2 (Alpine ships the fix as gitea 1.27.3-r0); EPSS is only 0.24% (14th percentile) and no public exploit code or CISA KEV entry was identified at time of analysis.
Path traversal in Gitea's Org-mode (`.org`) markup renderer allows an attacker who can get Org-mode content rendered by the server to read arbitrary files from the Gitea host filesystem, through abuse of the `#+INCLUDE:` directive. Affected releases are Gitea 1.22 through versions prior to 1.27.1 (including the Alpine Linux `gitea` package, fixed in 1.27.1-r0); publicly available exploit code exists, and vendor patches are available. The input's 9.8 CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H) overstates the issue relative to our independent assessment (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N), which characterizes this as an authenticated arbitrary file disclosure rather than unauthenticated remote code execution with full integrity and availability impact. No CISA KEV entry was provided, so active exploitation is not confirmed.
Gitea 1.27.1 and earlier can complete an external OAuth2/OpenID account-linking flow without satisfying the second authentication factor, letting an attacker who already holds a victim's primary credentials bind their own external identity to the victim's account and ride that link past TOTP/WebAuthn protection. The defect is a missing critical step in the authentication sequence (CWE-304): the linking code only checked for TOTP enrollment, so users protected solely by WebAuthn were treated as having no 2FA and the link was committed before any second factor was answered. Exploitation requires a Gitea instance configured with external OAuth2/OpenID sources and account linking, plus valid primary credentials for a 2FA-enrolled target account (authenticated, PR:L); there is no public exploit identified at time of analysis, no CISA KEV listing, and EPSS is low at 0.20% (9th percentile), consistent with a targeted, credential-dependent attack rather than mass scanning.
Cross-site request forgery on the repository-topics endpoint in Gitea 28.1.0 and earlier allows a third-party site to silently overwrite or clear the topic tags of a repository, because the POST /{owner}/{repo}/topics route was registered without the sign-in middleware that performs Gitea's cross-origin check. A repository administrator who is logged in to Gitea and visits a malicious page can have their repository's topics changed; no other repository settings are reachable through this route, and there is no data disclosure. The attacker needs no account (unauthenticated, per the CVSS vector PR:N) but exploitation depends on the victim's interaction (UI:R), and only the topics field is affected, which is materially narrower than the supplied 8.1 score implies. EPSS is low at 0.16% (4th percentile), there is no CISA KEV listing, and no public exploit code was identified at time of analysis; prioritized as remediation work for this week, with a vendor-released fix in Gitea 28.2.0.
Authentication bypass and user impersonation in Gitea through 28.1.0 let an authenticated low-privilege attacker assume another user's identity when the instance trusts a user SSH certificate authority and allows arbitrary principals. The flaw is highly configuration-dependent: only deployments with SSH_TRUSTED_USER_CA_KEYS set and SSH_AUTHORIZED_PRINCIPALS_ALLOW=anything are exposed, and Gitea states instances that do not trust a user CA are unaffected. No public exploit has been identified at time of analysis; EPSS is 0.10% (1st percentile) and CISA SSVC records exploitation none and automatable no, while the vendor has released Gitea 28.2.0.
Broken access control in Gitea's push-mirror API (CVE-2026-86684) lets an authenticated repository administrator push a repository's refs into an existing Git repository located on the server's local filesystem, using the permissions of the Gitea process rather than the caller's own privilege. Exploitation requires three conditions to hold simultaneously: the instance must be configured with [security] IMPORT_LOCAL_PATHS = true (not a default setting), the attacker must hold repository-administrator rights on a repository whose owner holds the AllowImportLocal permission (the owner's permission is what the flawed check inspected), and a writable Git repository must already exist at the chosen path. The integrity-only impact (CVSS 3.1 7.1, AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:N as independently assessed) and non-default prerequisites mean real-world risk is lower than the headline score implies; no public exploit code or confirmed active exploitation was identified at time of analysis, and EPSS is 0.15% (3rd percentile).
Broken access control in Gitea up to and including 28.0.0 allows an authenticated repository collaborator who holds write access to the Code unit (but not Releases write access) to permanently delete published releases and their attachments by sending a single POST to /{owner}/{repo}/tags/delete against the release's tag. The flaw is rated CVSS 8.1 (AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:H per the assessed vector), reflecting high integrity and availability impact with no confidentiality loss, and exploitation requires the attacker to already be a trusted collaborator on the target repository rather than an anonymous outsider. There is no public exploit code identified at time of analysis, CISA KEV does not list it, SSVC rates exploitation as none and automatable as no, and EPSS is low at 0.17% (6th percentile).
OAuth2 token-endpoint misuse in Gitea 28.0.0 and earlier allows anyone holding a valid, unexpired OAuth2 access token to submit it under the refresh_token grant and receive a brand-new access token plus refresh token, effectively extending access past the credential's original expiry. Exploitation requires a pre-existing valid access token issued for the same OAuth2 application and grant, so this is a persistence/escalation-of-lifetime flaw rather than an entry point for an unauthenticated outsider; the assessed vector is CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N (NVD rates it 9.1 with PR:N). Multi-source signals conflict: NVD's score and CISA's SSVC rating of total technical impact are severe, while EPSS is only 0.17% (6th percentile) and SSVC lists exploitation as none - no public exploit code has been identified at time of analysis and the issue is not in CISA KEV.
Denial of service in Gitea affects instances running 1.27.3 and earlier that have Actions enabled: a user who can open a pull request from a fork can submit a small workflow file whose static strategy.matrix expands to an enormous number of job combinations, exhausting server memory and potentially killing the Gitea process. Because the Cartesian-product expansion occurs at run-creation time, before the fork pull-request approval gate is enforced, no maintainer approval and no self-hosted runner are required to trigger the resource consumption. Gitea 28.0.0 rejects static matrices exceeding 256 combinations before expansion; EPSS is 0.16% (4th percentile), there is no CISA KEV entry, and no public exploit code has been identified at time of analysis. This is a moderate, not top-tier, priority.
Unauthenticated attackers who can reach Gitea's web installer on an instance whose INSTALL_LOCK has been reset to false (or is otherwise unset) can obtain a fully authenticated session for any existing account - including an administrator - simply by submitting the install form with a username that matches that account, with no password verification whatsoever. Full administrative takeover follows, allowing the attacker to change the account's password and control the instance. The bypass only exists while the installer is network-reachable against a database that already contains users; the default hardened post-install state (INSTALL_LOCK=true) is not affected. Independent assessment rates this CVSS 8.1 (AV:N/AC:H/PR:N/UI:N, C:H/I:H/A:H); EPSS is low at 0.16% (4th percentile) and no public exploit code has been identified at time of analysis.
Gitea instances up to and including 1.27.3 can be crashed by a repository administrator who configures an external issue tracker link format whose regular expression uses alternation with separate capture groups; the resulting invalid slice index triggers a Go runtime panic that terminates the Gitea process, and because rendering is triggered on later page views (for example a README containing matching text), the crash hits every user of the instance, not just the configurator. Exploitation requires an actor able to edit a repository's external issue tracker settings - on instances that permit self-service repository creation this effectively means any authenticated user on their own repository - so the practical barrier is configuration privilege rather than anonymity. Independent signals are moderate and partly conflicting: EPSS is only 0.16% (4th percentile), CISA SSVC rates exploitation as 'none' with partial technical impact, no CISA KEV listing or public exploit code has been identified at time of analysis, and a vendor fix ships in Gitea 28.0.0.
Duplicate-name tree entries pushed to Gitea ≤1.27.3 are stored and served inconsistently: the web diff and file views resolve such a path to the first entry, while `git checkout`, Gitea Actions and generated release archives resolve it to the last, so a contributor can open a pull request that looks benign to reviewers but runs or delivers attacker-controlled content at the same commit. Exploitation requires the ability to push a branch or open a pull request (contributor access, or a public instance allowing registration and fork-based PRs) and is only consequential where a consumer resolves the commit differently - CI auto-running on the PR, a developer checking it out, or a release tarball being built; there is no confirmed active exploitation and no public exploit code identified at time of analysis, with EPSS at 0.16% (4th percentile). Critically, upgrading fixes only new incoming objects - existing repositories are not rescanned, so a malicious tree already stored stays exploitable after the patch.
Fork-originated Gitea Actions workflows can run on a base repository's registered runners without the required approval when a repository maintainer performs ordinary pull request triage, such as adding a label, because the approval decision was keyed to the user who triggered the event rather than the fork pull request author, allowing fork-controlled workflow code to execute in the base repository's CI context. Gitea versions up to and including 1.27.3 are affected when Actions is enabled and a matching runner is registered; the issue is fixed in Gitea 28.0.0. No public exploit code was identified at time of analysis and EPSS is low (0.15%, 3rd percentile), but exploitation is not autonomous: the assessed vector (CVSS:3.1/AV:N/AC:H/PR:L/UI:R/S:U/C:H/I:H/A:H) requires an attacker-submitted fork pull request plus a privileged maintainer action, and CISA SSVC rates the technical impact as total, so the outcome when the prerequisite chain is met is full compromise of confidentiality, integrity, and availability of the workflow execution environment.
Push mirror synchronization in Gitea 1.27.3 and earlier reuses a remote address that was validated against the [migrations] allow/block lists only once, at mirror-creation time, so a hostname that later resolves to a blocked or internal address is still handed to git push - a time-of-check/time-of-use flaw (CWE-367). An authenticated user who administers a repository (which includes any repository they create themselves) can therefore aim a push mirror at an internal Git service and force-push the repository's contents to it, assuming attacker influence over name resolution and a network-reachable internal endpoint. The assessed severity is high (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:N) because scope changes and both confidentiality and integrity of internal Git services are affected, but no public exploit code has been identified at time of analysis and EPSS is low (0.12%, 2nd percentile), with SSVC recording no observed exploitation and a non-automatable attack path - a real but bounded risk rather than a mass-exploitation emergency.
Gitea 1.27.3 and earlier misattributes the pushing identity to the repository owner whenever a git push is authenticated with a repository deploy key, causing the pre-receive hook pipeline to evaluate permissions against the owner rather than the deploy key. An attacker holding a write-enabled deploy key can therefore create protected tags despite not being on the tag allow list, or flip repository visibility (for example private to public) through git push options, and pull requests created via the AGit flow are likewise attributed to the owner. Access is gated: a read-only deploy key is insufficient, exploitation requires an authenticated push (CVSS PR:L), no public exploit code has been identified at time of analysis, EPSS is only 0.15% (3rd percentile), and CISA SSVC rates exploitation as none with partial technical impact.
Server-side request forgery in Gitea 1.27.3 and earlier lets a user who can start a repository migration or mirror reach blocked internal addresses: Gitea validates the destination hostname against its egress allow/block lists before invoking Git, but the Git subprocess resolves the hostname independently when it actually connects, so an attacker who controls the destination's DNS can re-point the name from an allowed address to an internal one between validation and connection. Exploitation requires both the ability to initiate a migration (on a default install this means a logged-in account, and instances with open registration make it effectively unauthenticated) and control of authoritative DNS with suitably short TTLs, which is why the independent assessment rates it CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:L/I:N/A:N rather than the vendor's 7.5. No public exploit code has been identified at time of analysis, EPSS is only 0.15% (3rd percentile), and SSVC records Exploitation: none with partial technical impact; the vendor-released fix is Gitea 28.0.0.
Server-side request forgery in Gitea (versions up to and including 1.27.3) lets a repository administrator bypass the configured outbound host policy: Gitea validates the initial remote URL for push mirrors, wiki remote checks, and migrated pull-request heads, but the raw Git operation that follows will chase an HTTP redirect to an address the policy would otherwise block, causing the server's Git client to reach internal services. Exploitation is meaningfully constrained - it requires repository-administrator privileges, a restrictive egress allow-list must actually be configured, and the attacker must control or locate an allow-listed endpoint that redirects to the desired internal target - so the realized impact is bounded by which internal services are reachable from the Gitea host. EPSS is 0.15% (3rd percentile), no public exploit identified at time of analysis, and there is no CISA KEV listing, so exploitation appears opportunistic and low-volume rather than confirmed actively exploited. Note that the published CVSS vector (7.5, PR:N) overstates the privilege requirement; our assessment rates it PR:L with limited confidentiality and integrity impact.
Gitea Actions in versions up to and including 1.27.3 can execute workflow code from an untrusted fork pull request head on the repository's runners without the maintainer approval that the first-time-contributor gate is supposed to require. An authenticated user holding Actions write permission can cancel a run that is still awaiting approval and then re-run it; the rerun path recreated the attempt's jobs as waiting instead of blocked while the run still recorded that approval was required, so the jobs were released without an approval decision. Signals point to a genuine but not emergency-grade issue: exploitation requires Actions enabled, a registered matching runner, a fork pull request from a first-time contributor, and Actions write access (CVSS PR:L), no public exploit code was identified at time of analysis, and EPSS is low at 0.16% (4th percentile).
Fork-controlled workflow code execution is possible in Gitea (through 1.27.3) when Actions is enabled and a repository runs a shared run-level concurrency group: an attacker who can open a fork pull request plants workflow content in an approval-gated run, a sibling run in the same concurrency group cancels the blocked job and drives the run terminal while it still carries the approval flag, and a later maintainer approval re-queues the already-cancelled job so a matching runner claims and executes it. The independent assessment rates this CVSS:3.1/AV:N/AC:H/PR:L/UI:R/S:U/C:H/I:H/A:H - lower than the 8.8 base figure because the decisive step is a human maintainer approval plus a race against a sibling run and an available accepting runner - and no public exploit code has been identified at time of analysis. No public exploit identified at time of analysis; EPSS is 0.16% (4th percentile) and CISA SSVC records Exploitation: none, Automatable: no, Technical Impact: total.
Authenticated users who are able to open a pull request from a fork can cancel trusted, in-progress Gitea Actions runs in the base repository when those runs share a workflow-level concurrency group with cancel-in-progress enabled, because the cancellation logic does not check whether the newer run still needs approval before terminating the older ones. The attacker runs no code and gains no data access, but on self-hosted runners the interruption can abort an in-flight deployment and leave partial state behind. No public exploit code has been identified at time of analysis and EPSS is low at 0.16% (4th percentile), consistent with a targeted, configuration-dependent CI-disruption issue rather than a broad default-config exposure.
Authentication bypass in Gitea's built-in SSH server (affected releases up to and including 1.27.3) lets a remote attacker authenticate as another user by presenting a case-variant of that user's registered RSA public key. Three conditions must all hold: the built-in SSH server must be enabled via START_SSH_SERVER = true (non-default on many deployments), the backing database must perform case-insensitive text comparison (the default SQLite qualifies), and the attacker must possess or derive a working RSA private key whose public key differs from the victim's only by letter case, which is cryptographically very hard and is why the effort is assessed as high complexity rather than the low complexity of the published vendor vector. No public exploit code identified at time of analysis; EPSS is 0.16% (4th percentile) and the CISA SSVC assessment records exploitation: none. The flaw is fixed in v28.0.0 by matching keys on their SHA256 fingerprint instead of encoded content.
Server-side request forgery in Gitea 1.27.3 and earlier allows an authenticated user with permission to start repository migrations to reach internal services by pointing an allow-listed migration hostname at a loopback or private address, bypassing the ALLOW_LOCALNETWORKS=false restriction. Exploitation requires the optional [migrations] ALLOWED_DOMAINS allow-list to be configured (default installations are unaffected by this specific bypass), valid migration rights (CVSS PR:L, authenticated), and attacker control over DNS resolution for a hostname already present in that allow-list. No public exploit code or confirmed active exploitation was identified at time of analysis; the root-cause class is network-restriction bypass (SSRF-style) rather than an authentication bypass, despite that tag in the source data.
Account takeover in Plane (makeplane) versions prior to 1.4.0 allows remote unauthenticated attackers to log in as existing users by exploiting OAuth email trust in Gitea and self-managed GitLab deployments where email confirmation is disabled. The vulnerability (CWE-287) stems from Plane matching the email returned by the OAuth provider to a local account without verifying provider-side ownership; an attacker can set an OAuth identity's unverified email to the victim's address and authenticate as them without knowing the password, as confirmed by the provided independent assessment. Deployments using GitHub, GitLab.com, or Google OAuth are not affected because those providers return verified emails; no public exploit identified at time of analysis, and the flaw is gated by deployment configuration rather than being universally exploitable.
Server-side request forgery in Plane, the open-source project management tool, allows a low-privilege user of a connected Gitea instance to make the Plane server issue HTTP requests to internal or private addresses. The flaw affects versions prior to 1.4.0 and only manifests when an administrator has explicitly enabled Gitea OAuth and pointed GITEA_HOST at a legitimate Gitea deployment (the feature is off by default); an authenticated Gitea user then sets an internal URL as their profile avatar and logs in through OAuth, causing Plane to fetch that attacker-chosen target without validation. The result is a largely blind SSRF primitive, since the avatar handler only accepts image Content-Types and enforces a size cap, and no public exploit code or active exploitation has been identified at time of analysis.
Workflow-supplied container options in Gitea act_runner (versions before 3.0.0) are merged straight into the Docker HostConfig of the job container, letting a workflow author request host PID/IPC namespaces, CapAdd=ALL and unconfined seccomp/apparmor and then escape to the runner host as root. The twist is that the flaw is exploitable precisely when runner privileged mode is disabled: that code path forces only Privileged=false while preserving namespace, capability, device and security-profile flags from workflow YAML, so the control administrators rely on does not contain the attack. Only the Docker job-container backend is affected, and exploitation requires the ability to submit or trigger a workflow on a repository served by that runner (authenticated, push or pull-request privileges per the PR:L vector), with impact changing scope to the underlying host; no public exploit identified at time of analysis, and EPSS is low at 0.20% (9th percentile), though real-world risk is severe for shared runners open to untrusted workflow authors.
Dokploy instances running versions prior to 0.29.13 disclose stored Git provider secrets - GitHub App private keys, OAuth tokens and client secrets, webhook secrets, and Gitea/Bitbucket access tokens, refresh tokens, and app passwords - to authenticated organization members who were never granted access to those providers. The protected tRPC procedures github.one, gitlab.one, gitea.one, and bitbucket.one return full provider rows without applying getAccessibleGitProviderIds or an organization check, and application.one returns the same secrets as nested relations from findApplicationById even when hasGitProviderAccess is false. Exploitation requires an authenticated Dokploy account (PR:L) holding application read access or knowledge of a provider identifier, and the practical impact is confidentiality: a restricted member can use the leaked credentials to read private repositories or manipulate external CI/CD and webhook workflows. No public exploit code has been identified at time of analysis.
Server-side request forgery in Gitea Open Source Git Server (all versions through 1.26.4) lets attackers abuse the repository migration and mirror features to reach internal network resources. Two distinct weaknesses are involved: a DNS-rebinding bypass where a hostname resolves to a permitted address during validation and to an internal address when the actual request is made, and a missing re-validation flaw where redirect or subsequent fetch targets are not re-checked against the allow/deny policy. No public exploit was identified at time of analysis, EPSS is low (0.15%), and it is not in CISA KEV, but the vendor rates technical impact as total and the issue is fixed in 1.27.0.
Broken access control in Gitea (self-hosted Git service) versions up to and including 1.26.4 lets the team-repository linking endpoint ignore the RepoAdminChangeTeamAccess organization setting, so repository administrators can grant or alter team access to repositories even when an org owner has explicitly restricted that ability. This CWE-862 missing-authorization flaw undermines an intended org-level guardrail, exposing private repository contents (C:H) and permitting unauthorized permission changes (I:H). No public exploit has been identified at time of analysis, and the EPSS probability is low (0.15%, 5th percentile).
Authenticated command injection in Dokploy (self-hostable PaaS) versions 0.29.3 through 0.29.12 lets a low-privileged user achieve arbitrary host command execution by storing a malicious Git branch value and triggering a deployment. The branch fields (customGitBranch, branch, gitlabBranch, bitbucketBranch, giteaBranch) were left without server-side validation because the earlier fix for CVE-2026-45628 was incomplete, so attacker-controlled input flows unescaped into shell-based git clone commands. No public exploit has been identified at time of analysis, but the flaw carries a CVSS of 9.9 and is fixed in 0.29.13.
SSRF protection bypass in Gitea prior to 1.27.0 exposes internal services, cloud instance-metadata endpoints (e.g., AWS IMDSv1 at 169.254.169.254), and local files - including the application configuration containing database credentials and signing secrets - to authenticated attackers. Three HTTP fetch code paths in the migration and OAuth avatar subsystems use Go's raw http.Get() rather than the hardened hostmatcher.NewDialContext() transport used elsewhere, completely circumventing Gitea's built-in SSRF defenses. A publicly available proof-of-concept is included in the GHSA advisory; no confirmed active exploitation (CISA KEV) has been identified at time of analysis.
Server-side request forgery in Gitea ≤1.26.4 allows privileged users to bypass the platform's own hostmatcher SSRF defenses via three unprotected raw http.Get() code paths in the migration and OAuth avatar subsystems, enabling retrieval of cloud instance metadata (AWS IMDSv1, GCP tokens), local file read (e.g., app.ini with database credentials and JWT secrets), and internal network scanning. A detailed proof-of-concept exploit is publicly available in the GitHub Security Advisory GHSA-2wm4-vwp6-v7xc. EPSS is low at 0.16% (6th percentile), consistent with the privilege requirements limiting opportunistic exploitation, but the disclosed PoC and the sensitivity of reachable data elevate real-world risk for cloud-hosted deployments. No active exploitation is confirmed in CISA KEV at time of analysis.
Private organization member enumeration in Gitea allows any authenticated user to retrieve the full member roster - including emails - of a private organization via the /api/v1/orgs/{org}/members endpoint. The root cause is an incomplete fix: PR #38145 added visibility guards to ListPublicMembers and IsPublicMember but omitted the same guard from ListMembers, leaving a single missing HasOrgOrUserVisible check in routers/api/v1/org/member.go. Proof-of-concept code is publicly available in the GitHub Security Advisory; no active exploitation has been confirmed in CISA KEV, and the EPSS score of 0.16% (5th percentile) indicates low probability of widespread automated exploitation.
Server-side request forgery in Gitea before 1.27.0 lets attackers coerce the server into HTTP requests against internal hosts because its outbound IP allow-list classifier (IsGlobalUnicast && !IsPrivate) fails to block CGNAT (100.64.0.0/10) and nine IPv6 transition prefixes. An authenticated user can point a webhook or repo migration at an internal CGNAT service and read the full response (status, headers, and up to 1 MB body) rendered back on the hook detail page; separately, when OpenID sign-in is enabled the unauthenticated /user/login/openid discovery fetch uses http.DefaultClient with no IP filtering, giving anonymous internet callers a blind SSRF primitive. Publicly available exploit code exists (bundled run_poc.sh reproduces all three primitives), but no active exploitation is confirmed.
Unauthenticated denial of service in Gitea's Locale middleware allows any remote attacker to consume ~2 seconds of server CPU per HTTP request by crafting a ~1 MiB Accept-Language header composed of underscore separators, bypassing the existing CVE-2022-32149 guard in golang.org/x/text which only counts dash characters. All Gitea releases from 1.22.x through 1.26.x are affected because the middleware at modules/web/middleware/locale.go:38 passes the raw, unfiltered header directly to the quadratic-time ParseAcceptLanguage parser; ten concurrent attackers consuming ~10 MiB/s of upstream bandwidth can saturate all cores of a ten-core host indefinitely. Publicly available exploit code exists in the GHSA advisory; no active exploitation has been confirmed by CISA KEV at time of analysis.
Repository visibility and template status in Gitea (self-hosted Git service) before 1.27.0 can be silently toggled by any repository owner or admin-collaborator through undocumented git push options (repo.private, repo.template) processed by the post-receive hook, bypassing all audit logging, webhooks, and notifications. An insider can flip a private repository to public long enough to clone proprietary code, then revert it, leaving only two ordinary push events in the activity feed. No CISA KEV listing and no separately published exploit tool exist, but the GHSA advisory ships full working reproduction commands, and the CVSS 3.1 base score is 7.1 (High).
Improper authorization in Gitea before 1.27.0 lets an administrator-deactivated user (IsActive=false) silently reactivate their own account by signing in through an OAuth2/OIDC source that issues no refresh token - notably GitHub, or any OIDC source without offline_access. The reactivation gate added in PR #38009 uses an empty stored refresh token as its signal for 'disabled by auto-sync cron,' but for these sources every user has an empty refresh token, so an administrator's deliberate deactivation is indistinguishable from a cron disable and gets undone on the next login, granting a full session (including regained admin rights, since deactivation does not clear IsAdmin). No public exploit code is packaged, but a detailed, reproducible proof-of-concept is published in the vendor advisory; not listed in CISA KEV.
Identity-claim disclosure in Gitea (self-hosted Git server) before 1.27.0 lets any holder of a valid personal access token retrieve their email and organization/team membership from the OIDC userinfo endpoint (GET /login/oauth/userinfo) even when the token's scopes (e.g. only read:misc) would deny the equivalent REST API calls. The endpoint accepts API tokens as bearer credentials but skips the scope enforcement applied elsewhere, collapsing the authorization boundary that scoped tokens are meant to provide. Publicly available exploit code exists; the flaw is not in CISA KEV and EPSS is low (0.17%).
Improper TLS certificate validation in Gitea versions prior to 1.27.0 lets an on-path attacker intercept the internal API channel and steal the static, high-privilege INTERNAL_TOKEN. The internal API HTTP client (modules/private/internal.go) hardcodes InsecureSkipVerify:true with no config override, so gitea serv / gitea hook subprocesses accept any certificate when LOCAL_ROOT_URL uses HTTPS to a non-loopback host. A detailed proof-of-concept is published in the vendor advisory, but there is no evidence of active exploitation; the token grants full control over every /api/internal/* endpoint, including server shutdown, SSH key authorization, and arbitrary git command execution.
Gitea's REST API leaks private organization membership through the `GET /orgs/{org}/public_members/{username}` endpoint, bypassing the visibility controls that correctly conceal this information in the web UI. All versions up to and including 1.26.4 are affected, permitting any user with a valid API token to confirm whether a specific user belongs to a hidden organization - data intentionally withheld from the web interface. No public exploit is confirmed in CISA KEV, though a detailed proof-of-concept with curl commands is documented in GHSA-jr5x-6h83-wrxf; EPSS stands at 0.16% (5th percentile), indicating low observed exploitation probability.
Gitea's Actions permission engine grants fork-PR task tokens unauthorized code-read access to third private repositories via a missing fork-PR discriminator in the collaborative-owner branch of `GetActionsUserRepoPermission`. All Gitea instances running versions up to and including 1.26.4 are affected when the collaborative-owner Actions feature is configured, as confirmed by vendor advisory GHSA-fj8v-hjwv-qm88 and EUVD-2026-58151. An attacker who has had at least one fork PR previously approved can exploit this to clone the full source of a private repository they were never authorized to access; impact is strictly read-only, with no write or code-execution capability. A functional PoC was included in the security advisory; this CVE is not in the CISA KEV catalog and no EPSS score was provided in the available data.
Broken authorization in Gitea (self-hosted Git server) versions before 1.27.0 lets a token scoped as public-only,write:repository push commits into a private pull-request head branch it should never touch. Because Gitea only evaluates the public-only restriction against the public base repository named in the route (POST /api/v1/repos/{owner}/{repo}/pulls/{index}/update) and never re-applies it to the private head repository, an attacker holding such a token can force a server-side write into the private repo and, where Actions is enabled, trigger its push workflow. This is CWE-863 incorrect authorization; a publicly available exploit code exists in the vendor advisory, EPSS is low at 0.24%, and it is not listed in CISA KEV.
Privilege escalation in Gitea's self-hosted Git service (all versions ≤ 1.26.4) lets an attacker holding a narrowly-scoped Personal Access Token mint a new token with any scope, including full 'all' access, without the account password. The POST /users/{username}/tokens endpoint is guarded by reqBasicOrRevProxyAuth, which is meant to force password auth, but supplying the token as Authorization: Basic base64(<token>:x-oauth-basic) tricks the guard into setting IsBasicAuth=true, and the token-creation handler enforces no scope ceiling. A working proof-of-concept integration test is published in the advisory, though there is no public exploit identified in the wild and EPSS is low (0.16%).
Persistent account takeover in Gitea (self-hosted Git service) versions up to and including 1.26.4 arises because a stolen Remember-Me cookie is never revoked after theft is detected. When the split-token (ID:Hash) design detects a hash mismatch - the canonical signal of a compromised token per the Paragonie remember-me guidance - CheckAuthToken only returns ErrAuthTokenInvalidHash and autoSignIn merely clears the victim's local cookie, leaving the attacker's rotated token live in the database. The result is indefinite attacker access to the victim's account. Fixed in 1.27.0; no public exploit identified at time of analysis, and EPSS is low at 0.16%.
Authorization bypass in Gitea before 1.27.0 lets a public-only Personal Access Token read internal content owned by Limited-visibility users and organizations, exceeding the reach the scope is meant to grant. The Repository and Package scope categories only test repo.IsPrivate / Owner.Visibility.IsPrivate(), which return false for VisibleTypeLimited, so an authenticated attacker with a public-only PAT can fetch READMEs, repo content, packages from all 24 registries, and even perform full git-upload-pack clones of instance-internal projects. A vendor-verified end-to-end Docker PoC exists (publicly available exploit code exists); it is not in CISA KEV and EPSS is low at 0.17% (6th percentile). This is the residual gap left after CVE-2026-25714 / PR #37118 fixed the sibling User/Org/ActivityPub cases.
Branch protection bypass in Gitea versions prior to 1.27.0 allows a user with write (non-admin) access to merge unauthorized code into a protected branch by exploiting a stale approval flag. When a pull request is retargeted from an unprotected branch to a protected one via ChangeTargetBranch, Gitea fails to re-evaluate the stored official=true flag on existing approvals, so an approval that was never valid under the protected branch's whitelist still satisfies its required-approvals gate. Publicly available exploit code exists (a detailed step-by-step PoC in the GHSA advisory); no public exploit identified as actively used and it is not in CISA KEV.
Server-side request forgery and internal repository exfiltration in Gitea before 1.27.0 lets a low-privileged authenticated user bypass the migration URL allow/block list by supplying a permitted public Git URL that HTTP-redirects the server's git subprocess to an otherwise-blocked internal endpoint. Because Gitea validates only the originally submitted URL while git runs with its default http.followRedirects=initial, the redirected internal Git repository is cloned into an attacker-controlled repository, and pull mirrors keep re-fetching it on schedule. No public exploit identified at time of analysis; a vendor-authored local proof-of-concept confirmed the redirect is followed to 127.0.0.1, and EPSS/KEV data were not supplied.
Cross-repository information disclosure and cross-task tampering in Gitea's self-hosted Git server (fixed in v1.26.2) arises from an HMAC signature ambiguity in the Actions Artifacts V4 signed-URL scheme, letting an authenticated low-privilege user reuse a validly signed URL outside its intended repository or task context. An attacker with access to a single Actions task can read private artifacts belonging to other repositories and write upload-state for tasks they do not own, crossing the repository trust boundary (CVSS 9.6, scope-changed). There is no public exploit identified at time of analysis, and it is not listed in CISA KEV.
Authorization bypass in Gitea's Gitea Actions fork pull-request approval gate lets a low-privileged contributor permanently defeat the maintainer approval step that normally guards workflow execution on fork PRs, so that after the initial gate is subverted the attacker's workflow code runs against the repository's CI runners and secrets. CVSS is 8.9 (high) with a scope change and high integrity/availability impact; no public exploit has been identified at time of analysis, but a vendor patch (v1.26.4) is available. The flaw is classed as CWE-285 (Improper Authorization) and was self-reported by the Gitea project.
Authentication bypass in Gitea's Git LFS (Large File Storage) SSH handling allows a low-privileged authenticated user to read files from private repositories they should not access by supplying a malformed SSH sub-verb, per the Gitea security advisory GHSA-7wvc-rvp7-w99x. Because the flaw crosses a security boundary (CVSS scope change) it exposes confidential repository contents without any integrity or availability impact. No public exploit has been identified at time of analysis, and it is not listed in CISA KEV, but a vendor patch is available in Gitea 1.26.4.
Authorization bypass in Gitea Open Source Git Server (versions up to and including 1.26.1) allows a user whose account was deliberately disabled by an administrator to silently regain access simply by signing in through a linked OAuth provider. The OAuth sign-in callback fails to honor the administrator's 'disabled' flag, effectively reversing an intended access-revocation action. EPSS is low (0.16%, 6th percentile) and there is no public exploit identified at time of analysis, but the flaw undermines a core account-lifecycle control on a widely self-hosted platform.
Denial of service in Gitea, the self-hosted open-source Git service, allows a remote unauthenticated attacker to exhaust server CPU by triggering catastrophic backtracking in the regular-expression engine that evaluates CODEOWNERS pattern matching. All versions prior to the fixed 1.26.3/1.26.4 releases are affected, and the CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N, A:H only) confirms network-reachable, low-complexity, no-authentication abuse with availability-only impact. There is no public exploit identified at time of analysis and EPSS is low (0.16%, 6th percentile), so exploitation risk is real but not yet widespread.
Information disclosure in Gitea Open Source Git Server (through 1.26.2) allows a user whose repository access has been revoked to continue viewing private issue metadata via the Notification API, because notification records are not purged or re-authorized when permissions change. The CVSS 3.1 base score is 7.5 (C:H) and the vendor (Gitea) fixed it in 1.26.3/1.26.4. No public exploit identified at time of analysis, and EPSS is low (0.17%, 7th percentile), indicating limited near-term exploitation likelihood.
Broken authorization in Gitea (self-hosted Git service) versions up to and including 1.26.2 lets a user who holds general repository access but has NOT been granted the Code unit permission read private source content by reusing Git LFS objects to authorize otherwise-restricted source objects. The flaw (CWE-639, tracked as GHSA-2m9v-5q2g-58vq) enables horizontal privilege escalation to confidential code within a repository. There is no public exploit identified at time of analysis and it is not listed in CISA KEV, but a vendor patch shipped in 1.26.3.
Branch-protection bypass in Gitea's self-hosted Git server (all versions before 1.26.0) allows a user with push access to circumvent pre-receive hook enforcement by supplying oversized hook input that trips a bufio.Scanner error the code fails to handle safely. Because Gitea does not fail closed on the scanner error, the protection check is silently skipped and the push is accepted. No public exploit identified at time of analysis; EPSS is low (0.17%, 7th percentile) and this is not in CISA KEV, but a vendor patch (v1.26.0) is available.
Canonical URL spoofing in Gitea before 1.25.5 lets remote attackers inject malformed X-Forwarded-Proto values that the server trusts when computing its public-facing URL, causing it to emit attacker-controlled canonical links (e.g. in emails, redirects, and generated absolute URLs). No public exploit identified at time of analysis, and the low EPSS score (0.17%, 6th percentile) reflects minimal in-the-wild interest, but a vendor patch is available in v1.25.5. Note that the published CVSS vector claims availability impact (A:H) while the description describes URL spoofing (an integrity concern), a discrepancy worth verifying with the vendor.
Privilege escalation in Gitea 1.25.5 lets a user holding a per-branch maintainer-edit grant reuse that write permission against other refs and obtain full repository write access. The flaw stems from a branch-specific permission result being cached and incorrectly reused across multiple refs within a single pre-receive hook session. It is an authenticated authorization-bypass (CWE-863) fixed in Gitea 1.26.3; no public exploit has been identified and EPSS exploitation probability is low (0.20%).
Broken access control in Gitea's Composer package registry (versions up to and including 1.26.1) lets remote attackers read private or internal Composer package source links they should not be authorized to see, leaking internal repository/source metadata. The flaw is a missing-authorization (CWE-862) issue reported by the Gitea project itself and fixed in v1.26.2; no public exploit identified at time of analysis, and it is not listed in CISA KEV. With a CVSS 3.0 base score of 8.2 driven by high confidentiality impact, the practical effect is unauthorized disclosure of otherwise-private package sourcing information.
Broken access control in Gitea before 1.25.5 lets clients retrieve draft release metadata and their attached files through the REST API without holding the repository write permission those drafts are meant to require. The flaw stems from the API omitting a token-scope/write-access check on draft release and attachment endpoints, so read-scoped tokens (and, on publicly readable repositories, unauthenticated callers) can enumerate and download unpublished release content. There is no public exploit identified at time of analysis, EPSS risk is low (0.17%, 6th percentile), and it is not on CISA KEV.
Broken object-level authorization (IDOR) in Gitea before 1.25.5 lets an authenticated user manipulate the primary email address of an arbitrary other account by supplying an email row ID they do not own. The account-settings 'make primary' handler looked up the target email by ID alone without verifying ownership, so a logged-in attacker can alter another user's primary email - an integrity impact with account-hijack and notification-redirection potential. There is no public exploit or active exploitation, EPSS is low (0.17%), and Gitea has shipped a fix in 1.25.5.
Uncontrolled resource consumption in Gitea before 1.25.5 allows remote attackers to exhaust server CPU by triggering unbounded 'git grep' code searches that ran without any execution timeout. Because the search endpoint is network-reachable and the CVSS vector (PR:N) indicates no authentication is required, an attacker can repeatedly submit expensive regex/pattern searches against hosted repositories to degrade or deny service. No public exploit identified at time of analysis, and EPSS is low (0.18%), but SSVC marks the flaw as automatable with partial technical impact.
Migration transport protections in Gitea are bypassed for Git LFS operations, affecting all self-hosted instances before version 1.25.5. Because LFS push and sync-mirror requests instantiated their client with a nil HTTP transport (lfs.NewClient(endpoint, nil)) instead of the hardened migration transport, LFS traffic escaped the allowlist/SSRF restrictions the migration transport enforces, letting a user who can configure a repository mirror direct LFS requests to otherwise-blocked destinations. There is no public exploit identified at time of analysis and EPSS is low (0.17%), but SSVC rates technical impact as total and automatable, and a vendor patch is available.
OAuth2 PKCE protection bypass in Gitea before 1.25.5 allows remote attackers to complete an authorization-code token exchange without a valid code verifier because the server fails to persist the S256 challenge method during authorization. Rated CVSS 9.1 with SSVC technical impact of 'total', though EPSS is low (0.17%, 6th percentile) and there is no public exploit identified at time of analysis. The fix is confirmed in release v1.25.5 (PRs 36462 and 36477), which was reported by the Gitea project itself.
Authentication bypass via OAuth2 authorization code replay in Gitea before 1.25.5, where the server fails to consistently enforce code expiry and single-use during the token-exchange step, letting an attacker who obtains a valid authorization code redeem it (potentially more than once, and after it should have expired) to mint access tokens for a victim's account. The source fix confirms authorization codes previously had no enforced 10-minute validity window and that double-redemption was not reliably detected. EPSS is low (0.17%, 6th percentile) and CISA SSVC lists exploitation status as none, but SSVC rates the technical impact as total and marks it automatable; no public exploit identified at time of analysis.
Arbitrary file read and write in Gitea before 1.25.5 arises when the template repository generation feature resolves paths through symlinks or other non-regular file types instead of restricting itself to regular files within the target root. An attacker who controls a template repository can plant symlinked or special paths so that generation reads sensitive files or writes attacker-controlled data outside the intended boundary, yielding high confidentiality and integrity impact (CVSS 9.1). There is no public exploit identified at time of analysis, the EPSS probability is low (0.17%, 7th percentile), and CISA SSVC records exploitation as 'none', but the flaw is automatable with total technical impact.
Improper access control in Gitea's organization permission API (all releases before 1.25.5) lets an authenticated API caller query permission and membership details for hidden organization members and private organizations they should not be able to see. The root cause is a visibility check performed against the target user instead of the requesting user, disclosing metadata that reveals otherwise-concealed org membership and permission levels. This is an information-disclosure/access-control issue (CWE-284) with no public exploit identified at time of analysis, a low EPSS (0.16%, 5th percentile), and SSVC exploitation status of 'none'.
Information disclosure in the Gitea 1.26.2 self-hosted Git service allows non-members to read the labels of private organizations via the Organization Labels API, exposing label metadata (id, name, description, color, url) that should be restricted to org members. The authorization gap affects GET /api/v1/orgs/{org}/labels and .../labels/{id} only, while organization info, teams, hooks, and secrets endpoints correctly returned 404 to the same user. Publicly available exploit code exists in the vendor GHSA advisory, though EPSS risk is low (0.20%, 10th percentile) and it is not on CISA KEV.
Improper access control in Gitea before 1.25.5 allows users to update or rebase pull request head branches without holding the write/force-push permissions those actions require, letting them push base-branch commits or rewrite history on branches they should not control. The flaw stems from the IsUserAllowedToUpdate logic in services/pull/update.go, which failed to properly re-check repository push and branch-protection permissions on the head branch. This is an integrity-only issue (CVSS 7.5, I:H) with no confidentiality or availability impact; SSVC lists exploitation as none and EPSS is low (0.16%), and no public exploit identified at time of analysis.
Information disclosure in Gitea 1.26.2 lets a fork owner keep pulling commits from a parent repository via the merge-upstream API even after the parent was switched from public to private, exposing content the fork should no longer be authorized to see. The flaw stems from the synchronization endpoint failing to re-check the parent's current visibility, so data added during the private period leaks into a fork whose owner can no longer directly access the parent. A working proof-of-concept is publicly published and CISA SSVC rates exploitation automatable, but the issue is not on CISA KEV and EPSS is low (0.20%); it is fixed in Gitea 1.26.3.
Server-side request forgery in Gitea versions up to and including 1.26.2 lets authenticated users abuse incomplete allow-list filtering in the webhook and repository-migration features to coerce the server into making requests to internal or otherwise restricted network destinations. Because the existing SSRF protection is incomplete rather than absent, attackers can craft addresses that bypass the allow-list checks to reach services that should be unreachable from outside. No public exploit identified at time of analysis, and the flaw is not listed in CISA KEV; a vendor patch is available in Gitea 1.26.3.
Improper input validation in Gitea Open Source Git Server before 1.25.5 lets authenticated users submit repository-creation requests with unbounded template fields (issue labels, license, readme, fork branch) and unsupported trust-model or object-format values. The upstream fix (PRs 36671/36757) adds MaxSize length constraints and rejects any ObjectFormatName that is not sha1 or sha256. Rated CVSS 9.1 by the reporter, but no public exploit was identified, EPSS is only 0.17% (6th percentile), and CISA SSVC records exploitation status as none.
Reverse-proxy authentication bypass in the official Gitea Docker image (versions up to and including 1.26.2) allows any source IP to impersonate arbitrary users because the image ships with REVERSE_PROXY_TRUSTED_PROXIES=* by default. When an operator enables reverse-proxy header authentication (e.g. X-WEBAUTH-USER), the wildcard trust list means Gitea accepts those identity headers from any client rather than only from a trusted front-end proxy, granting full account takeover including administrator access. No public exploit has been identified at time of analysis, and the issue is patched in Gitea 1.26.3.
TOTP two-factor authentication replay in Gitea 1.5.0 through 1.26.2 lets a captured valid one-time code be accepted multiple times instead of being invalidated after first use, weakening 2FA on both the web login flow and the Basic Auth X-Gitea-OTP header path. An attacker who observes a legitimate TOTP code (via interception, shoulder-surfing, or logging) can replay it within its validity window to authenticate as the victim. There is no public exploit identified at time of analysis and it is not listed in CISA KEV; the flaw is fixed in Gitea 1.26.3.
Approval-gate bypass in Woodpecker CI before 3.15.0 lets an attacker who can open a merge request from a fork against a GitLab-backed repository run unapproved, attacker-controlled pipelines. Because the GitLab forge driver populates pipeline.Author from the spoofable git commit author name (commit.author.name) rather than the GitLab-validated user identity, an attacker simply sets the commit author to a name listed in ApprovalAllowedUsers, making needsApproval return false. This grants arbitrary CI step execution on a Woodpecker agent and exposure of CI secrets; there is no public exploit identified at time of analysis, but the issue was reported by VulnCheck and is trivially reproducible.
Container escape in Gitea act_runner (Docker backend, through act 0.262.0) lets an authenticated user with workflow-execution rights break out to the host as root even when privileged mode is disabled. The runner passes a workflow's container.options string straight into the Docker job container's HostConfig and only forces the Privileged flag off, leaving dangerous options like --pid=host, --cap-add, and --security-opt intact. Publicly available exploit code exists (reported by VulnCheck), though it is not listed in CISA KEV.
Stored cross-site scripting in Gitea 1.25.x affects the built-in 3D file viewer (Online3DViewer integration) where a crafted .gltf file with an unsupported extension name in extensionsRequired is rendered into the DOM via innerHTML without sanitization. Any low-privileged user who can push a file to a repository (including a public fork) can compromise the session of any user who later views the file, enabling token theft and full account takeover. Publicly available exploit code exists (a working PoC is included in the GHSA-9cpj-qc93-vw8v advisory); no public exploit identified at time of analysis in CISA KEV.
Authorization bypass in Gitea versions 1.22.3 through 1.26.1 allows holders of `public-only` access tokens or OAuth grants to read and modify private account resources via `/api/v1/user/...` self routes, despite the public-only flag being designed to restrict tokens to public data. The flaw is a systemic scope-boundary failure across many self routes (SSH keys, emails, OAuth apps, Actions secrets/variables/runners, private repos, webhooks), publicly available exploit code exists in the form of reproducible Go PoCs in the advisory, and the issue represents an incomplete fix of CVE-2025-68941 in a different route family.
Authorization bypass in Gitea versions prior to 1.26.0 lets a read-only organization member create repositories in the organization namespace via the API fork endpoint, despite a team configuration that denies repository creation (can_create_org_repo=false). Because the fork creator receives admin rights on the resulting repo, the attacker can enable Actions and push a workflow that exfiltrates all organization-level CI/CD secrets (deploy keys, cloud credentials, API tokens). Publicly available exploit code exists in the GHSA advisory with a full step-by-step PoC; no public exploit identified at time of analysis beyond the reporter's reproduction.
Authorization bypass in Gitea versions up to and including 1.26.1 allows any authenticated user with mere read access to push arbitrary commits directly to any repository they can view, including all public repositories on the instance. The flaw stems from the 'Allow edits from maintainers' pull request flag being trusted without verifying the PR submitter actually owns write access on the HEAD side, enabling reverse-fork PRs to grant unauthorized push rights to upstream targets. Publicly available exploit code exists (a working poc.py is attached to the advisory), and the issue is fixed in Gitea 1.26.2.
OAuth2 scope enforcement bypass in Gitea <= 1.26.1 allows any OAuth2 access token to perform write actions far beyond its granted scope when submitted via HTTP Basic authentication instead of as a Bearer token. A token issued with only `read:user` can modify user settings, add attacker-controlled emails, and create or delete the user's repositories, effectively nullifying the entire OAuth2 scope model for Basic-auth requests. No public exploit identified at time of analysis, but the advisory itself contains a full working PoC.
Authorization scope bypass in Gitea v1.26.1 and earlier allows authenticated users to use OAuth2/PAT Bearer tokens to perform Git Smart HTTP clone, fetch, and push operations on private repositories without holding the required read:repository or write:repository token scopes. The flaw stems from CheckRepoScopedToken() short-circuiting unless ctx.IsBasicAuth is true, while the same route accepts Bearer authentication. No public exploit identified at time of analysis beyond the reporter's PoC test in the GHSA advisory.
Gitea fails to validate repository ownership when linking attachments to releases, allowing users to attach files from one repository to releases in another.
Gitea fails to validate repository ownership when deleting Git LFS locks, allowing users with write access to one repo to delete LFS locks in other repositories.
Gitea does not properly validate project ownership in organization operations, allowing users with project write access to manipulate projects belonging to other organizations.
Gitea fails to properly validate repository ownership when processing attachment deletion requests, allowing an authenticated attacker to delete files from repositories they no longer have access to by routing deletion requests through a different accessible repository. This authorization bypass affects all users who have uploaded attachments to shared repositories and could result in loss of critical project documentation or resources. A patch is available to address this improper access control vulnerability.
Gitea before 1.16.7 does not escape git fetch remote. Rated high severity (CVSS 7.5), this vulnerability is remotely exploitable, no authentication required, low attack complexity. Public exploit code available.
The git hook feature in Gitea 1.1.0 through 1.12.5 might allow for authenticated remote code execution in customer environments where the documentation was not understood (e.g., one viewpoint is that. Rated high severity (CVSS 7.2), this vulnerability is remotely exploitable, low attack complexity. Public exploit code available and no vendor patch available.
Gitea on Alpine Linux received a security fix packaged as gitea-1.27.3-r0, indicating an unspecified vulnerability was patched in this self-hosted Git service. The nature of the flaw, attack vector, and achievable impact are entirely undisclosed in available intelligence - only the corrected Alpine package version is confirmed. No CVSS score, CWE class, or vulnerability description accompanies this entry, making meaningful risk characterization impossible without additional vendor disclosure.
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.
Gitea versions 1.16.0 through 1.27.1 contain an authentication-logic flaw in which the sign-in, OAuth2 account-linking, and OpenID connect flows enforce a second factor by checking only for TOTP enrollment (HasTwoFactorByUID) and ignoring registered WebAuthn/passkey credentials, so an attacker who already holds valid primary credentials for a WebAuthn-only account can complete login or link an external identity without ever satisfying the second factor. Because exploitation presupposes a compromised password or a linkable external OAuth2/OpenID identity and only affects accounts whose sole second factor is WebAuthn with no TOTP enrolled, this is a second-factor bypass rather than a standalone remote takeover, which is consistent with the independently assessed CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H (high complexity) rather than the headline 9.8. There is no CISA KEV entry and no public exploit identified at time of analysis, and EPSS is low at 0.17% (6th percentile), so the practical risk is concentrated in deployments that rely exclusively on passkeys for MFA and in environments where primary credentials are already exposed.
Code injection in Gitea's Actions workflow handling can let a low-privileged authenticated user who can open a pull request cause workflow content to be executed from the wrong commit in pull_request_target runs, potentially running attacker-influenced workflow code in a privileged context. Gitea 1.19.0 through 1.27.1 are affected; fixed releases are Gitea 1.27.2 and Alpine package 1.27.3-r0. Exploitation is gated on Gitea Actions being enabled and a repository defining a pull_request_target workflow, EPSS is low at 0.22% (12th percentile), and no public exploit was identified at time of analysis.
Incorrect privilege assignment in Gitea (all versions through 1.26.4) causes scoped API/OAuth2/basic-auth/HTTP-signature tokens to be trusted beyond the scope they were issued for, so any authenticated user who can mint a token can read and modify resources the token was never meant to reach, including private-release drafts, package-registry endpoints, go-get and git-over-HTTP repository access. The CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:N/C:H/I:H/A:N, 8.1) confirms the attacker must already hold a valid account and credential, and the flaw is a silent authorization bypass rather than a pre-authentication compromise. Upstream patched the token-scope plumbing in Gitea 1.27.2 (Alpine ships the fix as gitea 1.27.3-r0); EPSS is only 0.24% (14th percentile) and no public exploit code or CISA KEV entry was identified at time of analysis.
Path traversal in Gitea's Org-mode (`.org`) markup renderer allows an attacker who can get Org-mode content rendered by the server to read arbitrary files from the Gitea host filesystem, through abuse of the `#+INCLUDE:` directive. Affected releases are Gitea 1.22 through versions prior to 1.27.1 (including the Alpine Linux `gitea` package, fixed in 1.27.1-r0); publicly available exploit code exists, and vendor patches are available. The input's 9.8 CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H) overstates the issue relative to our independent assessment (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N), which characterizes this as an authenticated arbitrary file disclosure rather than unauthenticated remote code execution with full integrity and availability impact. No CISA KEV entry was provided, so active exploitation is not confirmed.
Gitea 1.27.1 and earlier can complete an external OAuth2/OpenID account-linking flow without satisfying the second authentication factor, letting an attacker who already holds a victim's primary credentials bind their own external identity to the victim's account and ride that link past TOTP/WebAuthn protection. The defect is a missing critical step in the authentication sequence (CWE-304): the linking code only checked for TOTP enrollment, so users protected solely by WebAuthn were treated as having no 2FA and the link was committed before any second factor was answered. Exploitation requires a Gitea instance configured with external OAuth2/OpenID sources and account linking, plus valid primary credentials for a 2FA-enrolled target account (authenticated, PR:L); there is no public exploit identified at time of analysis, no CISA KEV listing, and EPSS is low at 0.20% (9th percentile), consistent with a targeted, credential-dependent attack rather than mass scanning.