Export limit exceeded: 418266 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Export limit exceeded: 418266 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Export limit exceeded: 418266 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (418266 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2026-118386 | 1 Gitea | 1 Gitea | 2026-11-01 | N/A |
| Workflows triggered by a pull request review were read from the commit named in the review's `commit_id`, while the fork restrictions were decided by the reviewed pull request, and the commit was not checked to belong to that pull request. A user with read access to a repository could place a commit of their own in it, through a fork pull request or an AGit push, and submit a review naming that commit on a pull request whose head branch is in the same repository. On instances with a runner serving the repository, the attacker's workflow then ran without approval, received the Actions secrets of the repository and its owner, and got a `GITEA_TOKEN` with write access to the repository. Review-triggered workflows now run on the pull request head. | ||||
| CVE-2026-120263 | 1 Gitea | 1 Gitea | 2026-11-01 | N/A |
| When `[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. | ||||
| CVE-2026-116289 | 1 Gitea | 1 Gitea | 2026-11-01 | N/A |
| Gitea 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. | ||||
| CVE-2026-116296 | 1 Gitea | 1 Gitea | 2026-11-01 | N/A |
| The API routes for releases, release assets, milestones and repository labels did not reject changes to archived repositories. A user with write access to an archived repository, or a holder of such a user's write-scoped token, could replace or delete release assets while keeping their download URLs, delete releases and tags, and create, edit or delete milestones and labels of a repository that is meant to be read-only. Changing requests on these routes now return 423 Locked for archived repositories. | ||||
| CVE-2026-116474 | 1 Gitea | 1 Gitea | 2026-11-01 | N/A |
| The `GITEA_TOKEN` of a Gitea Actions job authenticates as the `gitea-actions` system user, and the `/api/v1/user` email and GPG key endpoints accepted that user, so a job could register an email address and a GPG key on it; without required email confirmation (the default) the address is stored as activated. Commit verification treats a key without a real owner as the instance signing key, so any user who can run a workflow job could make commits signed with their own key show as trusted and signed by the instance in every repository where they appear, including pull requests to repositories the user cannot write to. The impact is limited to the displayed signature status: enforcement such as required signed commits only checks that a signature is verified and is unaffected, and no access is gained. The `/api/v1/user` routes now reject system users. | ||||
| CVE-2026-117635 | 1 Gitea | 1 Gitea | 2026-11-01 | N/A |
| The `/api/v1/admin` route group did not enforce the `public-only` restriction of personal access tokens. A public-only token with admin scope issued by a site administrator could therefore list private organizations and the email addresses of all users, create organizations, obtain runner registration tokens and create new site administrator accounts, the last of which persists after the token is revoked. Tokens of users who are not site administrators cannot reach these routes; public-only tokens are now rejected on the admin API. | ||||
| CVE-2026-117649 | 1 Gitea | 1 Gitea | 2026-11-01 | N/A |
| The issue timeline API and the web issue page hid cross-reference events that point at issues the reader cannot access, but not "dependency added" and "dependency removed" events. When a readable issue had been linked as a dependency to an issue in a repository the reader cannot access, for example a private repository, any reader of the first issue, including anonymous users of a public repository, received the linked issue's current title, body, state, labels, poster and attachment names through the API, and its repository, number and title on the web page. Creating the link requires access to both issues; comments and attachment downloads of the linked issue stayed protected. Dependency events are now filtered with the same read permission check; a related exposure of unlinked attachment metadata through hidden dependency placeholders was already fixed in 28.2.0. | ||||
| CVE-2026-117677 | 1 Gitea | 1 Gitea | 2026-11-01 | N/A |
| When parsing an uploaded Helm chart, Gitea decompressed the archive and read every tar entry while looking for `Chart.yaml` without limiting the decompressed size, and did so before the package size quota was checked; the quota only considers the compressed upload size. A user with package write access to an owner, for example their own account on an instance with open registration, could repeatedly upload small, highly compressed archives that make the server spend CPU time proportional to the decompressed size, degrading the availability of the Gitea instance. The issue does not allow code execution or data access. | ||||
| CVE-2026-117685 | 1 Gitea | 1 Gitea | 2026-11-01 | N/A |
| The 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. | ||||
| CVE-2026-118394 | 1 Gitea | 1 Gitea | 2026-11-01 | N/A |
| The OAuth2 userinfo endpoint (`/login/oauth/userinfo`) decided whether to limit the `groups` claim to public organizations by re-parsing the `Authorization` header as an OAuth2 access token instead of using the scope of the credential that authenticated the request. When a public-only OAuth2 token was sent as a query parameter or form field, or a public-only personal access token was used, that scope came back empty and the claim listed the token owner's private organizations, teams and concealed memberships. The disclosure is limited to the owner's organization and team names and memberships; no repository content is exposed. The endpoint now uses the scope of the authenticating token. | ||||
| CVE-2026-119441 | 1 Gitea | 1 Gitea | 2026-11-01 | N/A |
| `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. | ||||
| CVE-2026-119533 | 1 Gitea | 1 Gitea | 2026-11-01 | N/A |
| Repository 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. | ||||
| CVE-2026-119627 | 1 Gitea | 1 Gitea | 2026-11-01 | N/A |
| The web profile and RSS/Atom feed routes of users and organizations checked only whether a signed-in viewer could see a limited-visibility owner, without considering the `public-only` restriction of the personal access token used to authenticate. Any user holding a public-only token could send it over HTTP Basic authentication to read the profile and activity feed of limited-visibility users and organizations, which are hidden from anonymous visitors and refused on the equivalent API routes. The disclosure covers existence, profile metadata and public activity; it does not grant write access. | ||||
| CVE-2026-120225 | 1 Oray | 1 Pugongying X5 Pro | 2026-11-01 | 9.1 Critical |
| A weakness has been identified in Oray Pugongying X5 Pro up to 7.6.1. Affected by this vulnerability is the function config_restore_ex of the file /etc/openwrt_release. This manipulation of the argument filename causes relative path traversal. The attack may be initiated remotely. The exploit has been made available to the public and could be used for attacks. The vendor was contacted early about this disclosure but did not respond in any way. | ||||
| CVE-2026-39738 | 2026-11-01 | 9.8 Critical | ||
| Deserialization of Untrusted Data vulnerability in Aman FunnelKit Automations wp-marketing-automations allows Object Injection.This issue affects FunnelKit Automations: from n/a through 3.8.6.1. | ||||
| CVE-2026-120217 | 1 Delgan | 1 Loguru | 2026-11-01 | 4.3 Medium |
| A vulnerability was detected in Delgan loguru 0.7.3. The affected element is the function AnsiParser.feed of the file loguru/_colorizer.py of the component ANSI Color-Markup Parser. Performing a manipulation results in inefficient regular expression complexity. The attack is possible to be carried out remotely. The exploit is now public and may be used. The vendor was contacted early about this disclosure but did not respond in any way. | ||||
| CVE-2026-7233 | 1 Artifex | 1 Mupdf | 2026-11-01 | 3.3 Low |
| A vulnerability was determined in Artifex MuPDF. The impacted element is the function fz_subset_cff_for_gids of the file subset-cff.c of the component CFF Index Handler. This manipulation causes out-of-bounds read. The attack can only be executed locally. The exploit has been publicly disclosed and may be utilized. The project was informed of the problem early through a bug report but has not responded yet. | ||||
| CVE-2026-120218 | 1 Typemill | 1 Typemill | 2026-11-01 | 3.5 Low |
| A flaw has been found in Typemill up to 2.26.0. The impacted element is the function ControllerApiImage::saveImage of the file system/typemill/Models/SvgSanitizer.php. Executing a manipulation can lead to cross site scripting. The attack may be performed from remote. The exploit has been published and may be used. Upgrading to version 2.27.0 is sufficient to resolve this issue. This patch is called 9ca43c4a7b6764c5a6ac11a2ccc099b036ee3cef. It is recommended to upgrade the affected component. | ||||
| CVE-2026-74245 | 1 Redhat | 3 Openshift Update Service, Quay, Quay 3 | 2026-11-01 | 5.9 Medium |
| A flaw was found in Red Hat Quay's exported logs feature. An unauthenticated attacker with a valid file ID could download exported action logs without proper authorization. While file IDs are complex, they can be intercepted from plaintext email or webhook callbacks. This vulnerability leads to information disclosure, potentially exposing sensitive data such as usernames, email addresses, IP addresses, and action-specific metadata. | ||||
| CVE-2026-74241 | 1 Redhat | 3 Openshift Update Service, Quay, Quay 3 | 2026-11-01 | 4.8 Medium |
| A flaw was found in Red Hat Quay's external Lightweight Directory Access Protocol (LDAP) authentication handling. When an LDAP referral is returned during authentication, the system does not properly escape the username input. This allows an attacker to inject LDAP filter metacharacters, enabling user-existence oracle attacks at the referral Directory Name (DN). This could also potentially influence which DN is used for password binding in multi-domain Active Directory environments. | ||||