Vulnerabilities
All
My stack
Known exploited
Public exploit
Critical (9+)
Likely exploited (EPSS ≥ 50%)
Changed, 24 h
New, 24 h
Sort:
risk
modified
published
CVSS
EPSS
| CVE | CVSS | EPSS | Vendor, product | Description | Modified |
|---|---|---|---|---|---|
| CVE-2026-27657 | 7.5 high | 0.00% | no CPE yet | Gitea versions before 1.25.5 allow a user to change another user's primary email address. | Sun 25 Oct |
| CVE-2026-27660 | 7.5 high | 0.00% | no CPE yet | Gitea versions before 1.25.5 allow draft release data or attachments to be accessed without the required write permission. | Sun 25 Oct |
| CVE-2026-109553 | 7.5 high | 0.00% | no CPE yet | Gitea resolved the principals of an SSH certificate by searching the content of all stored public keys instead of only principal keys. When Gitea trusts a user certificate authority (`SSH_TRUSTED_USER_CA_KEYS`) and accepts arbitrary principals (`SSH_AUTHORIZED_PRINCIPALS_ALLOW=anything`), a user could register another user's public key line as their own principal, or a holder of a certificate signed by that authority could list it, and then authenticate as the owner of that key through the HTTP signature API and the built-in SSH server. Instances that do not trust a user certificate authority are not affected. | 19 Oct |
| CVE-2026-73539 | 7.5 high | 0.00% | no CPE yet | Gitea substitutes a URL derived from the markup Context field into external renderer command templates without escaping the reference path before shell-style argument splitting. A crafted Context can inject additional renderer arguments, including options that load executable filter files. On deployments using a susceptible external renderer such as pandoc, a user who can place a filter file at an accessible path can cause it to execute as the Gitea service account; the public repository markup endpoint itself can be reachable without authentication. | 18 Oct |
| CVE-2026-103670 | 7.5 high | 0.00% | gitea | When a Gitea Actions run was inserted, older runs in the same workflow-level concurrency group were cancelled without checking whether the new run still needed approval. Because fork pull request runs are inserted under the base repository, a user who can open a pull request from a fork could cancel trusted in-progress runs that share a concurrency group with `cancel-in-progress` enabled, without approval and without running any code. On self-hosted runners this can interrupt deployments and leave partial state behind. | 15 Oct |
| CVE-2026-104636 | 7.5 high | 0.00% | gitea | Gitea validated the initial remote URL for push mirrors, wiki remote checks, and fetches of migrated pull request heads, but the subsequent raw Git operations followed HTTP redirects without revalidating the destination. A repository administrator using a policy-allowed endpoint that redirects could make Gitea's Git client send requests to an address that the outbound host policy would otherwise block. The impact depends on the configured policy and the internal services reachable from the server. | 13 Oct |
| CVE-2026-70357 | 7.5 high | 0.00% | gitea | Gitea validates a repository migration hostname against its network allow and block lists before invoking Git, but the Git subprocess independently resolves the hostname when connecting. An attacker who can start a migration and control the destination's DNS can change the address between validation and connection to reach a blocked internal address. The affected path is the Git clone operation; validation in the migration HTTP client's dialer does not protect the independently connecting Git subprocess. | 13 Oct |
| CVE-2026-96399 | 7.5 high | 0.00% | gitea | A repository's external issue tracker regular expression containing alternating capture groups could produce invalid slice indexes when Gitea rendered issue references, causing a runtime panic that terminated the Gitea process. A user who can edit a repository's external issue tracker settings could make any later rendering of matching content, such as viewing a README, crash the instance for all users. | 13 Oct |
| CVE-2026-96580 | 7.5 high | 0.00% | gitea | Gitea expanded a workflow's static `strategy.matrix` into its full Cartesian product without a size limit when creating a run, before the fork pull request approval gate applied. A user who can open a pull request from a fork could submit a small workflow file whose matrix expands to a very large number of jobs, consuming server memory and potentially terminating the Gitea process. No runner is required. Static matrices above 256 combinations are now rejected before expansion. | 13 Oct |
| CVE-2026-20779 | 7.1 high | 0.00% | no CPE yet | Gitea versions from 1.5.0 before 1.26.3 have a TOTP single-use enforcement defect that allows a valid TOTP code to be accepted more than once across web two-factor authentication flows and the Basic Auth X-Gitea-OTP path. | Sun 25 Oct |
| CVE-2026-28740 | 7.1 high | 0.00% | no CPE yet | Gitea versions up to and including 1.26.2 allow Git LFS object reuse to authorize private source objects for users who have repository access but lack Code-unit access. | Sun 25 Oct |
| CVE-2026-86684 | 7.1 high | 0.00% | gitea | The Gitea push mirror API checked whether the repository owner, instead of the requesting user, may use local file system paths. On instances with `[security] IMPORT_LOCAL_PATHS = true`, a repository administrator who is not allowed to import local paths could add a push mirror to a local path on the server when the repository owner has that permission. Gitea then pushed the repository's refs into an existing Git repository at that path with the permissions of the Gitea process. | 13 Oct |
| CVE-2026-79960 | 7.1 high | 0.00% | gitea | When a push was authenticated with a deploy key, Gitea recorded the repository owner as the pusher, so permission checks in the push hook pipeline evaluated the owner instead of the deploy key. A holder of a writable deploy key could create protected tags without being on the tag allow list and change repository visibility through push options, for example making a private repository public. Pull requests created through the AGit flow with a deploy key were also attributed to the owner. | 13 Oct |
| CVE-2026-110324 | 6.5 medium | 0.00% | no CPE yet | The visibility check of Gitea user profiles was applied to GET requests only, while `POST /{username}` (follow and unfollow) required only a signed-in user. Any authenticated user could therefore obtain the full name, location, website and description of a user with a private profile from the response. The issue was fixed in 28.1.0 and disclosed with 28.2.0. | 19 Oct |
| CVE-2026-105964 | 6.5 medium | 0.00% | no CPE yet | The Gitea Actions artifact v4 (Twirp) handlers read the whole request body into memory without a size limit. A user who can run a workflow and obtains the runner token of that run could send an oversized request to the artifact service and exhaust the memory of the server, which terminates the Gitea process. The request body is now limited to 1 MiB. | 19 Oct |
| CVE-2026-73814 | 6.5 medium | 0.00% | no CPE yet | Gitea's collaboration access-mode endpoint accepts the Owner access mode from an authenticated repository collaborator with Admin access. The collaborator can promote their effective permissions from Admin to Owner and then perform owner-only operations, including transferring the repository to their own account. This bypasses the intended boundary between repository administration and ownership. | 18 Oct |
| CVE-2026-60010 | 6.5 medium | 0.00% | no CPE yet | Gitea's repository-side team-link API allows a repository administrator who is not an organization owner to attach organization teams to a repository despite RepoAdminChangeTeamAccess being disabled. The endpoint does not enforce the organization's restriction on repository administrators changing team access. This allows unauthorized changes to which organization teams receive repository access. | 15 Oct |
| CVE-2026-70406 | 6.5 medium | 0.00% | no CPE yet | Gitea's shared comparison helper omits the token repository-access check used when updating pull requests. A public-only token with read:repository scope can route a comparison or pull request creation through a public base repository and retrieve commit history and diffs from a private head repository accessible to the token owner. This bypasses the token's public-only restriction; it does not remove the account's underlying repository permission checks. | 14 Oct |
| CVE-2026-66874 | 6.5 medium | 0.00% | no CPE yet | For pull request events, Gitea reads workflow definitions from the pull request head and posts a synthetic skipped status when workflow branch or path filters exclude execution. A fork pull request author can supply a workflow matching a required status context but deliberately prevent it from running. Because skipped statuses count as success, branch protection or organization-required workflow checks can appear satisfied without the mandated workflow executing; no runner or maintainer approval is required for this path. | 14 Oct |
| CVE-2026-95112 | 6.5 medium | 0.00% | gitea | When processing issue and comment bodies, Gitea scanned the entire preceding text for action keywords such as "closes" or "fixes" once per Markdown link, giving processing time quadratic in the input size. An authenticated user able to submit issue or comment content could send a crafted body of about 1 MB that keeps a CPU core busy for several minutes while holding a database transaction open. | 13 Oct |
| CVE-2026-104633 | 6.5 medium | 0.00% | gitea | When migrating a repository from another Gitea instance, Gitea used the page size reported in the source server's API settings to end its paginated downloads. A source that reported `max_response_items` as `0` made these loops run indefinitely and grow server memory until it was exhausted. Any user who can migrate repositories could point a migration at a server they control and cause a denial of service. | 13 Oct |
| CVE-2026-25779 | 6.1 medium | 0.00% | no CPE yet | Gitea versions up to and including 1.25.4 allow redirect bypasses through raw or percent-encoded backslashes in redirect_to values. | Sun 25 Oct |
| CVE-2026-96594 | 6.1 medium | 0.00% | gitea | The Gitea API endpoint `GET /api/v1/repos/{owner}/{repo}/media/{filepath}` wrote files of up to 1 KiB that are stored directly in Git, not in LFS, to the response without the content type and disposition headers Gitea uses for user content. An HTML file committed to a repository was therefore rendered by the browser on the Gitea origin. A user who can push to a repository could run JavaScript in the session of a victim who opens the media URL and act with the victim's permissions. | 13 Oct |
| CVE-2026-78433 | 5.9 medium | 0.00% | no CPE yet | Gitea's web attachment handler skips its cross-repository ownership check for attachments created before 16 January 2026 and checks permissions against the repository named in the request URL instead. An unauthenticated attacker who knows a private attachment's UUID can request it through a public repository's attachment path and retrieve its contents. This can expose issue and pull request attachments or release assets; the random attachment UUID must already be known to the attacker. | 18 Oct |
| CVE-2026-70402 | 5.8 medium | 0.00% | no CPE yet | Gitea creates server-side Git hook directories and scripts with mode 0777 and relies on the process umask to restrict access. With a permissive umask such as 0000 or 0002, another local user who can reach the repository storage may modify a hook or add an executable to a writable hook directory. A later Git operation can execute that file as the Gitea service account. | 14 Oct |
| CVE-2026-104627 | 5.4 medium | 0.00% | no CPE yet | The Gitea OpenID association callback in the security settings accepted a positive OpenID 2.0 assertion without checking that the signed-in user had started the linking. Because OpenID 2.0 allows unsolicited assertions, an attacker-controlled OpenID provider could attach the attacker's identity to the account of a signed-in victim who opened a crafted link, and the attacker could then sign in as the victim through OpenID login, which does not apply the local TOTP or WebAuthn checks. The callback now requires a time-limited `state` value bound to the user. | 19 Oct |
| CVE-2026-70396 | 5.4 medium | 0.00% | no CPE yet | Gitea's organization repository-creation API requires write:organization but omits the write:repository token scope enforced by other repository-creation routes. A personal access token or OAuth application token without repository-write scope can therefore create organization-owned repositories if the authorizing user has permission to do so. This bypasses the token's delegated scope boundary while remaining subject to the user's organization permissions. | 18 Oct |
| CVE-2026-103667 | 5.4 medium | 0.00% | gitea | Gitea's container registry served blob downloads with a `Content-Type` taken from the media type declared in pushed image manifests, without a `Content-Disposition` or restrictive content security policy. A user who can push container images can publish a blob containing HTML and JavaScript with a `text/html` media type. When a victim who is authenticated to the instance opens the blob URL in a browser, the script runs on the Gitea origin and can perform actions as the victim, such as creating API tokens. | 15 Oct |
| CVE-2026-70400 | 5.4 medium | 0.00% | no CPE yet | Gitea's repository migration API accepts a public-only token when the request specifies creation of a private repository. A delegated token intended to operate only on public resources can create a private repository and migration task under the authorizing account or an organization where that user has the necessary permissions. The ordinary private repository-creation route rejects the same token, but the migration path omits that restriction. | 14 Oct |
| CVE-2026-89182 | 5.4 medium | 0.00% | gitea | With `[repository] FORCE_PRIVATE = true`, Gitea creates new repositories as private, but the post-receive hook still applied the `repo.private=false` push option to an empty repository created by push. Any user who can create repositories could make their new repository public in violation of the instance policy. The default configuration is not affected. | 13 Oct |
| CVE-2025-68942 | 5.4 medium | 0.00% | gitea | Gitea before 1.22.2 allows XSS because the search input box (for creating tags and branches) is v-html instead of v-text. | 13 Oct |
| CVE-2025-68946 | 5.4 medium | 0.00% | gitea | In Gitea before 1.20.1, a forbidden URL scheme such as javascript: can be used for a link, aka XSS. | 13 Oct |
| CVE-2026-20909 | 5.3 medium | 0.00% | no CPE yet | Gitea versions before 1.25.5 have insufficient permission checks when listing tracked time entries. | Sun 25 Oct |
| CVE-2026-25782 | 5.3 medium | 0.00% | no CPE yet | Gitea versions before 1.25.5 look up tracked-time entries by time ID without scoping the lookup to the issue in the request URL, allowing deletion attempts to target entries from another issue. | Sun 25 Oct |
| CVE-2026-28705 | 5.3 medium | 0.00% | no CPE yet | Gitea versions before 1.25.5 use release tag names and asset names as filesystem path components when dumping release assets, allowing specially crafted names to affect dump output paths. | Sun 25 Oct |
| CVE-2026-78231 | 5.3 medium | 0.00% | no CPE yet | When OpenID sign-in is enabled, Gitea processes unauthenticated assertion parameters and sends an HTTP POST request to the caller-supplied OpenID provider endpoint during verification. An attacker controls the destination and much of the form body, allowing interaction with internal HTTP services reachable from the Gitea server. The response is not returned to the attacker, so the issue is blind SSRF; its impact depends on the services and network addresses the server can reach. | 18 Oct |
| CVE-2026-73135 | 5.3 medium | 0.00% | no CPE yet | Gitea uses inconsistent repository visibility predicates, and the condition used by some repository-listing endpoints admits repositories whose owners are hidden from the viewer. Those listings disclose repository metadata even though direct routes correctly deny access with a 404 response. The issue exposes repository existence and listing information across the intended owner-visibility boundary. | 14 Oct |
| CVE-2026-63792 | 5.3 medium | 0.00% | no CPE yet | Gitea's collaborative-owner authorization path for reading cross-repository reusable workflows does not exclude fork pull request runs. An approved fork workflow targeting a private repository can read workflow files from another private repository that trusts the base repository's owner through collaborative-owner configuration. The issue exposes private reusable workflow contents at caller-selected Git refs; it does not itself grant write access or code execution in the other repository. | 14 Oct |
| CVE-2026-25946 | 5.3 medium | 0.00% | no CPE yet | When OpenID sign-in is enabled, Gitea accepts a user-supplied OpenID URL and performs discovery requests without validating the destination against internal network addresses. An unauthenticated remote attacker can cause the server to contact loopback or private-network HTTP services. This can expose internal service behavior and enable interaction with resources that are not directly reachable by the attacker. | 14 Oct |
| CVE-2025-68938 | 5.3 medium | 0.00% | gitea | Gitea before 1.25.2 mishandles authorization for deletion of releases. | 13 Oct |
| CVE-2025-68939 | 5.3 medium | 0.00% | gitea | Gitea before 1.23.0 allows attackers to add attachments with forbidden file extensions by editing an attachment name via an attachment API. | 13 Oct |
| CVE-2025-68940 | 5.3 medium | 0.00% | gitea | In Gitea before 1.22.5, branch deletion permissions are not adequately enforced after merging a pull request. | 13 Oct |
| CVE-2025-68941 | 5.3 medium | 0.00% | gitea | Gitea before 1.22.3 mishandles access to a private resource upon receiving an API token with scope limited to public resources. | 13 Oct |
| CVE-2025-68943 | 5.3 medium | 0.00% | gitea | Gitea before 1.21.8 inadvertently discloses users' login times by allowing (for example) the lastlogintime explore/users sort order. | 13 Oct |
| CVE-2025-68944 | 5.3 medium | 0.00% | gitea | Gitea before 1.22.2 sometimes mishandles the propagation of token scope for access control within one of its own package registries. | 13 Oct |
| CVE-2025-68945 | 5.3 medium | 0.00% | gitea | In Gitea before 1.21.2, an anonymous user can visit a private user's project. | 13 Oct |
| CVE-2026-97208 | 4.9 medium | 0.00% | gitea | The Gitea API endpoint for creating push mirrors (`POST /api/v1/repos/{owner}/{repo}/push_mirrors`) checked only whether mirroring was enabled and not the `[mirror] DISABLE_NEW_PUSH` setting that the web interface enforces. A repository administrator could therefore create new push mirrors on instances where the site administrator had disabled them. A push mirror pushes all refs of the repository to a remote chosen by the caller, on each commit or on a schedule. | 13 Oct |
| CVE-2026-25714 | 4.3 medium | 0.00% | no CPE yet | Gitea versions up to and including 1.26.1 do not apply public-only token filtering consistently to the user organization API, leaving an incomplete fix for CVE-2025-68941. | Sun 25 Oct |
| CVE-2026-27761 | 4.3 medium | 0.00% | no CPE yet | Gitea versions up to and including 1.26.2 allow repository RSS and Atom feed endpoints to bypass API access token scope checks, exposing private repository commit data to tokens without the required repository scope. | Sun 25 Oct |
| CVE-2026-27783 | 4.3 medium | 0.00% | no CPE yet | Gitea versions up to and including 1.26.1 do not enforce repository-unit authorization on issue-template API endpoints. | Sun 25 Oct |
Download these 118 as CSV · subscribe to this list.
EPSS scores: 2026-10-29. NVD cursor: 2026-10-29 00:22. The News page shows only notable CVEs (KEV, your stack, new criticals, EPSS over 50%, or active exploitation per SSVC); this table has all of them.