Export limit exceeded: 381471 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (3653 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2026-76019 | 1 Google | 1 Chrome | 2026-08-21 | 8.1 High |
| Incorrect authorization in Workers in Google Chrome prior to 151.0.7922.173 allowed a remote attacker who had compromised the renderer process and leveraged social engineering to bypass web origin policy via a crafted HTML page. (Chromium security severity: High) | ||||
| CVE-2026-76341 | 1 Splunk | 2 Splunk, Splunk Enterprise | 2026-08-21 | 5.4 Medium |
| In Splunk Enterprise versions below 10.4.2, 10.2.6, 10.0.9, and 9.4.14, a user who holds the "power" Splunk role could store attacker-controlled Search Processing Language (SPL) in a Table Editor dataset and share the dataset. A user who holds the "admin" Splunk role triggers the SPL when that user opens the dataset in the Table Editor. The SPL runs using the permissions of the second user and could expose all relevant data and modify limited data on the search head. The vulnerability is possible because the Table Editor does not apply SPL safeguards for risky commands when it prepares the dataset initial data. The vulnerability requires the attacker to phish the affected user by tricking them into initiating a request within their browser. The user who holds the "power" Splunk role should not be able to exploit the vulnerability at will. For more information see Define initial data for a new table dataset (https://help.splunk.com/en/splunk-enterprise/manage-knowledge-objects/knowledge-management-manual/9.4/create-and-edit-table-datasets/define-initial-data-for-a-new-table-dataset), SPL safeguards for risky commands (https://help.splunk.com/en/splunk-enterprise/administer/manage-users-and-security/10.2/best-practices-for-splunk-platform-security/spl-safeguards-for-risky-commands), and Define roles on the Splunk platform with capabilities (https://help.splunk.com/en/splunk-enterprise/administer/manage-users-and-security/10.4/manage-splunk-platform-users-and-roles/define-roles-on-the-splunk-platform-with-capabilities) in the Splunk documentation. | ||||
| CVE-2026-76342 | 1 Splunk | 2 Splunk, Splunk Enterprise | 2026-08-21 | 5.4 Medium |
| In Splunk Enterprise versions below 10.4.2, 10.2.6, 10.0.9, and 9.4.14, a user who holds the "power" Splunk role could store risky Search Processing Language (SPL) commands in a Table Editor dataset and share the dataset. A user who holds the "admin" Splunk role triggers the commands when that user opens the dataset in the Table Editor. The commands run using the permissions of the second user and could expose all relevant data and modify lookup files. The vulnerability is possible because the Table Editor does not apply SPL safeguards for risky commands to the field-summary search that it runs for the Initial Data step. The vulnerability requires the attacker to phish the affected user by tricking them into initiating a request within their browser. The user who holds the "power" Splunk role should not be able to exploit the vulnerability at will. For more information see SPL safeguards for risky commands (https://help.splunk.com/en/splunk-enterprise/administer/manage-users-and-security/10.2/best-practices-for-splunk-platform-security/spl-safeguards-for-risky-commands) and Define roles on the Splunk platform with capabilities (https://help.splunk.com/en/splunk-enterprise/administer/manage-users-and-security/10.2/manage-splunk-platform-users-and-roles/define-roles-on-the-splunk-platform-with-capabilities) in the Splunk documentation. | ||||
| CVE-2026-76391 | 1 Splunk | 1 Ai Toolkit | 2026-08-21 | 8.3 High |
| In Splunk AI Toolkit versions below 6.0.0, a user who does not hold the "admin" or "power" Splunk roles could run searches with system-level privileges, access all relevant data, affect system integrity, and read or delete search jobs belonging to other users through Agent Run History. The improper privilege management is possible because the Agent Run History handler replaces the calling user session key with a system authentication token before it performs search operations. For more information see AI Toolkit Agent Launchpad (https://help.splunk.com/en/splunk-enterprise/apply-machine-learning/use-ai-toolkit/6.0.0/ai-toolkit-connections-containers-and-agents/ai-toolkit-agent-launchpad) in the Splunk documentation. | ||||
| CVE-2026-77234 | 1 Freertos | 1 Freertos-kernel | 2026-08-21 | 8.8 High |
| Improper input validation in FreeRTOS-Kernel before 11.3.1 might allow an unprivileged task on MPU-enabled ports to execute code in privileged kernel context. To remediate this issue, users should upgrade to version 11.3.1 or later. | ||||
| CVE-2026-62941 | 1 Lxc | 1 Incus | 2026-08-21 | 9.9 Critical |
| Incus is a system container and virtual machine manager. Prior to version 7.3.0, when copying an instance across projects, the project restriction check (`AllowInstanceCreation`) runs BEFORE the source instance's configuration is merged into the request. Dangerous configuration keys (including `security.privileged`, `raw.lxc`, `raw.apparmor`) from the source instance are merged AFTER the check passes, bypassing all project restrictions on the target project. Version 7.3.0 patches the issue. | ||||
| CVE-2026-62313 | 1 Lxc | 1 Incus | 2026-08-21 | 4.3 Medium |
| Incus is a system container and virtual machine manager. Prior to version 7.3.0, project-level enforcement of `restricted.containers.privilege=isolated` can be trivially bypassed, allowing a user to create a non-isolated (shared host idmap) container in a project that is configured to forbid them. The restriction only rejects an explicitly set `security.idmap.isolated=false` (or empty) and fails to enforce anything when the key is omitted entirely. Because an unset `security.idmap.isolated` defaults to `false` (non-isolation), a user simply leaves the key out and obtains exactly the container state the restriction is meant to forbid. This defeats the tenant-isolation guarantee the restriction exists to provide. Containers in the project share the host uid/gid map instead of receiving unique, non-overlapping ranges, weakening the isolation boundary between co-tenant containers and the host. Version 7.3.0 patches the issue. | ||||
| CVE-2026-16577 | 2 Dokan, Wordpress | 2 Ai Powered Woocommerce Multivendor Marketplace Solution:dokan: Ai Powered Woocommerce Multivendor Marketplace Solution, Wordpress | 2026-08-21 | 2.7 Low |
| The Dokan: AI Powered WooCommerce Multivendor Marketplace Solution WordPress plugin before 5.0.14 does not validate a client-supplied payment amount against the vendor's actual outstanding balance when recording a reverse-withdrawal payment, allowing a vendor to credit their reverse-withdrawal ledger with an arbitrary amount and clear their real commission debt without paying. | ||||
| CVE-2026-17559 | 2026-08-21 | 5.3 Medium | ||
| The Passster WordPress plugin before 4.3.9 does not correctly match its own public endpoint paths when deciding which REST API requests may bypass global password protection, comparing them as an unanchored substring of the request URI rather than against the resolved route, allowing an unauthenticated attacker to read the content of globally password-protected posts and pages. | ||||
| CVE-2026-59318 | 1 Spring | 1 Spring Ai | 2026-08-21 | 6.5 Medium |
| In Spring AI's tool calling support, the per-request tool list is advertised to the model as a boundary but is not fully enforced when a tool call is dispatched. Under certain conditions, a tool that was not made available to the current request could be invoked, potentially leading to privilege escalation. Affected versions: Spring AI: 2.0.0 Spring AI: 1.1.0 through 1.1.8 Spring AI: 1.0.0 through 1.0.9 | ||||
| CVE-2026-76370 | 1 Splunk | 2 Soar, Splunk | 2026-08-21 | 4.3 Medium |
| In Splunk SOAR versions below 8.6.0, an authenticated user with restricted tenant access could use the Representational State Transfer (REST) API to view the names and identifiers of tenants that fall outside the role scope for that user. The vulnerability is possible because Splunk SOAR does not enforce role-based tenant restrictions when it returns tenant information through the REST API in deployments with multi-tenancy turned on. For more information see REST Roles and Permissions (https://help.splunk.com/en/splunk-soar/soar-cloud/rest-api-reference/role-management-endpoints/rest-roles-and-permissions) and Configure multiple tenants on your Splunk SOAR (On-premises) instance (https://help.splunk.com/en/splunk-soar/soar-on-premises/administer-soar-on-premises/7.1.0/configure-product-settings-for-your-splunk-soar-on-premises-instance/configure-multiple-tenants-on-your-splunk-soar-on-premises-instance) in the Splunk documentation. | ||||
| CVE-2026-67266 | 1 Dell | 2 Command Update, Dell Command Update (dcu) | 2026-08-21 | 5.5 Medium |
| Dell Command Update (DCU), versions prior to 5.7.1, contain an Incorrect Authorization vulnerability. A low privileged attacker with local access could potentially exploit this vulnerability, leading to Elevation of privileges. | ||||
| CVE-2026-55089 | 1 Etherpad | 1 Etherpad | 2026-08-21 | 9.9 Critical |
| Etherpad is a real-time collaborative editor. From 2.1.0 until 3.1.0, Etherpad's src/node/handler/APIHandler.ts authorizes requests to /api/2/* in the authorization_code OAuth path by using requiredClaims with the admin claim. This check requires only that the claim exists, while src/node/security/OAuth2Provider.ts issues admin: false for configured non-admin users. A non-admin user with a valid signed token can therefore invoke administrative functions including setHTML, setText, appendText, deletePad, copyPad, movePad, restoreRevision, anonymizeAuthor, listAllPads, and listAuthorsOfPad, allowing disclosure, modification, or deletion of pads across the instance. This issue is fixed in version 3.1.0. | ||||
| CVE-2026-71424 | 1 Onyx | 1 Onyx | 2026-08-21 | 9.6 Critical |
| Onyx is an open-source AI platform. Prior to 3.1.10, 3.2.14, and 4.0.0, Onyx's GET /api/mcp/servers and GET /api/mcp/servers/persona/{persona_id} endpoints expose another user's OAuth Authorization header because OnyxTokenStorage.set_tokens and OnyxTokenStorage.set_client_info in backend/onyx/server/features/mcp/api.py copy per-user tokens into a shared admin MCPConnectionConfig row and _db_mcp_server_to_api_mcp_server returns that row through auth_template.headers to any BASIC_ACCESS user. This issue is fixed in versions 3.1.10, 3.2.14, and 4.0.0. | ||||
| CVE-2026-70408 | 1 Extra Innovation | 2 Acmailer Cgi, Acmailer Db | 2026-08-21 | N/A |
| An incorrect authorization vulnerability exists in acmailer, which may allow a user to create a sub-account that has administrative privileges. | ||||
| CVE-2026-69555 | 1 Microsoft | 1 Azure Arc | 2026-08-21 | 10 Critical |
| Incorrect authorization in Azure Arc allows an unauthorized attacker to elevate privileges over a network. | ||||
| CVE-2026-70769 | 1 Oracle | 1 Hyperion Financial Reporting | 2026-08-21 | 6.5 Medium |
| Vulnerability in the Oracle Hyperion Financial Reporting product of Oracle Hyperion (component: Server). The supported version that is affected is 11.2.25.0.000. Difficult to exploit vulnerability allows unauthenticated attacker with network access via HTTP to compromise Oracle Hyperion Financial Reporting. Successful attacks of this vulnerability can result in unauthorized access to critical data or complete access to all Oracle Hyperion Financial Reporting accessible data as well as unauthorized update, insert or delete access to some of Oracle Hyperion Financial Reporting accessible data. CVSS 3.1 Base Score 6.5 (Confidentiality and Integrity impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:L/A:N). | ||||
| CVE-2026-76878 | 2026-08-21 | 6.3 Medium | ||
| In OpenStack Aodh before 22.0.1, the alarm list API bypasses project scoping when the all_projects query parameter is set to false. The API checks for the presence of the all_projects key rather than its value; a true value enforces the administrator-only policy, but a false value removes the key and skips the branch that normally restricts results to the caller's project. A non-admin user with the reader role can list alarms from all projects, exposing alarm actions containing trust webhook URLs, Heat signal endpoints, project IDs, and user IDs. The parameter can also be combined with a foreign project_id to target a specific project's alarms. A related concern is that OpenStack Watcher does not apply authorization to its webhook trigger endpoint. Any authenticated user who learns an audit's webhook URL, for example from this leaked Aodh alarm metadata, can start an EVENT audit and its associated action plan regardless of their own project or role. The webhook endpoint has lacked policy enforcement since its introduction in the Ussuri release (Watcher 4.0.0). | ||||
| CVE-2026-47866 | 2 Broadcom, Vmware | 2 Vmware Avi Load Balancer, Vmware Avi Load Balancer | 2026-08-20 | 8.3 High |
| VMware Avi Load Balancer contains an authorization bypass vulnerability. A malicious actor on the network can access a limited subset of the Avi Control Plane without proper authorization. Affected versions: 32.1.1 (fixed in 32.1.2) 31.1.1 through 31.2.2 (fixed in 31.2.2-2p3) 30.1.1 through 30.2.6 (fixed in 30.2.7) 22.1.1 through 22.1.7 (fixed in 30.2.7) | ||||
| CVE-2026-54136 | 1 Windmill-labs | 1 Windmill | 2026-08-20 | N/A |
| Windmill is an open-source developer platform for internal code: APIs, background jobs, workflows and UIs. Prior to 1.715.0, a resource-scoped API token could read script contents outside its allowed path scope through GET /api/w/{workspace}/scripts/list_search. The route-level scope middleware validated the token domain and action but did not enforce the resource/path segment, and the list_search_scripts handler had no additional check_scopes call or per-row filtering before returning script path and content fields. A token such as scripts:read:f/allowed/* could therefore receive source code for unrelated paths in the same workspace, potentially disclosing internal automation logic, integration details, business logic, inline configuration, or hardcoded secrets and credentials. Exploitation required possession of a valid scoped API token for the workspace but did not require administrator privileges. This issue is fixed in version 1.715.0. | ||||