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-59774exploit ×4 | 9.8 critical | 28.0% | no CPE yet | Gitea's Org-mode markup renderer processes INCLUDE directives supplied to the repository markup endpoint without preventing access to server-side files. An unauthenticated attacker can use a suitable public repository to read files accessible to the Gitea service account. If the disclosed files include app.ini and its INTERNAL_TOKEN, the attacker can chain the disclosure with internal logger access to modify a Git hook and execute commands as the Gitea service account. | 15 Oct |
| CVE-2026-20896exploit ×8 | 9.8 critical | 3.0% | no CPE yet | Gitea Docker image versions up to and including 1.26.2 use REVERSE_PROXY_TRUSTED_PROXIES=* by default, allowing any source IP to impersonate a user when reverse-proxy authentication headers such as X-WEBAUTH-USER are enabled. | Sun 25 Oct |
| CVE-2026-27771exploit ×2 | 8.2 high | 1.0% | no CPE yet | Gitea versions up to and including 1.26.1 have insufficient permission checks for Composer package source links, which can expose private or internal package source information. | Sun 25 Oct |
| CVE-2026-28699exploit | 8.1 high | 1.0% | no CPE yet | Gitea versions up to and including 1.26.1 allow OAuth2 access token scope enforcement to be bypassed through HTTP Basic authentication. | Sun 25 Oct |
| CVE-2026-22874exploit ×2 | 9.6 critical | 0.00% | no CPE yet | Gitea versions up to and including 1.26.2 have incomplete SSRF protection in webhook and migration allow-list filtering. | Sun 25 Oct |
| CVE-2026-97859exploit ×3 | 6.5 medium | 0.00% | no CPE yet | Seven Gitea API routes under `/api/v1/users/{username}` (followers, following, following/{target}, starred, subscriptions, keys and gpg_keys) were registered without the `individualPermsChecker` middleware that enforces the visibility of the target user. An authenticated user could therefore read the followers, following list, starred and watched repositories and public SSH and GPG keys of a user with limited or private visibility, whom they could not otherwise see. The issue was fixed in 1.27.3 and 28.0.0 and disclosed with 28.2.0. | 19 Oct |
| CVE-2025-69413exploit | 5.3 medium | 0.00% | gitea | In Gitea before 1.25.2, /api/v1/user has different responses for failed authentication depending on whether a username exists. | 14 Oct |
| CVE-2026-26292 | 9.8 critical | 1.0% | no CPE yet | Gitea versions before 1.25.5 do not use the migration HTTP transport for LFS push and sync mirror operations, bypassing the configured migration transport protections for those LFS requests. | Sun 25 Oct |
| CVE-2026-27780 | 9.8 critical | 1.0% | no CPE yet | Gitea versions before 1.26.0 do not fail closed on bufio.Scanner errors while processing pre-receive hook input, allowing oversized input to bypass branch-protection checks. | Sun 25 Oct |
| CVE-2026-94205 | 9.8 critical | 1.0% | gitea | Gitea Actions decided whether a fork pull request run needed approval based on the user who triggered the event rather than the pull request author. For `pull_request` activity triggered by a maintainer during ordinary triage, such as adding a label, the run was created without requiring approval, while the workflow definition was still taken from the fork head. Where Actions is enabled and a matching runner is registered, fork-controlled workflow code could run on the base repository's runners without an explicit approval. | 13 Oct |
| CVE-2026-58370 | 9.2 critical | 1.0% | no CPE yet | Woodpecker before 3.15.0 matches the ApprovalAllowedUsers bypass list against pipeline.Author. For the GitLab forge driver, pipeline.Author is populated from the git commit author name (commit.author.name) carried in the webhook payload, which is attacker-controlled and not verified by GitLab. A user who can open a merge request from a fork can set the commit author name to match an entry in ApprovalAllowedUsers, causing needsApproval to return false so the pipeline runs without the required approval. This defeats the fork-approval security boundary and allows execution of attacker-controlled pipeline steps on a Woodpecker agent and exfiltration of CI secrets exposed to the run. Other built-in forge drivers (Gitea, Forgejo, GitHub, Bitbucket) derive pipeline.Author from the forge-validated sender/actor identity and are not affected. | Sun 25 Oct |
| CVE-2026-20706 | 9.1 critical | 1.0% | no CPE yet | Gitea versions up to and including 1.26.1 allow repository archive downloads to bypass token scope checks on the web archive download endpoint. | Sun 25 Oct |
| CVE-2026-22547 | 9.1 critical | 1.0% | no CPE yet | Gitea versions before 1.25.5 lack validation constraints for repository creation fields, including length-limited template fields and trust model or object format values. | Sun 25 Oct |
| CVE-2026-25718 | 9.1 critical | 1.0% | no CPE yet | Gitea versions before 1.25.5 mishandle path resolution during template repository generation, allowing template processing to read or write through symlinked or otherwise non-regular paths. | Sun 25 Oct |
| CVE-2026-27775 | 8.8 high | 1.0% | no CPE yet | Gitea 1.25.5 caches a branch-specific write-permission result across multiple refs in one pre-receive hook session, allowing a per-branch maintainer-edit grant to be reused for other refs and escalate to full repository write access. | Sun 25 Oct |
| CVE-2026-73800 | 8.8 high | 1.0% | no CPE yet | Gitea resolves local reusable workflow files from a fork's head commit when a trusted base-branch workflow runs for a pull_request_target event. A fork author can modify a referenced reusable workflow so attacker-controlled code executes with the repository and organization secrets available to that event. Exploitation requires a base workflow that calls a local reusable workflow, and bypasses the intended separation between trusted base code and untrusted fork code. | 18 Oct |
| CVE-2026-96404 | 8.1 high | 1.0% | gitea | When Gitea's web installer is reachable against a database that already contains users, such as after `INSTALL_LOCK` has been reset to `false`, submitting the install form with an administrator username matching an existing account issued an authenticated session for that account without verifying its password. If the account is an administrator, the session grants full administrative access, including changing the account's password. Databases with a single user also did not require the reinstall confirmation. | 13 Oct |
| CVE-2026-25038 | 7.5 high | 1.0% | no CPE yet | Gitea 1.26.2 allows unauthorized users to access labels of private organizations. | Sun 25 Oct |
| CVE-2026-26307 | 7.5 high | 1.0% | no CPE yet | Gitea versions before 1.25.5 do not enforce a timeout on git grep searches, allowing expensive searches to consume server resources. | Sun 25 Oct |
| CVE-2026-27779 | 7.5 high | 1.0% | no CPE yet | Gitea versions before 1.25.5 accept malformed or injected forwarded-proto values when detecting public URLs, allowing spoofed canonical URL generation. | Sun 25 Oct |
| CVE-2026-60021 | 6.5 medium | 1.0% | no CPE yet | Gitea's initial GitLab migration version probe uses an HTTP client without a timeout and does not attach the migration task's cancellation context. An authenticated user who can start migrations can target an attacker-controlled server that keeps the response open indefinitely. The request continues after task cancellation and can exhaust the migration worker pool, preventing other migrations from progressing. | 18 Oct |
| CVE-2026-63021 | 6.5 medium | 1.0% | no CPE yet | Gitea's Swift package parser limits each manifest to 128 KiB but does not limit the number of manifests or their aggregate size before reading them into memory. An authenticated user with package-publish permission can upload a highly compressed archive containing many manifests, causing allocations far larger than the uploaded archive. This can exhaust memory, terminate the process, or cause request failures. | 14 Oct |
| CVE-2026-62925 | 6.5 medium | 1.0% | no CPE yet | Gitea parses Alpine package uploads before enforcing package-size quotas and does not bound the decompressed .PKGINFO data or its dependency and provides entry counts. An authenticated user with package-publish permission can upload a small, highly compressed archive that causes disproportionately large memory allocations during parsing and metadata generation. On memory-constrained deployments, this can terminate the process or otherwise disrupt availability. | 14 Oct |
| CVE-2026-60018 | 6.5 medium | 1.0% | no CPE yet | Gitea's OneDev migration downloader reads the entire remote version response into memory without a size limit and uses a client without a timeout. An authenticated user who can start a repository migration can direct it to an attacker-controlled OneDev-compatible server returning an oversized or never-ending response. This can consume memory and hold migration workers, impairing service availability. | 14 Oct |
| CVE-2026-73278 | 9.8 critical | 0.00% | gitea | Gitea's OAuth2 and OpenID Connect sign-in paths do not require a WebAuthn challenge when WebAuthn is the account's only configured second factor. A party able to authenticate through the affected external identity flow can obtain a full session without the passkey verification enforced during password login. One affected path can also persist an external identity link, extending the compromise beyond the initial session; accounts with TOTP configured are outside the reported WebAuthn-only scenario. | 13 Oct |
| CVE-2026-58426 | 9.6 critical | 0.00% | no CPE yet | Gitea Actions Artifacts V4 signed URL HMAC ambiguity allows cross-repository artifact read and cross-task upload-state write | Sun 25 Oct |
| CVE-2026-58053 | 9.4 critical | 0.00% | no CPE yet | Gitea act_runner with the Docker backend (through act 0.262.0) passes a workflow's container.options string to the Docker job container's HostConfig and, when configured with privileged: false, forces only the Privileged flag off while merging options such as --pid=host, --cap-add, and --security-opt unchanged. A user who can run a workflow on a Docker-backed runner can create a job container with host namespaces and broad capabilities and escape to the host as root despite privileged mode being disabled. | Sun 25 Oct |
| CVE-2026-26232 | 9.1 critical | 0.00% | no CPE yet | Gitea versions before 1.25.5 do not consistently enforce OAuth2 authorization code expiry and single-use behavior during token exchange. | Sun 25 Oct |
| CVE-2026-26247 | 9.1 critical | 0.00% | no CPE yet | Gitea versions before 1.25.5 do not persist the OAuth2 PKCE S256 challenge method correctly during authorization, allowing token exchange without the expected verifier check. | Sun 25 Oct |
| CVE-2026-103059 | 9.1 critical | 0.00% | gitea | When Gitea's built-in SSH server is enabled (`START_SSH_SERVER = true`), the presented public key was looked up with an SQL `LIKE` comparison of its encoded content, which is case-insensitive on some databases, including the default SQLite. An attacker who can construct a case variant of another user's registered RSA public key for which they can derive the private key could have that key matched to the victim's account and authenticate over SSH as that user. Keys are now looked up by fingerprint. | 15 Oct |
| CVE-2026-95106 | 9.1 critical | 0.00% | gitea | Gitea accepted pushed Git trees containing two entries with the same name, which Git's own consistency checks reject. Gitea's web views resolved such a path to the first entry, while `git checkout`, Gitea Actions, and release archives use the last. A contributor could open a pull request whose diff and file views show benign content while CI and checkouts at the same commit use different, attacker-controlled content. Incoming objects are now checked for consistency; objects already stored in existing repositories are not rescanned. | 13 Oct |
| CVE-2026-101023 | 9.1 critical | 0.00% | gitea | Gitea's OAuth2 token endpoint verified the signature and grant of a token submitted with the `refresh_token` grant type, but not that the token was a refresh token. An unexpired access token for the same OAuth2 application and grant could be exchanged for a new access token and refresh token. Whoever holds such an access token could keep access beyond the token's original lifetime. | 13 Oct |
| CVE-2026-73802 | 8.8 high | 0.00% | no CPE yet | Gitea Runner passes workflow-controlled container options into Docker job container configuration while privileged mode is disabled. Host namespace settings, expanded capabilities, and security profile overrides can remain effective despite Privileged being forced false. A workflow author able to run jobs on an affected Docker-backed runner can use these options to access host namespaces and execute commands as root on the runner host, bypassing the intended container isolation. | 18 Oct |
| CVE-2026-73535 | 8.8 high | 0.00% | no CPE yet | Gitea's OpenID connect handler accepts a user's password without enforcing enrolled TOTP or WebAuthn verification before completing sign-in and linking an OpenID identifier. When OpenID sign-in is enabled, an attacker who knows the victim's password can obtain a session and link an attacker-controlled identifier. The attacker can then sign in through that identifier without the victim's password or second factor, and a password change does not remove the link. | 18 Oct |
| CVE-2026-71184 | 8.8 high | 0.00% | no CPE yet | Gitea's pull request review notifier does not attach the pull request to the Actions notification, so the fork workflow approval gate does not recognize the run as originating from a fork. Review comment and review approval or rejection events can consequently load workflow code from the fork head and run it on the base repository's runners without the required maintainer approval. This allows execution of fork-controlled workflow code across the intended approval boundary. | 15 Oct |
| CVE-2026-104626 | 8.8 high | 0.00% | gitea | A user who can open a fork pull request can place workflow content with a shared run-level concurrency group into a Gitea Actions run that is awaiting approval. When a later run in that group cancels the blocked job, the run becomes terminal while still marked as needing approval. If a maintainer later approves the run, Gitea passed the already-cancelled job back through concurrency preparation, set it to waiting, and made it claimable by a matching runner, executing fork-controlled workflow code. Exploitation requires the maintainer's later approval action, Actions to be enabled, and a runner that accepts the repository's jobs. | 13 Oct |
| CVE-2026-104632 | 8.8 high | 0.00% | gitea | Gitea Actions blocks the jobs of workflow runs from first-time fork pull request contributors until a maintainer approves the run. The rerun path only required a run to be finished and built the new attempt's jobs without considering the pending approval, so when a user with Actions write access cancelled a run that was awaiting approval and then re-ran it, the new jobs were created as waiting rather than blocked while the run still recorded that approval was required. Cancelling and re-running stale fork checks is a routine action that does not involve the approval control, so where Actions is enabled and a matching runner is registered, workflow code taken from the fork pull request head could run on the repository's runners without an explicit approval. | 13 Oct |
| CVE-2026-28737 | 8.7 high | 0.00% | no CPE yet | Gitea versions from 1.25.0 before 1.26.0 allow stored cross-site scripting through the extensionsRequired field in glTF files rendered by the 3D file viewer. | Sun 25 Oct |
| CVE-2026-26231 | 8.5 high | 0.00% | no CPE yet | Gitea versions up to and including 1.26.1 allow the Allow edits from maintainers permission path to authorize commits to repositories that the user can read but should not be able to write. | Sun 25 Oct |
| CVE-2026-34966 | 8.3 high | 0.00% | no CPE yet | Gitea prior to 1.27.0 contains a server-side request forgery vulnerability that allows authenticated attackers to bypass SSRF protections by exploiting HTTP fetch operations in migration and OAuth avatar code paths that use Go's default http.Get without a custom DialContext. Attackers can supply arbitrary URLs through release asset download URLs, pull-request patch URLs, or OAuth avatar endpoints to reach internal services, cloud instance-metadata endpoints, or read local files such as the application configuration containing database credentials and signing secrets, with exfiltrated content persisted as migration release assets for later retrieval. | 8 Oct |
| CVE-2026-22555 | 8.1 high | 0.00% | no CPE yet | Gitea versions before 1.26.0 allow API users to fork a repository into an organization without first passing the CanCreateOrgRepo check, which can expose organization secrets. | Sun 25 Oct |
| CVE-2026-28744 | 8.1 high | 0.00% | no CPE yet | Gitea versions up to and including 1.26.1 allow Git smart HTTP requests authenticated with bearer tokens to bypass repository token scope checks. | Sun 25 Oct |
| CVE-2026-73804 | 8.1 high | 0.00% | no CPE yet | Gitea allows a token with write:user scope to register an attacker-controlled SSH public key on the token owner's account. API requests signed with the corresponding private key authenticate as that account through HTTP Signature without API token scope information, causing route-level token scope checks to be skipped. This converts a user-scoped token into an unscoped API authentication method while retaining the account's normal role and repository permissions. | 18 Oct |
| CVE-2026-66877 | 8.1 high | 0.00% | no CPE yet | Gitea enforces first-time fork contributor approval by blocking jobs, but some job transition and dispatch paths do not re-check the run's approval requirement. A separate run sharing a job-level concurrency group can cancel a pending job and cause its blocked sibling jobs to be re-emitted and dispatched without approval. This allows unreviewed workflow code to execute on self-hosted runners; fork secrets remain withheld and the run token remains read-only. | 15 Oct |
| CVE-2026-89430 | 8.1 high | 0.00% | gitea | Gitea validated a push mirror's remote address against the `[migrations]` allow and block lists only when the mirror was created. Each synchronization passed the stored address directly to `git push`, so a name that later resolved to a blocked or internal address was still reached. A user with administrator access to a repository, which includes repositories they create themselves, could aim push mirror synchronization at internal Git services and force-push the repository's contents to them. | 13 Oct |
| CVE-2026-105267 | 8.1 high | 0.00% | gitea | The Gitea web route for deleting tags (`POST /{owner}/{repo}/tags/delete`) requires only write access to the Code unit, but shares its handler with release deletion and did not check that the target was a plain tag. A collaborator with Code write access and without Releases write access could permanently delete published releases of that repository, including their attachments. Protected tag rules covering the release tag still blocked the deletion. | 13 Oct |
| CVE-2026-101027 | 7.7 high | 0.00% | gitea | When `[migrations] ALLOWED_DOMAINS` was configured, a hostname matching the allow list was accepted without checking its resolved address against the local-network restrictions. A user who can start repository migrations and control the DNS of an allowed hostname could make it resolve to loopback or private addresses and bypass `ALLOW_LOCALNETWORKS = false`, reaching internal services from the Gitea server. Instances without `ALLOWED_DOMAINS` configured are not affected by this specific bypass. | 15 Oct |
| CVE-2026-24451 | 7.5 high | 0.00% | no CPE yet | Gitea 1.26.2 allows fork synchronization to continue after a parent repository changes from public to private, exposing data to a fork that should no longer be authorized. | Sun 25 Oct |
| CVE-2026-24690 | 7.5 high | 0.00% | no CPE yet | Gitea versions before 1.25.5 have insufficient permission checks for updating or rebasing pull request branches. | Sun 25 Oct |
| CVE-2026-25712 | 7.5 high | 0.00% | no CPE yet | Gitea versions before 1.25.5 have insufficient visibility checks in organization permission APIs for hidden members and private organizations. | Sun 25 Oct |
50 of 118 · Next
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.