Base de CVEs

In Splunk Enterprise versions below 10.4.2 and 10.2.6, a user who does not hold the "admin" or "power" Splunk roles could delete all Search Processing Language 2 (SPL2) modules across all apps and users on the instance through the SPL2 module management Representational State Transfer (REST) API. This could delete exported datasets and functions, affect system integrity, and cause partial service disruption. The vulnerability does not affect Splunk Enterprise versions below 10.2. The vulnerability is possible because the SPL2 module management REST API does not sufficiently authorize and validate module deletion requests. For more information see Manage SPL2 modules (https://help.splunk.com/en/splunk-enterprise/search/spl2-search-manual/multiple-searches-in-an-spl2-module/manage-spl2-modules) and Module permissions (https://help.splunk.com/en/splunk-enterprise/search/spl2-search-manual/modules-statements-and-views/module-permissions) 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 "user" Splunk role could craft a Dashboard Studio dashboard that runs attacker-controlled Search Processing Language (SPL) for another authenticated user. The attacker-controlled SPL could access all relevant data and affect system integrity and availability. The vulnerability is possible because Dashboard Studio does not consistently enforce the expected app-visibility authorization boundary before dashboard search query options reach search dispatch. 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 "user" Splunk role should not be able to exploit the vulnerability at will. For more information see Create search-based visualizations with ds.search (https://help.splunk.com/en/splunk-enterprise/create-dashboards-and-reports/dashboard-studio/10.4/use-data-sources/create-search-based-visualizations-with-ds.search) in the Splunk documentation.

In Splunk Enterprise versions below 10.4.2, 10.2.6, 10.0.9, and 9.4.14, a low-privileged user that does not hold the fsh_manage capability could perform Remote Code Execution through Federated Search bundle selection. This could allow for access to all relevant data and affect system integrity and availability. The vulnerability is possible because the Federated Search dispatch flow accepts caller-controlled bundle selection without enforcing the capability that manages federated providers and indexes. For more information see Security models for Federated Search for Splunk (https://help.splunk.com/en/splunk-enterprise/search/federated-search/10.4/run-federated-searches-across-other-splunk-deployments/service-accounts-and-security-for-federated-search-for-splunk/security-models-for-federated-search-for-splunk) 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 Splunk Enterprise versions below 10.4.1, 10.2.6, 10.0.8, and 9.4.13, a user who does not hold the "admin" or "power" Splunk roles could trick another user into running arbitrary Search Processing Language (SPL) commands through the Data Model Editor using the permissions of the affected user. The commands could access all relevant data available to the affected user and affect system integrity. The vulnerability is possible because Splunk Web does not apply SPL safeguards for risky commands when the Data Model Editor runs the base search for auto-extracted fields. The vulnerability requires the attacker to phish the affected user by tricking them into initiating a request within their browser. The user who does not hold the "admin" or "power" Splunk roles 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.4/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, and 10.0.9, a user who does not hold the "admin" or "power" Splunk roles could cause the Splunk App for Splunk Observability Cloud to forward requests to Splunk Observability Cloud, including the Splunk Observability Cloud access token stored for the app. With this access, the user could view all relevant data available to that token and make limited changes to Splunk Observability Cloud content. The vulnerability does not affect Splunk Enterprise 9.4 and 9.3 versions. The vulnerability is possible because the app's Representational State Transfer (REST) API endpoint handlers do not enforce the read_o11y_content capability before forwarding requests with the stored access token. For more information see 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.

Termix is a web-based server management platform with SSH terminal, tunneling, and file editing capabilities. Prior to 2.3.2, the POST /database/export endpoint creates a user export that includes the global settings table even though the rest of the export is user-scoped. The settings table contains reset_code_ and temp_reset_token_ password-reset artifacts, allowing a low-privileged authenticated user to recover another local account's reset code and complete the normal password-reset flow. Successful exploitation results in local-user account takeover and administrative compromise when the victim is an administrator. This issue is fixed in version 2.3.2.

IBM Portieris 0.5.0 through 0.14.2 could allow a remote authenticated attacker to bypass image policy enforcement due to improper authorization of pod owner references.

Snipe-IT is an IT asset/license management system. Prior to 8.6.0, an authenticated user with users.create permission can submit the admin permission while creating a user because store() in app/Http/Controllers/Users/UsersController.php strips superuser permission but does not strip admin permission. The created account can obtain administrative privileges. This issue is fixed in version 8.6.0.

IBM Power Systems Firmware FW1120.00, FW1110.00 through FW1110.30, and FW1060.00 through FW1060.80 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 execute arbitrary code on the host system, giving full control over the host system and all hosted partitions, resulting in a confidentiality, integrity, and availability impact.

Grav API Plugin is a RESTful API for Grav CMS that provides full headless access to your site's content. Prior to 1.0.8, the Grav API plugin intercepts the apiKeyGenerate and apiKeyRevoke admin tasks in user/plugins/api/api.php and authorizes the caller with only admin.login. A basic panel user can select another account from the route, create a persistent ApiKeyManager credential bound to that target, and inherit the target's API permissions, including api.super or administrative write access when present. This issue is fixed in version 1.0.8.

Grav API Plugin is a RESTful API for Grav CMS that provides full headless access to your site's content. Prior to 1.0.6, the Grav API plugin ApiKeyManager::generateKey() stores a declared scopes array, but ApiKeyAuthenticator::authenticate() does not read keyData[scopes] and returns the owning user's complete identity. AbstractApiController::requirePermission() consequently evaluates the full user ACL, so a key issued for a read-only scope can perform every write, delete, and administrative operation available to the owner. This issue is fixed in version 1.0.6.

Dell Command Update (DCU), versions prior to 5.7.1, contain a Missing Authorization vulnerability. A low privileged attacker with local access could potentially exploit this vulnerability, leading to Elevation of Privileges.

Dell Command Update (DCU), versions prior to 5.7.1, contain a Missing Authorization vulnerability. A low privileged attacker with local access could potentially exploit this vulnerability, leading to Unauthorized access.

MyBooks is an ebook management web server also known as Talebook. In 3.41.2 and earlier, the AdminSettings.post handler for POST /api/admin/settings in webserver/handlers/admin.py applies the auth decorator but does not check the self.admin_user property, unlike the corresponding GET handler. Any authenticated regular user can therefore overwrite server configuration values including SMTP credentials, OAuth client secrets, storage paths, security feature flags, and autoreload settings. The process_auth_header function in webserver/handlers/base.py also fails to verify the matched account's active flag, allowing a registered but unactivated account to authenticate and reach the vulnerable handler. Exploitation can disclose secrets through configuration access paths, sabotage application behavior, force service restarts, and supply the settings needed for related code-injection attacks. This issue is fixed in version 3.42.0.

ArcadeDB (com.arcadedb) versions 26.7.3 and earlier fail to enforce the UPDATE_SCHEMA permission check when a DEFINE FUNCTION statement targets an already-existing function library. A user with only database access can add or overwrite SQL or Cypher functions in an existing library and persist the change, enabling tampering with admin-defined function logic. The issue is fixed in 26.8.1. (JavaScript functions still trigger the UPDATE_SECURITY check and are not affected.)