Export limit exceeded: 408108 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (408108 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2026-89310 | 2026-10-14 | 9.9 Critical | ||
| A parameter taken from the request body is inserted into a T-SQL statement without parameterization or escaping, allowing a remote attacker to execute arbitrary SQL statements in the context of the application's database account. | ||||
| CVE-2026-85471 | 2 Red Hat, Redhat | 4 Red Hat Quay 3, Mirror Registry, Mirror Registry For Red Hat Openshift and 1 more | 2026-10-14 | 6.4 Medium |
| A flaw was found in Quay. An authenticated repository administrator could bypass the hostname blacklist in webhook notifications, leading to a Server-Side Request Forgery (SSRF) vulnerability. This allows the Quay application to be tricked into sending requests to internal network resources, such as cloud metadata services or other services within the cluster. Consequently, this could lead to the disclosure of sensitive information from these internal services. | ||||
| CVE-2026-82026 | 2026-10-14 | 8.8 High | ||
| Radar before 1.12.2 contains a missing authorization vulnerability in the handleLocalTerminal WebSocket endpoint (/api/local-terminal) that allows authenticated or unauthenticated attackers to spawn a privileged shell by relying only on a runtime-mode check instead of role-based access control. Attackers can connect to the endpoint to execute /bin/bash -l on the Radar host with Radar's own kubeconfig and process credentials injected into the shell environment, achieving remote code execution with Radar's privileges even when the --disable-local-terminal flag is set. | ||||
| CVE-2026-77459 | 1 Argoproj | 1 Argo-cd | 2026-10-14 | 9.9 Critical |
| Argo CD is a declarative, GitOps continuous delivery tool for Kubernetes. From 2.10.0 until 3.3.15, 3.4.10, 3.5.4, and 3.6.0-rc2, Argo CD creates PostDelete resource hooks without applying the AppProject destination and resource authorization checks used during ordinary synchronization. The omitted checks include cluster-scoped and namespaced resource allow/deny lists. A user who can write to an Application's Git repository can commit a delete hook targeting a forbidden namespace, server, group, kind, or resource name, and deletion of the Application causes the application-controller to create that resource with its destination-cluster credentials. The reachable impact is bounded by the controller's cluster access but can include cluster-scoped resources, disallowed namespaces, persistent hook objects, and secondary objects created by a hook Job. PreSync, Sync, PostSync, and SyncFail hooks continue to use the normal project checks. This issue is fixed in versions 3.3.15, 3.4.10, 3.5.4, and 3.6.0-rc2. | ||||
| CVE-2026-71301 | 2026-10-14 | 4.3 Medium | ||
| Gitea's repository markup endpoint resolves same-repository pull request references without enforcing the viewer's Pull Requests permission. A member with only Wiki access to a private repository can submit a markup preview request and retrieve a private pull request's title and state icon despite lacking Issues and Pull Requests access. This exposes pull request metadata across repository unit permissions. | ||||
| CVE-2026-68964 | 2026-10-14 | 4.3 Medium | ||
| Gitea's user SSH and GPG key-list API endpoints omit the profile visibility check applied by their web equivalents. A restricted account can retrieve public keys, key titles, fingerprints, and GPG-embedded email addresses belonging to Limited-visibility users. The disclosure concerns public key material and associated metadata, not private cryptographic keys. | ||||
| CVE-2026-68957 | 2026-10-14 | 4.3 Medium | ||
| Gitea's API and web issue-search paths do not treat restricted accounts as anonymous viewers when evaluating Limited-visibility repository owners. A restricted user can search and retrieve issue titles and bodies that should be hidden by the owner's visibility policy. Keyword matching can also reveal that hidden issue content or comments contain a supplied term. | ||||
| CVE-2026-67577 | 2026-10-14 | 4.3 Medium | ||
| Gitea's activity-feed and contribution-heatmap API handlers do not apply the profile visibility check for restricted accounts viewing Limited-visibility users. A restricted user can retrieve activity records and contribution timestamps that the corresponding profile routes deny. Exposed activity can include repository names, commit messages, and issue or pull request events associated with qualifying public-repository activity. | ||||
| CVE-2026-66877 | 2026-10-14 | 8.1 High | ||
| Gitea enforces first-time fork contributor approval by blocking jobs, but some job transition and dispatch paths do not re-check the run's approval requirement. A separate run sharing a job-level concurrency group can cancel a pending job and cause its blocked sibling jobs to be re-emitted and dispatched without approval. This allows unreviewed workflow code to execute on self-hosted runners; fork secrets remain withheld and the run token remains read-only. | ||||
| CVE-2026-66874 | 2026-10-14 | 6.5 Medium | ||
| For pull request events, Gitea reads workflow definitions from the pull request head and posts a synthetic skipped status when workflow branch or path filters exclude execution. A fork pull request author can supply a workflow matching a required status context but deliberately prevent it from running. Because skipped statuses count as success, branch protection or organization-required workflow checks can appear satisfied without the mandated workflow executing; no runner or maintainer approval is required for this path. | ||||
| CVE-2026-66853 | 2026-10-14 | 4.3 Medium | ||
| Gitea's user organization-list API includes Limited-visibility organizations for authenticated restricted accounts without applying the visibility restriction enforced by the single-organization endpoint. A restricted user can list a known user's public organization memberships and retrieve limited organizations' names, descriptions, and avatars. This exposes organization metadata that should be hidden from the requesting account. | ||||
| CVE-2026-66849 | 2026-10-14 | 4.3 Medium | ||
| Gitea's package registry grants authenticated users read access to packages owned by Limited-visibility users without excluding restricted accounts. A restricted user can enumerate and download those packages despite the visibility policy that should prevent this access. The issue affects user-owned package registries and exposes package contents across the intended authorization boundary. | ||||
| CVE-2026-101980 | 2026-10-14 | 9.8 Critical | ||
| An Integer Underflow vulnerability in the kernel of Juniper Networks Junos OS with Extended Echo configured allows an unauthenticated, network-based attacker to cause a denial of service by a kernel crash. | ||||
| CVE-2026-66057 | 1 Frappe | 1 Frappe | 2026-10-14 | N/A |
| Frappe is a full-stack web application framework. Prior to 15.116.0 and 16.29.0, the OAuth login flow uses an unsanitized client-controlled state parameter to select post-authentication navigation, allowing a crafted state value to redirect a user to an attacker-chosen location. This issue is fixed in versions 15.116.0 and 16.29.0. | ||||
| CVE-2026-63792 | 2026-10-14 | 5.3 Medium | ||
| Gitea's collaborative-owner authorization path for reading cross-repository reusable workflows does not exclude fork pull request runs. An approved fork workflow targeting a private repository can read workflow files from another private repository that trusts the base repository's owner through collaborative-owner configuration. The issue exposes private reusable workflow contents at caller-selected Git refs; it does not itself grant write access or code execution in the other repository. | ||||
| CVE-2026-63162 | 2026-10-14 | 8.8 High | ||
| Omnispace Agora Project before 26.10.0 contains a path traversal vulnerability that allows attackers to write arbitrary files outside the intended temporary directory by supplying an unanchored tmpFolderName value in the upload destination path. Attackers can exploit this flaw, for example by setting tmpFolderName to a traversal sequence targeting the web root, to write attacker-controlled files and achieve remote code execution. | ||||
| CVE-2026-63158 | 2026-10-14 | 7.4 High | ||
| Omnispace Agora Project before 26.10.0 contains an authentication bypass vulnerability that allows attackers possessing a user's stored bcrypt password hash to authenticate as that user without knowing the actual password, caused by the legacy AGORAP_LOG/AGORAP_PASS cookie mechanism treating the stored hash as a directly replayable bearer credential. Attackers can set the AGORAP_LOG/AGORAP_PASS cookies with a stolen password hash to impersonate any user, including administrators, and gain unauthorized access to the application. | ||||
| CVE-2026-63156 | 2026-10-14 | 6.1 Medium | ||
| Omnispace Agora Project before 26.10.0 contains a reflected cross-site scripting vulnerability that allows unauthenticated attackers to inject malicious HTML attributes by manipulating the visioUrl parameter, which was not routed through the URL-sanitizing branch of the parameter filter and was urldecoded after filtering. Attackers can craft a malicious URL containing the visioUrl parameter with an attribute breakout payload to execute arbitrary JavaScript in the victim's browser pre-authentication, with the issue fixed in version 26.10.0 via changes to app/Common/Req.php. | ||||
| CVE-2026-63153 | 2026-10-14 | 8.1 High | ||
| Omnispace Agora Project before 26.10.0 contains a broken access control vulnerability in setAffectations() that allows authenticated attackers to insert access-right records for a caller-supplied target space without verifying the caller has rights to that space. Attackers can assign access affectations to spaces outside their own reach, breaking tenant isolation and granting unauthorized access to restricted spaces. | ||||
| CVE-2026-63021 | 2026-10-14 | 6.5 Medium | ||
| Gitea's Swift package parser limits each manifest to 128 KiB but does not limit the number of manifests or their aggregate size before reading them into memory. An authenticated user with package-publish permission can upload a highly compressed archive containing many manifests, causing allocations far larger than the uploaded archive. This can exhaust memory, terminate the process, or cause request failures. | ||||