CVE Vulnerability Catalog

WSO2 Identity Server fails to enforce a default expiry time for SMS One-Time Passwords (OTPs) used in MFA. Unused OTPs remain valid indefinitely, allowing attackers to conduct brute force attacks by repeatedly guessing the code. A successful attack can lead to MFA bypass and unauthorized account takeover.

The Aurora Heatmap plugin for WordPress up to version 1.7.2 is vulnerable to Stored Cross-Site Scripting via the 'url' parameter due to insufficient input sanitization and output escaping. Unauthenticated attackers can inject scripts that execute when an admin user clicks the injected heatmap link.

The LatePoint plugin for WordPress up to version 5.6.9 is vulnerable to Insecure Direct Object Reference. The process_step_customer() function uses only is_user_logged_in() as a gate before merging POSTed customer data into an existing LatePoint customer, without ownership checks. This allows authenticated attackers with Subscriber-level access or above to modify personal information of arbitrary LatePoint customers, and when contact_merge is 'phone', overwrite the victim's email and take over the account via password reset.

The PostgreSQL JDBC Driver (pgjdbc) versions 42.7.4 through 42.7.13 pads a value shorter than its declared length with bytes left in its send buffer instead of zeros, and the server stores those bytes as part of the value. These bytes are messages the driver sent earlier on the same connection: SQL text and parameter values of recent statements, which on a pooled connection can come from other requests. Each padded value can carry up to 8192 bytes of this traffic, or 16320 bytes with GSS encryption. The padding occurs when an application declares a length larger than the data it supplies through certain APIs. An attacker who can make the application store such a value and read it back can collect earlier traffic. Applications whose declared lengths always match their data are not affected. Versions 42.7.3 and earlier pad with zeros.

In pgjdbc (PostgreSQL JDBC Driver) versions 42.7.11 through 42.7.13, the requireAuth property does not enforce restrictions when it excludes all known authentication methods (e.g., requireAuth=!password,!md5,!gss,!sspi,!scram-sha-256,!none). The driver then accepts any method the server asks for, including cleartext password authentication. An attacker in a man-in-the-middle position can capture the database password. Version 42.7.14 fixes the issue.

In the AsyncHttpClient (AHC) library prior to versions 3.0.12 and 2.16.1, a proxied ws request is carried through CONNECT, but NettyRequestFactory.newNettyRequest and requestUri decide whether to attach proxy authentication and an absolute-form target only from whether the URI is secure. Because ws is not marked secure, the tunneled WebSocket upgrade sent to the origin includes the proxy's Proxy-Authorization value. Basic credentials are directly recoverable and Digest responses can be replayed or cracked offline. This issue is fixed in versions 3.0.12 and 2.16.1.

In the AsyncHttpClient (AHC) library prior to versions 3.0.13 and 2.16.1, ThreadSafeCookieStore validates Domain attributes with domain matching but does not reject public suffixes. A host beneath a suffix such as co.uk can set a cookie for that suffix, after which the shared cookie store sends it to unrelated hosts under the suffix. This can inject or overwrite session-relevant cookie values across origins. This issue is fixed in versions 3.0.13 and 2.16.1.

Vault's ACL policy cache allowed namespace traversal when policy names contained path traversal constructs. This may allow a token assigned specially crafted policy names to use the capabilities of policies defined in other namespaces, including the root namespace. This vulnerability is fixed in Vault Enterprise 2.1.2, 1.21.12, 1.20.17, and 1.19.23. Vault Community Edition does not support namespaces and is not affected.

Vault's PKI secrets engine ACME server did not restrict certificate identities that ACME challenges do not validate when issuing certificates under the default directory policy. This may allow an ACME client to obtain a certificate containing unverified identity claims, potentially enabling impersonation toward systems that trust certificates issued by the affected Vault PKI mount. This vulnerability is fixed in Vault Community Edition 2.1.2, and Vault Enterprise 2.1.2, 1.21.12, 1.20.17, and 1.19.23.

In Splunk MCP Server versions below 1.2.1, the server could send the Splunk platform authentication token of a user who runs a custom API tool to the URL configured for that tool. If another user controls that URL, they could capture the token and use it to access data and perform actions as the user who ran the tool. Successful exploitation requires a user with a role containing the mcp_tool_execute capability to run a custom API tool configured by another user.

In Splunk Enterprise versions below 10.4.3, 10.2.7, 10.0.10, and 9.4.15, and Splunk Secure Gateway versions below 3.10.11, 3.9.25, and 3.8.72, an authenticated user without admin or sc_admin roles could modify alert and mobile-device recipient data in App Key Value Store collections used by alert and subscription workflows. The vulnerability is due to unrestricted write access to these collections.

In Splunk Enterprise versions below 10.4.3, 10.2.7, 10.0.10, and 9.4.15, a user with run_collect capability could use the collect SPL command to write events to internal indexes outside the role's configured index access. The vulnerability is due to lack of whitespace normalization in index names before applying access restrictions.

In Splunk Enterprise versions below 10.4.3, 10.2.7, and 10.0.10, a user with edit_spl2_module_permissions capability could use the REST API to access permission grants for SPL2 modules they are not allowed to view. The vulnerability is due to missing verification of user's read access to the app before returning module permissions.

In Splunk Enterprise versions below 10.4.3, 10.2.7, 10.0.10, and 9.4.15, a user with edit_user capability could create a native Splunk username ending with a period. Username validation does not reject a trailing period, causing distinct usernames to share per-user configuration data and user-management operations to affect the wrong account or fail.

In Splunk Enterprise versions below 10.4.3, 10.2.7, and 10.0.10, a low-privileged user without admin or power roles could retrieve original source code for the Discover Splunk Observability Cloud app through Splunk Web. The vulnerability is due to embedded source maps in production JavaScript bundles.

In Splunk Enterprise versions below 10.4.3, 10.2.7, 10.0.10, and 9.4.15, a user without admin or power roles could access search query text and job metadata for jobs belonging to other users via a REST API. The vulnerability is due to incomplete per-user authorization enforcement in search job listings.

In Splunk Enterprise versions below 10.4.3, 10.2.7, and 10.0.10, a user with read_o11y_content capability could redirect an outbound request from Splunk App for Splunk Observability Cloud through the REST API to an attacker-controlled host and disclose the configured Observability Cloud API token. The vulnerability is due to incomplete validation of the outbound request destination.

In Splunk Enterprise versions below 10.4.3, 10.2.7, 10.0.10, and 9.4.15, a user with run_collect capability could use the collect SPL command to add attacker-controlled content to system-level messages. The vulnerability is due to lack of index name validation before processing the value.

In Splunk Enterprise versions below 10.4.3, 10.2.7, 10.0.10, and 9.4.15, and Splunk Secure Gateway versions below 3.10.11, 3.9.25, and 3.8.72, a user without admin or power roles could cause Splunk Secure Gateway to sign attacker-controlled payloads. The vulnerability is due to lack of authorization verification for signature requests.

In Splunk Enterprise versions below 10.4.3, 10.2.7, and 10.0.10, a low-privileged user without admin or power roles could cause a denial of service against a REST API endpoint in the Discover Splunk Observability Cloud app. The vulnerability is due to an inefficient regular expression used for input validation.