Gitea

Gitea before 1.27.1 allows remote code execution via the diffpatch API through Git hook installation.

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 the dangerousness of…

Gitea before 1.16.7 does not escape git fetch remote.

models/repo_mirror.go in Gitea before 1.7.6 and 1.8.x before 1.8-RC3 mishandles mirror repo URL settings, leading to remote code execution.

Open Redirect on login in GitHub repository go-gitea/gitea prior to 1.16.5.

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.

Gitea before 1.17.3 does not sanitize and escape refs in the git backend.

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.

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.

Gitea does not properly validate repository ownership when linking attachments to releases.

Gitea does not properly validate repository ownership when deleting Git LFS locks.

Gitea does not properly validate project ownership in organization project operations.

Gitea before 1.5.4 allows remote code execution because it does not properly validate session IDs.

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.

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…

Gitea accepted pushed Git trees containing two entries with the same name, which Git's own consistency checks reject.

Gitea before 1.11.2 is affected by Trusting HTTP Permission Methods on the Server Side when referencing the vulnerable admin or user API.

Gitea 0.9.99 through 1.12.x before 1.12.6 does not prevent a git protocol path that specifies a TCP port number and also contains newlines (with URL encoding) in ParseRemoteAddr in modules/auth/repo_form.go.

Gitea before 1.8.0 allows 1FA for user accounts that have completed 2FA enrollment.

An Authentication Bypass vulnerability exists in Gitea before 1.5.0, which could let a malicious user gain privileges.

An issue exsits in Gitea through 1.15.7, which could let a malicious user gain privileges due to client side cookies not being deleted and the session remains valid on the server side for reuse.

An SSRF vulnerability in webhooks in Gitea through 1.5.0-rc2 and Gogs through 0.11.53 allows remote attackers to access intranet services.

Gitea Actions blocks the jobs of workflow runs from first-time fork pull request contributors until a maintainer approves the run.

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.

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.