Dell OpenManage Enterprise, versions prior to 4.7.0, contains an Improper Privilege Management vulnerability. A high privileged attacker with remote access could potentially exploit this vulnerability, leading to Elevation of privileges.

In Splunk Enterprise versions below 10.4.2, 10.2.6, 10.0.9, and 9.4.14, an unauthenticated user who has an embedded report token could download the associated search job dispatch archive, recover session material, and use it to access all relevant data available to the report owner and affect system integrity, including by performing administrative actions when the owner holds the "admin" Splunk role. The vulnerability is possible because embedded report access does not block Representational State Transfer (REST) API dispatch archive download requests. For more information see Additional configuration for embedded reports (https://help.splunk.com/en/splunk-enterprise/create-dashboards-and-reports/reporting-manual/9.1/report-management/additional-configuration-for-embedded-reports) and About configuring role-based user access (https://help.splunk.com/en/splunk-enterprise/administer/manage-users-and-security/10.4/manage-splunk-platform-users-and-roles/about-configuring-role-based-user-access) 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 a Splunk role that contains the high-privilege list_search_head_clustering capability could send a read request to Search Head Cluster member control endpoints and change cluster state, which could allow for a denial of service. The vulnerability is possible because the Search Head Cluster member control endpoints do not require a state-changing Hypertext Transfer Protocol (HTTP) request type before they apply read-only authorization.

In Splunk Enterprise versions below 10.4.2, 10.2.6, 10.0.9, and 9.4.14, and Splunk Secure Gateway versions below 3.10.9, 3.9.23, and 3.8.70, an unauthenticated user could trick a user who holds the "admin" or "sc_admin" Splunk roles into opening a crafted Splunk Web Uniform Resource Locator (URL). The resulting dashboard searches could run arbitrary Search Processing Language (SPL) commands with the permissions available to the affected user. The commands could expose all relevant data available to that user and affect search results or lookup data. The vulnerability is possible because Splunk Secure Gateway dashboards do not correctly neutralize caller-supplied values before using them in dashboard searches. The vulnerability requires the attacker to phish the affected user by tricking them into initiating a request within their browser. The unauthenticated user should not be able to exploit the vulnerability at will.

In versions below 2.5.3 of the Azure AD Graph app for Splunk SOAR, a user who holds a role with permission to run actions could expose a sensitive password by invoking the reset password action, because the action's temp_password parameter is not masked and is shown in cleartext in the user interface. The information disclosure is possible because the app does not mark the affected action parameter as a password. For more information see Run an action in Splunk SOAR (https://help.splunk.com/en/splunk-soar/soar-on-premises/use-splunk-soar-on-premises/8.6.0/use-the-command-line-interface-to-perform-tasks-in-splunk-soar-on-premises/run-an-action-in-splunk-soar-on-premises).

Orval generates type-safe JavaScript clients in TypeScript from OpenAPI v3 and Swagger v2 specifications. Prior to 8.21.0, a single quote in a schema property name is emitted into single-quoted object keys in generated MSW mock factories without safe encoding. This permits attacker-controlled JavaScript to be evaluated when the generated mock factory is called by tests or an MSW handler, resulting in code execution in the developer, CI, test, or application environment. The affected code is packages/core/src/getters/keys.ts function getKey and MSW mock generation. This issue is fixed in version 8.21.0.

stigmem-node 0.9.0a1 allows plugin signature enforcement to be disabled via a single configuration flag without a second explicit acknowledgment. If that setting is carried into an environment where plugin directories are writable by less-trusted users, unsigned (potentially malicious) plugin code could be loaded and executed, resulting in arbitrary code execution. Fixed in 0.9.0a2, which requires a second explicit acknowledgment to disable signature enforcement.

The Speed Optimizer – The All-In-One Performance-Boosting Plugin plugin for WordPress is vulnerable to Stored Cross-Site Scripting via Image Tag Attributes in all versions up to, and including, 7.8.0 due to insufficient input sanitization and output escaping. This makes it possible for authenticated attackers, with contributor-level access and above, to inject arbitrary web scripts in pages that will execute whenever a user accesses an injected page. This is only exploitable when the site administrator has enabled the Lazy Load Media option in the plugin settings.

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, and OP940.00 - OP940.81 is affected by a vulnerability in the service processor mailbox interface. An attacker with authenticated service-level access to the BMC/FSP can exploit this vulnerability, allowing arbitrary code to be executed in the host firmware runtime, giving full control over the managed system, resulting in a confidentiality, integrity, and availability impact to the managed system.

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.