| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| Incorrect authorization in WebXR in Google Chrome prior to 152.0.7977.65 allowed a remote attacker leveraging social engineering to obtain cross-origin data via a crafted HTML page. (Chromium security severity: Medium) |
| 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. |
| 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. |
| 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. |
| In OpenStack Keystone before 29.0.3, tokens obtained via OAuth1 access token, application credential, or trust-scoped authentication could create new long-lived credentials or authorize new delegations that persist independently of, and outlive, the credential used to obtain them. The delegation restrictions that block these operations did not consistently apply to all delegated token types, allowing an OAuth1-scoped token, for example, to create application credentials or authorize OAuth1 request tokens despite those operations being restricted for other delegated token types. All Keystone deployments that permit delegated authentication through OAuth1 access tokens, application credentials, or trusts are affected. |
| In OpenStack Keystone before 29.0.3, tokens obtained via delegated authentication mechanisms (OAuth1 access tokens, application credentials, trusts) could be submitted to the token-method authentication path for reauthentication to escape their intended project scope. When an application credential token was presented with no explicit scope, Keystone would issue a new token scoped to the credential owner's default project rather than the project for which the credential was issued, bypassing the intended project boundary. All Keystone deployments that permit delegated authentication through OAuth1 access tokens, application credentials, or trusts are affected. |
| IBM OPENBMC FW1110.00 through FW1110.20, and FW1060.00 through FW1060.71 allows ReadOnly users to escalate privileges and give themselves administrator privileges. |
| Incorrect authorization in frozen BI aggregations in Checkmk <2.5.0p2, <2.4.0p29, <2.3.0p47, and all 2.2.0 versions allows an authenticated user with restricted host and service visibility to learn the names and the existence of hosts and services they are not authorized to see. |
| Kimai before 2.56.0 does not enforce team-membership checks in TimesheetVoter::voteOnAttribute(), which maps permissions only to own_timesheet or other_timesheet. As a result, any authenticated user with ROLE_TEAMLEAD (or a role holding edit_other_timesheet/delete_other_timesheet) can read, modify, and permanently delete timesheets belonging to any user system-wide via the API, regardless of team membership. Timesheet IDs are sequential integers and trivially enumerable. ROLE_USER accounts are correctly restricted. (Note: the maintainers characterize this behavior as matching the documented permission model.) |
| The Grav API plugin (getgrav/grav-plugin-api) before 1.0.18 does not apply the API-key scope cap in the injectSecurityTab() function of BlueprintController when deciding whether a page's security/permissions blueprint section is editable. Because the function performs raw isSuperAdmin()/hasPermission() checks without a request parameter, it cannot enforce scopeAllows(). A caller holding a scoped API key may therefore see (and potentially edit) page permission fields beyond the scope granted to the key. The end-to-end write-time impact was not fully confirmed by the reporter. |
| Incorrect authorization in FileSystem in Google Chrome prior to 152.0.7977.65 allowed a remote attacker leveraging social engineering to bypass system access restrictions via a crafted HTML page. (Chromium security severity: Medium) |
| Incorrect authorization in Network in Google Chrome prior to 152.0.7977.65 allowed a remote attacker who had compromised the renderer process to bypass site isolation via a crafted HTML page. (Chromium security severity: Medium) |
| A flaw was found in OpenStack Keystone where delegation boundary enforcement is incomplete across trust, application credential, and OAuth1 authorization endpoints. Tokens obtained via delegated authentication methods, such as OAuth1 access tokens or custom Keystone authentication plugins, can perform operations beyond their intended scope because endpoint guards only recognized specific delegation types rather than using a comprehensive allowlist. This allows creating trusts that delegate roles beyond the token's authorized scope, creating persistent application credentials, and authorizing new OAuth1 delegations. These derived credentials persist independently and survive revocation of the original credential, enabling an attacker with a compromised narrow-scope credential to escalate to the user's full privileges and maintain persistent access. |
| Incorrect authorization in Downloads in Google Chrome prior to 152.0.7977.65 allowed a remote attacker leveraging social engineering to bypass system access restrictions via a crafted HTML page. (Chromium security severity: Medium) |
| IBM Power Systems Firmware FW1120.00, FW1110.00 through FW1110.30, FW1060.00 through FW1060.80, FW950.00 through FW950.H2, OP940.00 through OP940.a1 (Power9), and OP940.00 - OP940.81 (Power HMC) is affected by a vulnerability in the interface between the BMC/FSP and the host system. An attacker with service account or root access to the BMC/FSP can write arbitrary data to hardware control registers, allowing full control over the host system and all hosted partitions, resulting in a confidentiality, integrity, and availability impact. |
| Incorrect Authorization vulnerability in the OAuth token endpoint in hexpm hexpm allows an API key holding the repositories permission to read another organization's private packages.
When an API key is exchanged for a token through the OAuth client_credentials grant, validate_scopes_against_key/2 in lib/hexpm_web/controllers/api/oauth_controller.ex admits a requested scope whenever the key carries the repositories permission and the scope string begins with repository:. The organization name is never resolved against the principal, and expand_repositories_scope/3 only rewrites the literal repositories scope, so an explicit repository:<name> passes through untouched. Both CDN edges authorize repository access from the token claim without querying the database, so the minted token is read access to that organization's private packages until it expires.
This issue affects hex.pm: from 2025-10-18 before 2026-08-24. |
| A weakness has been identified in liketrek TREK up to 3.0.22. This impacts the function validateShareTokenForAsset of the component Journey Photo Proxy. Executing a manipulation can lead to incorrect authorization. The attack can be launched remotely. This attack is characterized by high complexity. The exploitability is said to be difficult. Upgrading to version 3.1.0 will fix this issue. You should upgrade the affected component. |
| A remote code execution security issue exists within Studio 5000 Logix Designer® due to incorrect authorization on a configuration file. This can allow any authenticated user to modify the paths of external tools configured within the application. If exploited, an attacker could alter the configuration to point to a malicious executable, resulting in arbitrary code execution when any user interacts with the external tools functionality. |
| 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) |
| Spring Framework version 5.0.5 when used in combination with any versions of Spring Security contains an authorization bypass when using method security. An unauthorized malicious user can gain unauthorized access to methods that should be restricted. |
