https://vulnfeed.org/Every disclosure, as it lands. Critical-only feed available.enhttps://vulnfeed.org/cve/CVE-2026-116289/https://vulnfeed.org/cve/CVE-2026-116289/Sun, 01 Nov 2026 10:18:34 +0000Gitea did not reject personal access tokens restricted to public resources (`public-only`) on the organization Actions runner registration-token endpoint, and the runner registered with the resulting token was not limited to public repositories. Holding only such a token with `write:organization` that belongs to an owner of a public organization, an attacker could register an organization-level runner and receive jobs of the organization's private repositories that have Actions enabled, including the workflow content, Actions secrets and variables, and a task token with access to the private repository. The issue widens what the restricted token can reach; it gives nothing beyond what the owner's full account can already do.https://vulnfeed.org/cve/CVE-2026-119533/https://vulnfeed.org/cve/CVE-2026-119533/Sun, 01 Nov 2026 09:48:55 +0000Repository and organization project boards listed the pull requests that reference each issue on the board without checking whether the viewer can read them. When a private pull request mentions an issue on a board the viewer can open, the board revealed the private repository's path and the pull request's number, title and state, to anonymous visitors in the case of a public board. The pull request body, diff and files were not exposed. Boards now skip linked pull requests in repositories where the viewer cannot read pull requests.https://vulnfeed.org/cve/CVE-2026-119441/https://vulnfeed.org/cve/CVE-2026-119441/Sun, 01 Nov 2026 09:48:54 +0000`DELETE /api/v1/orgs/{org}/repos` deletes all repositories of an organization, but it did not enforce the public-only restriction of access tokens: the route only checked that the organization itself was public. A public-only token of an owner of a public organization could therefore permanently delete the organization's private repositories, which such a token must not reach. Routes that require organization ownership now reject public-only tokens.https://vulnfeed.org/cve/CVE-2026-118395/https://vulnfeed.org/cve/CVE-2026-118395/Sun, 01 Nov 2026 09:48:51 +0000Gitea 1.27.3 stopped personal access tokens restricted to public resources (`public-only`) from creating repositories through `POST /api/v1/user/repos` and `POST /api/v1/repos/migrate`, but `POST /api/v1/org/{org}/repos`, `POST /api/v1/orgs/{org}/repos`, `POST /api/v1/orgs` and `POST /api/v1/repos/{owner}/{repo}/generate` still accepted such tokens. A holder of a public-only token with the needed write scopes could create private repositories in organizations where the token's owner may create repositories, create private organizations, and generate private repositories from templates. The token still could not read the private repositories it created.https://vulnfeed.org/cve/CVE-2026-117685/https://vulnfeed.org/cve/CVE-2026-117685/Sun, 01 Nov 2026 09:48:46 +0000The OCI registry's cross-repository blob mount checked the target package against the token's `public-only` restriction, but checked the source blob only against the full account permissions of the token owner. A `public-only` token with `write:package` scope, whose owner can read a private package and write to a public package namespace, could mount a blob of the private package into the public package. The private blob, such as a container layer, could then be downloaded by anyone through the public package.https://vulnfeed.org/cve/CVE-2026-120263/https://vulnfeed.org/cve/CVE-2026-120263/Sun, 01 Nov 2026 09:47:09 +0000When `[oauth2_client].ACCOUNT_LINKING` is set to `auto` (not the default) and registration is enabled, the link-account sign-up form looked up the existing account to link by the user name or email submitted in the form instead of the identity asserted by the OAuth2 provider. An attacker with an account on a configured OAuth2 provider could submit another user's name, link their external identity to that Gitea account and be signed in as it without its password, including as an administrator. The link persisted for later sign-ins. Automatic linking now only happens when the existing account matches the provider's email or provider-derived user name; otherwise the account password is required.https://vulnfeed.org/cve/CVE-2026-60004/https://vulnfeed.org/cve/CVE-2026-60004/Wed, 26 Aug 2026 19:45:00 +0000Gitea contains a code injection vulnerability that allows an attacker with repository write access to send a malicious patch to the diffpatch API endpoint to plant an executable Git hook and run shell commands as the Gitea service account.