- Top reward
- $1,500
- Top severity paid
- Critical
- Assets in scope
- 15
- Public CVEs
- 75
- Last change
- No changes yet
At a glance
What to know before you start testing.
- Pays from $1,500
- for critical bugs.
- Report on Sorona
- Submit through the program page.
- Partial safe harbor
- Some legal protection; read the terms.
- Publish after a fix
- Coordinate the timing with the company.
Rewards
What Sorona lists as the payout for each severity.
| Severity | Relative size | Reward |
|---|---|---|
| Critical | $1,500+ | |
| High | $700+ | |
| Medium | $300+ | |
| Low |
|
$100 $100 / 1 month Claude Max |
- Safe harbor
-
Partial
Sorona will not pursue legal action against you for good-faith research submitted to us in line with this policy. We cannot speak for the upstream project, its vendor, or any third party, and we do not grant authorization on their behalf.
- Hall of fame
-
Yes
Reporters are credited publicly by default and kept anonymous on request.
Summarised with AI from the program policy on Sorona, read 12 Nov 2026, and checked word for word against it. Read the original
Scope
15 assets you may test, 6 excluded.
Web 1
- https://about.gitea.com
Products and areas 14
- Archive generation, raw file serving, attachments and avatar handling
- Authentication in full: local accounts, OAuth2 providers, OpenID Connect, LDAP, SMTP, PAM and SPNEGO, plus two-factor and WebAuthn handling
- Every package registry the binary ships, covering Container, npm, Maven, PyPI, Go, Composer, NuGet, Debian, RPM, Alpine and the rest, along with the authentication on each
- Gitea Actions end to end: the runner registration and protocol, job dispatch, secret and variable injection, and workflow triggering from forks and pull requests
- Git LFS storage and the object access checks in front of it
- Personal access tokens and their scopes, OAuth2 application authorization, and the API key paths scripted consumers use
- Pull request merging, protected branches and the approval rules meant to gate a merge
- Rendering of Markdown, issue and comment content, repository files and the file preview paths
- Repository access control across public, private, limited and internal visibility, and the organisation, team and collaborator model on top of it
- SECURITY.md asks reporters not to file a public issue and to send the report privately to [email protected], offering public thanks in return. It declares no boundary narrower than Gitea itself
- The built-in web editor, file upload, and the notification and mail paths
- The full HTTP API, the admin panel and every setting an administrator can change on a running instance
- The Git transport layer over HTTP and SSH, including the built-in SSH server, authorized keys handling and the internal protocol between components
- Webhooks, repository migration and mirroring, and every other path where Gitea fetches a URL a user supplied
Out of scope (6)
- A repository, organisation or package an administrator deliberately made public
- Forgejo, a separate fork with its own security process, even where the code is shared
- The git binary and any external tool Gitea shells out to
- The reverse proxy and TLS termination in front of Gitea
- Third-party themes, templates and custom assets an operator installed
- Workloads a user's own Actions workflow chose to run, which execute what the workflow author wrote
Rules
What the policy asks of you, and the bug types it won't reward, quoted from Sorona's policy. "We" in these lines means Sorona, not this site.
While testing
-
Submit through sorona.xyz. This project runs no bounty of its own; we validate, coordinate disclosure with the maintainers, and pay you directly.
-
Report privately to the address on the policy page , the address SECURITY.md publishes along with a GPG key. GitHub Security Advisories are used for publication
-
Do not file a public issue. The policy says so directly and a public report burns the embargo
-
Give the account's repository and organisation permissions precisely. Almost every severe finding here is a specific permission level reaching something one level above it
Summarised with AI from the program policy on Sorona, read 12 Nov 2026, and checked word for word against it. Read the original
Changes
Tracked since 11 Nov 2026. Last checked 1 hour ago.
No changes yet. When the rewards or scope move, you will see it here and in the RSS feed.
Public CVEs
Published vulnerabilities in this vendor's products, from the NVD.
| CVE | Summary | Severity | Published |
|---|---|---|---|
| CVE-2026-86684 | 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 | High 7.1 | 6 Oct 2026 |
| CVE-2026-89182 | 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. | Medium 5.4 | 6 Oct 2026 |
| CVE-2026-96594 | 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 t | Medium 6.1 | 6 Oct 2026 |
| CVE-2026-97208 | 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 | Medium 4.9 | 6 Oct 2026 |
| CVE-2026-105267 | 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 | High 8.1 | 6 Oct 2026 |
| CVE-2026-105268 | The Gitea API routes for issue attachments (`/api/v1/repos/{owner}/{repo}/issues/{index}/assets/{attachment_id}`) also accepted attachments that belong to comments on the issue. Because the author of an issue may edit and delete the issue's attachments, a user who opened an issue could rename or delete attachments that other users had posted in comments on that issue. The contents of the attachmen | Medium 4.3 | 6 Oct 2026 |
| CVE-2026-104633 | 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 | Medium 6.5 | 6 Oct 2026 |
| CVE-2026-101023 | 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. | Critical 9.1 | 6 Oct 2026 |
| CVE-2026-96404 | 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, incl | High 8.1 | 6 Oct 2026 |
| CVE-2026-96580 | 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 re | High 7.5 | 6 Oct 2026 |
| CVE-2026-96589 | When a private repository is transferred to a user who lacks access, Gitea grants that recipient temporary read access as a collaborator so they can review the repository. Rejecting or cancelling the transfer did not revoke this collaboration, so the named recipient kept persistent read access to the private repository, including its code, issues, pull requests and wiki, and could clone it. The re | Medium 4.3 | 6 Oct 2026 |
| CVE-2026-94205 | 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 matc | Critical 9.8 | 6 Oct 2026 |
| CVE-2026-95106 | 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 | Critical 9.1 | 6 Oct 2026 |
| CVE-2026-95112 | 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. | Medium 6.5 | 6 Oct 2026 |
| CVE-2026-96399 | 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 | High 7.5 | 6 Oct 2026 |
| CVE-2026-96400 | With `[migrations] ALLOWED_DOMAINS` set to a matching entry such as `*` or a hostname wildcard, Gitea's migration URL validation could permit reserved and link-local addresses, such as `169.254.169.254`, even when `ALLOW_LOCALNETWORKS = false`. The local-network block list did not cover these ranges, and a hostname matching the allow list was accepted regardless of its resolved address. A user who | Medium 4.3 | 6 Oct 2026 |
| CVE-2026-79960 | 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 | High 7.1 | 6 Oct 2026 |
| CVE-2026-89430 | 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 | High 8.1 | 6 Oct 2026 |
| CVE-2026-70357 | 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; v | High 7.5 | 6 Oct 2026 |
| CVE-2026-73278 | 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 bey | Critical 9.8 | 6 Oct 2026 |
| CVE-2026-103667 | 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 br | Medium 5.4 | 6 Oct 2026 |
| CVE-2026-103670 | 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 | High 7.5 | 6 Oct 2026 |
| CVE-2026-104626 | 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, s | High 8.8 | 6 Oct 2026 |
| CVE-2026-104632 | 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 rat | High 8.8 | 6 Oct 2026 |
| CVE-2026-104636 | 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 b | High 7.5 | 6 Oct 2026 |
| CVE-2026-103059 | 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 | Critical 9.1 | 6 Oct 2026 |
| CVE-2026-101029 | Gitea's repository migration and pull mirror egress checks could be bypassed with a hostname that returns multiple DNS answers, because the address that was validated was not necessarily the address Git later connected to. A low-privileged user who can create migrations or mirrors could direct the server to internal services, reading from and writing to reachable internal Git or HTTP endpoints. Co | Medium 4.3 | 6 Oct 2026 |
| CVE-2026-101027 | 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 Git | High 7.7 | 6 Oct 2026 |
| CVE-2026-60004 | Gitea before 1.27.1 allows remote code execution via the diffpatch API through Git hook installation. | Critical 9.8 | 26 Aug 2026 |
| CVE-2026-20897 | Gitea does not properly validate repository ownership when deleting Git LFS locks. A user with write access to one repository may be able to delete LFS locks belonging to other repositories. | Critical 9.1 | 22 Jan 2026 |
| CVE-2026-20904 | Gitea does not properly validate ownership when toggling OpenID URI visibility. An authenticated user may be able to change the visibility settings of other users' OpenID identities. | Medium 6.5 | 22 Jan 2026 |
| CVE-2026-20912 | Gitea does not properly validate repository ownership when linking attachments to releases. An attachment uploaded to a private repository could potentially be linked to a release in a different public repository, making it accessible to unauthorized users. | Critical 9.1 | 22 Jan 2026 |
| CVE-2026-20800 | Gitea's notification API does not re-validate repository access permissions when returning notification details. After a user's access to a private repository is revoked, they may still view issue and pull request titles through previously received notifications. | Medium 6.5 | 22 Jan 2026 |
| CVE-2026-20883 | Gitea's stopwatch API does not re-validate repository access permissions. After a user's access to a private repository is revoked, they may still view issue titles and repository names through previously started stopwatches. | Medium 6.5 | 22 Jan 2026 |
| CVE-2026-20888 | Gitea does not properly verify authorization when canceling scheduled auto-merges via the web interface. A user with read access to pull requests may be able to cancel auto-merges scheduled by other users. | Medium 4.3 | 22 Jan 2026 |
| CVE-2026-20736 | Gitea does not properly verify repository context when deleting attachments. A user who previously uploaded an attachment to a repository may be able to delete it after losing access to that repository by making the request through a different repository they can access. | High 7.5 | 22 Jan 2026 |
| CVE-2026-20750 | Gitea does not properly validate project ownership in organization project operations. A user with project write access in one organization may be able to modify projects belonging to a different organization. | Critical 9.1 | 22 Jan 2026 |
| CVE-2026-0798 | Gitea may send release notification emails for private repositories to users whose access has been revoked. When a repository is changed from public to private, users who previously watched the repository may continue to receive release notifications, potentially disclosing release titles, tags, and content. | Low 3.5 | 22 Jan 2026 |
| CVE-2025-69413 | In Gitea before 1.25.2, /api/v1/user has different responses for failed authentication depending on whether a username exists. | Medium 5.3 | 1 Jan 2026 |
| CVE-2025-68946 | In Gitea before 1.20.1, a forbidden URL scheme such as javascript: can be used for a link, aka XSS. | Medium 5.4 | 26 Dec 2025 |
| CVE-2025-68945 | In Gitea before 1.21.2, an anonymous user can visit a private user's project. | Medium 5.8 | 26 Dec 2025 |
| CVE-2025-68943 | Gitea before 1.21.8 inadvertently discloses users' login times by allowing (for example) the lastlogintime explore/users sort order. | Medium 5.3 | 26 Dec 2025 |
| CVE-2025-68944 | Gitea before 1.22.2 sometimes mishandles the propagation of token scope for access control within one of its own package registries. | Medium 5.0 | 26 Dec 2025 |
| CVE-2025-68939 | Gitea before 1.23.0 allows attackers to add attachments with forbidden file extensions by editing an attachment name via an attachment API. | High 8.2 | 26 Dec 2025 |
| CVE-2025-68940 | In Gitea before 1.22.5, branch deletion permissions are not adequately enforced after merging a pull request. | Low 3.1 | 26 Dec 2025 |
| CVE-2025-68941 | Gitea before 1.22.3 mishandles access to a private resource upon receiving an API token with scope limited to public resources. | Medium 4.9 | 26 Dec 2025 |
| CVE-2025-68942 | Gitea before 1.22.2 allows XSS because the search input box (for creating tags and branches) is v-html instead of v-text. | Medium 5.4 | 26 Dec 2025 |
| CVE-2025-68938 | Gitea before 1.25.2 mishandles authorization for deletion of releases. | Medium 4.3 | 26 Dec 2025 |
| CVE-2022-38795 | In Gitea through 1.17.1, repo cloning can occur in the migration function. | Medium 6.5 | 7 Aug 2023 |
| CVE-2023-3515 | Open Redirect in GitHub repository go-gitea/gitea prior to 1.19.4. | Medium 4.4 | 5 Jul 2023 |
| CVE-2022-46685 | In Jenkins Gitea Plugin 1.4.4 and earlier, the implementation of Gitea personal access tokens did not support credentials masking, potentially exposing them through the build log. | Medium 4.3 | 12 Dec 2022 |
| CVE-2022-42968 | Gitea before 1.17.3 does not sanitize and escape refs in the git backend. Arguments to git commands are mishandled. | Critical 9.8 | 16 Oct 2022 |
| CVE-2022-38183 | In Gitea before 1.16.9, it was possible for users to add existing issues to projects. Due to improper access controls, an attacker could assign any issue to any project in Gitea (there was no permission check for fetching the issue). As a result, the attacker would get access to private issue titles. | Medium 6.5 | 12 Aug 2022 |
| CVE-2022-1928 | Cross-site Scripting (XSS) - Stored in GitHub repository go-gitea/gitea prior to 1.16.9. | Medium 5.4 | 29 May 2022 |
| CVE-2022-30781 | Gitea before 1.16.7 does not escape git fetch remote. | High 7.5 | 16 May 2022 |
| CVE-2022-27313 | An arbitrary file deletion vulnerability in Gitea v1.16.3 allows attackers to cause a Denial of Service (DoS) via deleting the configuration file. | High 7.5 | 3 May 2022 |
| CVE-2022-1058 | Open Redirect on login in GitHub repository go-gitea/gitea prior to 1.16.5. | Medium 6.1 | 24 Mar 2022 |
| CVE-2021-29134 | The avatar middleware in Gitea before 1.13.6 allows Directory Traversal via a crafted URL. | Medium 5.3 | 15 Mar 2022 |
| CVE-2022-0905 | Missing Authorization in GitHub repository go-gitea/gitea prior to 1.16.4. | High 7.1 | 10 Mar 2022 |
| CVE-2021-45331 | An Authentication Bypass vulnerability exists in Gitea before 1.5.0, which could let a malicious user gain privileges. If captured, the TOTP code for the 2FA can be submitted correctly more than once. | Critical 9.8 | 9 Feb 2022 |
Original policy
Copied from sorona.xyz on 12 Nov 2026. The summaries on this page are made from it; the live page may have changed since.
Skip to content What this pays This project runs no bounty of its own. sorona.xyz pays you directly on qualified, reproduced findings. Severity │ sorona.xyz pays Critical │ $1,500+ High │ $700+ Medium │ $300+ Low │ $100 / 1 month Claude Max Submit a vulnerability CVE history 75 Last 12 months 75 Lifetime Access control 35 % Supply chain 25 % SSRF 20 % Cross-site scripting 20 % Latest advisories Loading the feed Overview Gitea is the self-hosted Git service that a very large homelab and small-enterprise population runs instead of GitHub. One binary carries the repositories, a set of package registries and Actions runners with access to whatever secrets those workflows hold. Source code and CI credentials sitting together means an authorization defect there is a supply-chain compromise of everything the server builds. Gitea's SECURITY.md asks for private reports at a security address and offers public thanks as the reward, with no money from the project and none from any platform. sorona.xyz pays you directly on qualified, reproduced findings. In scope SECURITY.md asks reporters not to file a public issue and to send the report privately to [email protected] , offering public thanks in return. It declares no boundary narrower than Gitea itself Repository access control across public, private, limited and internal visibility, and the organisation, team and collaborator model on top of it The Git transport layer over HTTP and SSH, including the built-in SSH server, authorized keys handling and the internal protocol between components Authentication in full: local accounts, OAuth2 providers, OpenID Connect, LDAP, SMTP, PAM and SPNEGO, plus two-factor and WebAuthn handling Personal access tokens and their scopes, OAuth2 application authorization, and the API key paths scripted consumers use Gitea Actions end to end: the runner registration and protocol, job dispatch, secret and variable injection, and workflow triggering from forks and pull requests Every package registry the binary ships, covering Container, npm, Maven, PyPI, Go, Composer, NuGet, Debian, RPM, Alpine and the rest, along with the authentication on each Webhooks, repository migration and mirroring, and every other path where Gitea fetches a URL a user supplied Rendering of Markdown, issue and comment content, repository files and the file preview paths The full HTTP API, the admin panel and every setting an administrator can change on a running instance Git LFS storage and the object access checks in front of it Archive generation, raw file serving, attachments and avatar handling The built-in web editor, file upload, and the notification and mail paths Pull request merging, protected branches and the approval rules meant to gate a merge Out of scope Forgejo, a separate fork with its own security process, even where the code is shared The git binary and any external tool Gitea shells out to A repository, organisation or package an administrator deliberately made public Workloads a user's own Actions workflow chose to run, which execute what the workflow author wrote The reverse proxy and TLS termination in front of Gitea Third-party themes, templates and custom assets an operator installed Most-valued findings Repository authorization defects where a user reads, writes or forks a private repository their permissions never covered, including through the API, LFS, raw file serving, the archive builder and search Actions defects where a workflow from a fork or an untrusted branch reaches repository secrets or the runner's environment. That is the defining CI vulnerability class and Gitea puts it in the same process as the source Authentication bypass in any external identity provider, and token scope handling where a limited token performs a full-access operation Server-side request forgery from migration, mirroring or webhooks, all of which fetch a URL a user supplies from a server that sits inside the network Package registry paths letting a user publish over, delete or read another owner's package, since downstream builds pull from those registries by name Stored cross-site scripting in Markdown, issue content or file rendering, escalating to API calls in an administrator's session Path traversal in repository file serving, the archive builder or the attachment paths Protected branch and approval bypass, where a change merges without the review the branch rules require CVE-2026-20800 and CVE-2026-20896 are the two entries the study records for the current cycle. It describes neither, so treat the published record as thin rather than as a map Program rules Submit through sorona.xyz. This project runs no bounty of its own; we validate, coordinate disclosure with the maintainers, and pay you directly. Report privately to [email protected] , the address SECURITY.md publishes along with a GPG key. GitHub Security Advisories are used for publication Do not file a public issue. The policy says so directly and a public report burns the embargo The reward is public thanks, and the project will keep your name confidential if you ask. There is no money here from the project or any platform huntr once paid small bounties covering Gitea. It has pivoted to AI and ML only and those pages are sunsetting, so do not plan on a payout there Forgejo is a separate fork with its own security process. If the code you found it in is shared, say so, but file the Gitea report with Gitea Give the account's repository and organisation permissions precisely. Almost every severe finding here is a specific permission level reaching something one level above it Disclosure Coordinated privately with the Gitea maintainers by email, published as a GitHub Security Advisory with a CVE alongside a patched release. Gitea ships security fixes in point releases on the current and previous minor versions, so the embargo runs to that release. Reporters are credited publicly by default and kept anonymous on request. Safe harbor Sorona will not pursue legal action against you for good-faith research submitted to us in line with this policy. We cannot speak for the upstream project, its vendor, or any third party, and we do not grant authorization on their behalf. You are responsible for understanding and following the laws that apply to you, wherever you are, and for staying within any scope the project has defined. Submit a vulnerability