CVE Vulnerability Catalog

Vulnerability in AsyncHttpClient (AHC) library before versions 3.0.13 and 2.16.1 allows cross-host request replay that updates the current request but leaves the target request and proxy context pointing to the original origin. This can send the original host's path, Host header, Authorization credentials, or plaintext request to the replay destination.

The AsyncHttpClient (AHC) library allows Java applications to easily execute HTTP requests and asynchronously process HTTP responses. Prior to 3.0.13 and 2.16.1, the HTTP/1.1 connection-pool key excludes the authenticated principal for connection-oriented NTLM and Negotiate authentication. A pooled socket authenticated for one request can be reused by a request carrying another principal, and the server executes that later request as the first identity. Basic and Digest are not affected because they authenticate each request. This issue is fixed in versions 3.0.13 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.

The AsyncHttpClient (AHC) library allows Java applications to easily execute HTTP requests and asynchronously process HTTP responses. In 3.0.12, a peer offering only Digest qop=auth-int causes mutual-authentication verification to be skipped. AuthenticatorUtils.computeExpectedRspAuth returns no expected value for auth-int, and Interceptors treats that result as unverifiable but nonfatal, so a response with an invalid rspauth value is accepted. A peer that does not know the shared secret can therefore be accepted as the authenticated server. This issue is fixed in version 3.0.13.

The AsyncHttpClient (AHC) library allows Java applications to easily execute HTTP requests and asynchronously process HTTP responses. Prior to 3.0.12 on 3.x and 2.16.1 on 2.x, the client infers that an HTTP proxy tunnel exists from the last request method rather than the CONNECT result. After a proxy rejects CONNECT, redirect or authentication handlers can write an origin request and its Authorization credentials onto the still-plaintext proxy connection. Basic credentials can be recovered directly, while NTLM responses may be cracked or relayed. This issue is fixed in versions 3.0.12 and 2.16.1.

The AsyncHttpClient (AHC) library allows Java applications to easily execute HTTP requests and asynchronously process HTTP responses. Prior to 3.0.13 and 2.16.1, Realm.Builder treats a Digest challenge that yields no usable nonce as a Basic challenge. A malicious origin or proxy can label a challenge Digest while omitting or emptying the nonce, causing the client to resend the username and password using reversible Basic authentication. Both origin and proxy challenge parsers are affected. This issue is fixed in versions 3.0.13 and 2.16.1.

The AsyncHttpClient (AHC) library versions 2.0.0 through 3.0.14 incorrectly partition the connection pool for Kerberos, SPNEGO, NTLM, and authenticated proxy connections. Missing identity-defining fields can allow reuse of a socket authenticated as a different identity, leading to a request being executed under the first identity and exposing its data or authority to another caller. This issue is fixed in version 3.0.14.

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.

Vault and Vault Enterprise did not consistently verify that stored plugin catalog entries reference binaries within the configured plugin directory. When Vault uses Shamir seals and has an external plugin directory configured, a privileged operator able to restore an Integrated Storage (Raft) snapshot may be able to execute arbitrary code on the Vault host. 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.

As part of Cisco's internal security review, a software hardening release was issued that addresses multiple internally discovered vulnerabilities. The vulnerabilities tracked as CVE-2026-76285 relate to improper adherence to coding standards and are grouped under CWE-710.

As part of Cisco's internal security review, a software hardening release was issued that addresses multiple internally discovered vulnerabilities. The vulnerabilities tracked as CVE-2026-76284 relate to improper neutralization and are grouped under CWE-707.

As part of Cisco's ongoing commitment to proactive security and product quality, Cisco has conducted a comprehensive internal security review. This review resulted in a software hardening release that addresses multiple internally discovered vulnerabilities. The vulnerabilities tracked by CVE-2026-76283 are related to protection mechanism failure and are grouped under the Common Weakness Enumeration (CWE) CWE-693.

As part of Cisco's ongoing commitment to proactive security and product quality, Cisco has conducted a comprehensive internal security review. This review resulted in a software hardening release that addresses multiple internally discovered vulnerabilities. The vulnerabilities tracked by CVE-2026-76282 are related to improper control of a resource through its lifetime and are grouped under the Common Weakness Enumeration (CWE) CWE-664.

Cisco conducted a comprehensive internal security review that resulted in a software hardening release. The vulnerabilities tracked by CVE-2026-76281 relate to improper access control issues classified under CWE-284.

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.