Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
105 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
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.
Recommended action: Upgrade to 1.26.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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.
Recommended action: Upgrade to 1.25.5 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Gitea versions before 1.25.5 allow draft release data or attachments to be accessed without the required write permission.
Recommended action: Upgrade to 1.25.5 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Gitea versions before 1.25.5 accept malformed or injected forwarded-proto values when detecting public URLs, allowing spoofed canonical URL generation.
Recommended action: Upgrade to 1.25.5 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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.
Recommended action: Upgrade to 1.25.5 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Gitea versions before 1.25.5 do not enforce a timeout on git grep searches, allowing expensive searches to consume server resources.
Recommended action: Upgrade to 1.25.5 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Gitea versions before 1.25.5 have insufficient permission checks when listing tracked time entries.
Recommended action: Upgrade to 1.25.5 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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.
Recommended action: Upgrade to 1.25.5 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Gitea versions before 1.25.5 do not consistently enforce OAuth2 authorization code expiry and single-use behavior during token exchange.
Recommended action: Upgrade to 1.25.5 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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.
Recommended action: Upgrade to 1.25.5 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Gitea versions before 1.25.5 allow a user to change another user's primary email address.
Recommended action: Upgrade to 1.25.5 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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.
Recommended action: Upgrade to 1.25.5 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Gitea versions before 1.25.5 have insufficient visibility checks in organization permission APIs for hidden members and private organizations.
Recommended action: Upgrade to 1.25.5 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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.
Recommended action: Upgrade to 1.25.5 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Gitea versions before 1.25.5 have insufficient permission checks for updating or rebasing pull request branches.
Recommended action: Upgrade to 1.25.5 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The POST /api/v1/repos/{owner}/{repo}/merge-upstream endpoint continues to synchronize commits from a parent repository after the parent repository has been changed from public to private. A fork created while the parent repository was public can still receive commits made after the parent repository becomes private. As a result, content added during the private period becomes available through the fork repository after synchronization. Details Gitea provides the merge-upstream API to synchronize a fork with its parent repository. A typical workflow is: 1. A repository is public. 2. Another user creates a fork. 3. The fork owner uses merge-upstream to receive updates from the parent repository. However, if the parent repository is later changed from public to private, the synchronization endpoint continues to import new commits from the parent repository into the fork. In testing on Gitea 1.26.2, a fork owner who can no longer directly access the parent repository is still…
Recommended action: Upgrade to 1.26.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Gitea does not re-evaluate the official flag on existing pull request reviews when a PR's target branch is changed. An attacker with write access to a repository can obtain an official: true approval on a PR targeting an unprotected branch, then retarget the PR to a protected branch (e.g., master). The approval, which would have been official: false if submitted against the protected branch, is preserved and satisfies the protected branch's required approvals, allowing the attacker to merge without legitimate maintainer approval. - Confirmed on Gitea 1.25.4 (1.25.4+41-g96515c0f20) Vulnerability Details Root Cause When a review is submitted on a pull request, Gitea computes the official flag by checking whether the reviewer is in the target branch's approval whitelist (IsUserOfficialReviewer in models/git/protectedbranch.go). This flag is stored in the database as a boolean on the review record. When a PR's target branch is subsequently changed via ChangeTargetBranch…
Recommended action: Upgrade to 1.27.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Gitea Actions Artifacts V4 signed upload/download URLs can be rewritten to access a different running task and repository context while preserving the original HMAC signature. An attacker with permission to run a Gitea Actions job can turn a signed URL for an attacker-controlled artifact into a URL that reads artifacts from another task context, or writes attacker-controlled data into another task's artifact upload staging context, including in a private repository. This is one vulnerability with two exploit paths: - DownloadArtifact: cross-task/cross-repository artifact read, giving C:H. - UploadArtifact: cross-task artifact staging write and metadata mutation, giving I:H. Details The root cause is that the V4 artifact signed URL signature is built from raw concatenated fields without delimiters or length-prefixing: Affected code: routers/api/actions/artifactsv4.go:164-171. Because artifactName, taskID, and artifactID are concatenated without boundaries, two different URL…
Recommended action: Upgrade to 1.26.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Gitea 1.26.2 does not properly enforce organization visibility restrictions on organization label read endpoints. A user without access to a private organization can retrieve labels belonging to that organization through the Organization Labels API. As a result, label metadata intended to be restricted to organization members may be disclosed. The issue is limited to unauthorized read access. No unauthorized modification of labels was observed. Details The following endpoints are affected: GET /api/v1/orgs/{org}/labels GET /api/v1/orgs/{org}/labels/{id} During testing, a private organization was created and a label was added to that organization. Access to the organization itself was correctly restricted. A user without membership in the organization received a 404 Not Found response when requesting organization information. However, the same user was still able to retrieve organization labels through the endpoints listed above. For comparison, other organization-scoped…
Recommended action: Upgrade to 1.26.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The API endpoint used to fork repositories into organizations performs a weaker authorization check than the corresponding web UI and other repository creation endpoints. When a repository is forked into an organization through the API, the endpoint only verifies that the user is an organization member (IsOrgMember()), but does not verify whether the user is allowed to create repositories in that organization (CanCreateOrgRepo()). As a result, organization members belonging to teams with cancreateorgrepo=false can still create repositories inside the organization by using the fork API. Details Affected endpoint: In routers/api/v1/repo/fork.go, the endpoint performs the following authorization check: The equivalent web UI implementation uses the stronger permission check: The same CanCreateOrgRepo() authorization check is also used by: CreateOrgRepo API endpoint GenerateRepository API endpoint The fork endpoint appears to be the only repository creation path that relies solely…
Recommended action: Upgrade to 1.26.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
This issue has been found by a security agent and review by myself. Gitea's CODEOWNERS feature uses the regexp2 library to match file paths against ownership rules. User-supplied patterns are passed directly to regexp2.Compile with no sanitisation and no match timeout. This allows an attacker to write a pattern that causes the regex engine to backtrack exponentially when evaluated against a crafted file path. Who can trigger it Any registered user on the instance. The attacker needs only: 1. A repository they own (created via normal signup) 2. A CODEOWNERS file on the default branch containing malicious patterns 3. A pull request branch containing a file with a crafted name No elevated permissions, no admin access, no existing repositories required. How it is triggered The attacker pushes a CODEOWNERS file containing repeated instances of a catastrophic backtracking pattern (e.g. (a+)+ @attacker) and opens a pull request from a branch that contains a file named with a long string of…
Recommended action: Upgrade to 1.26.4 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Gitea: SSRF via HTTP Redirect in Repository Migration in code.gitea.io/gitea
Recommended action: Upgrade to 1.26.4 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
I'm reporting two related TOTP one-time-use defects in Gitea that survive the CVE-2021-45331 fix. The 2018 fix (PR #3878) introduced the TwoFactor.LastUsedPasscode field and added an in-memory inequality check on the web 2FA login path. That check works correctly in the single-request case, but it leaves two follow-up gaps: 1. A TOCTOU race on the web surfaces (Defect 1). The read-validate-check-save sequence against the twofactor row is not atomic. Two parallel submissions of the same passcode each load their own in-memory copy where LastUsedPasscode still holds the prior value; both pass the inequality check, both authenticate, and both then write the same new value back. Net effect: the same OTP redeems for two independent logged-in sessions. 2. No LastUsedPasscode check at all on the Basic-Auth API surface (Defect 2). services/auth/basic.go calls twofa.ValidateTOTP(...) for X-Gitea-OTP without ever reading or writing LastUsedPasscode. The same six-digit code is replayable…
Recommended action: Upgrade to 1.26.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A personal access token restricted with the public-only scope can still retrieve private organization membership and organization permission details for its own account through organization-listing endpoints. This bypass breaks the intended guarantee that such tokens are limited to public resources only. Details The issue affects the following endpoints: GET /api/v1/user/orgs GET /api/v1/users/{username}/orgs/{org}/permissions The application correctly prevents a public-only token from directly accessing a private organization through: GET /api/v1/orgs/{org} However, that same token can still obtain private organization data through alternate code paths. The root cause is inconsistent enforcement of the public-only restriction. The middleware responsible for blocking non-public organization access depends on route context being populated with the target organization. That assumption does not hold for all affected routes. For GET /api/v1/user/orgs, the route does not apply…
Recommended action: Upgrade to 1.27.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The ToHook() function in services/webhook/general.go decrypts the webhook's HeaderAuthorizationEncrypted field and returns the plaintext authorization header in the API response. Any repository admin can read the full plaintext value of webhook authorization headers (Bearer tokens, Basic auth credentials, API keys) set by other admins. The authorization header is stored encrypted in the database using the server's SecretKey, but ToHook() decrypts it before serializing it into the API response — converting a write-only secret into a readable credential. Vulnerable Code File: services/webhook/general.go:407-420 Decryption function: models/webhook/webhook.go:209-216 Affected Endpoints All call ToHook(): - GET /api/v1/repos/{owner}/{repo}/hooks (requires repo admin) - GET /api/v1/repos/{owner}/{repo}/hooks/{id} (requires repo admin) - GET /api/v1/admin/hooks (requires site admin) - GET /api/v1/orgs/{org}/hooks (requires org admin) - GET /api/v1/user/hooks (requires authenticated…
Recommended action: Upgrade to 1.27.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.