| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| No description is available for this CVE. |
| A flaw was found in curl that can allow unauthorized access through improper session reuse. When an unencrypted File Transfer Protocol (FTP) transfer reuses a pooled connection previously authenticated with a client certificate and upgraded using Transport Layer Security (TLS), curl fails to perform a new handshake or authentication. As a result, the subsequent transfer operates under the prior session's identity, allowing it to perform operations on the remote server with unintended authorization. |
| A flaw was found in curl. When an application attempts to disable Amazon Web Services Signature Version 4 (AWS SigV4) authentication on a reused connection handle, curl fails to clear the setting as expected. If the application subsequently directs a request to an untrusted or attacker-controlled server using the same handle, curl unintentionally transmits the signed authorization header. This flaw allows a remote attacker to obtain access key identifiers and request signatures, leading to information disclosure. |
| A flaw was found in curl. When connection pooling is used with forced local interface binding options, curl fails to include the source interface configuration in its connection reuse cache. An attacker able to initiate network requests in an application using pooled connections can cause subsequent transfers to inadvertently reuse an existing connection. This behavior causes outbound network traffic to be transmitted through the wrong source address, potentially routing requests through an unintended network interface. |
| A flaw was found in curl. When curl is built with the GnuTLS library, a blocked transmission during communication with a malicious WebSocket server can trigger an out-of-bounds memory read. A malicious server can exploit this flaw to expose sensitive data from neighboring memory buffers or crash the client, leading to information disclosure or a Denial of Service (DoS). |
| A flaw was found in the curl command-line tool. When configured to follow redirects to Secure File Transfer Protocol (SFTP) or Secure Copy Protocol (SCP) destinations, curl fails to apply user-specified Secure Shell (SSH) host verification settings. A malicious server can exploit this flaw by redirecting requests to an untrusted server, causing the connection to proceed without validating the remote host's identity. This failure can enable an attacker to intercept communications, leading to sensitive information disclosure. |
| In Splunk Enterprise versions below 10.4.3, 10.2.7, and 10.0.10, a user that holds a role with the edit_spl2_module_permissions capability could use the affected Representational State Transfer (REST) API to access permission grants for SPL2 modules that the user does not have permission to view. The vulnerability is possible because Splunk Enterprise does not verify that the user can read the requested app before the affected REST API returns SPL2 module permission grants. For more information see Module permissions (https://help.splunk.com/en/splunk-enterprise/search/spl2-search-manual/modules-statements-and-views/module-permissions) and Manage SPL2 modules (https://help.splunk.com/en/splunk-enterprise/search/spl2-search-manual/multiple-searches-in-an-spl2-module/manage-spl2-modules) in the Splunk documentation.
Splunk Enterprise versions 9.4.x are not affected. |
| In Splunk Enterprise versions below 10.4.3, 10.2.7, 10.0.10, and 9.4.15, a user that holds a role with the run_collect capability could use the collect Search Processing Language (SPL) command to write events to internal indexes outside the index access configured for the role. The vulnerability is possible because Splunk Enterprise does not normalize whitespace in an index name before applying configured index-access restrictions for the role. For more information see collect (https://help.splunk.com/en/splunk-enterprise/search/spl-search-reference/10.4/search-commands/collect), 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), and How indexing works (https://help.splunk.com/en/splunk-enterprise/administer/manage-indexers-and-indexer-clusters/10.4/indexing-overview/how-indexing-works) in the Splunk documentation. |
| 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 who does not hold the "admin" or "sc_admin" Splunk roles could modify Splunk Secure Gateway alert and mobile-device recipient data in App Key Value Store (KV Store) collections that later alert and subscription workflows use. The vulnerability is possible because the affected collections allow unrestricted write access instead of limiting writes to authorized Splunk Secure Gateway workflows. For more information see About the app key value store (https://help.splunk.com/en/splunk-enterprise/administer/admin-manual/10.4/administer-the-app-key-value-store/about-the-app-key-value-store), KV store endpoint descriptions (https://help.splunk.com/en/splunk-enterprise/leverage-rest-apis/rest-api-reference/10.4/kv-store-endpoints/kv-store-endpoint-descriptions), 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. |
| Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal') vulnerability in Super Forms allows Path Traversal.
This issue affects Super Forms: from n/a through 6.3.316. |
| Progress MarkLogic Server 12.x releases before 12.1.0 and 11.x releases before 11.3.7 do not sufficiently isolate user-supplied code executed through certain REST and XDBC evaluation paths from HTTP request, response, and session state. An attacker able to execute code through an affected path could perform unauthorized actions or compromise an authenticated session. |
| Photoshop Desktop is affected by an out-of-bounds write vulnerability that could result in arbitrary code execution in the context of the current user. Exploitation of this issue requires user interaction in that a victim must open a malicious file. |
| Photoshop Desktop is affected by an Incorrect Authorization vulnerability that could result in arbitrary code execution in the context of the current user. An attacker could exploit this vulnerability to execute arbitrary code. Exploitation of this issue requires user interaction in that a victim must open a malicious file. Scope is changed. |
| Photoshop Desktop is affected by a Heap-based Buffer Overflow vulnerability that could result in arbitrary code execution in the context of the current user. Exploitation of this issue requires user interaction in that a victim must open a malicious file. |
| Photoshop Desktop is affected by an out-of-bounds write vulnerability that could result in arbitrary code execution in the context of the current user. Exploitation of this issue requires user interaction in that a victim must open a malicious file. |
| Photoshop Desktop is affected by an Integer Overflow or Wraparound vulnerability that could result in arbitrary code execution in the context of the current user. Exploitation of this issue requires user interaction in that a victim must open a malicious file. |
| Photoshop Desktop is affected by a Double Free vulnerability that could result in arbitrary code execution in the context of the current user. An attacker could exploit this vulnerability to execute arbitrary code. Exploitation of this issue requires user interaction in that a victim must open a malicious file. |
| The Metasploit Framework post module post/apple_ios/gather/ios_image_gather is affected by a relative path traversal vulnerability (CWE-22). The module interpolates file names taken from a Meterpreter directory listing — data fully controlled by a hostile or tampered iOS device — directly into the local destination path passed to client.fs.file.download_file(), with no sanitization. The underlying stdapi sink (lib/rex/post/meterpreter/extensions/stdapi/fs/file.rb) writes to whatever path is supplied, so a listing entry such as ../../msfconsole.rc escapes the intended ~/.msf4/loot/<random> directory and overwrites ~/.msf4/msfconsole.rc, a resource file that every msfconsole invocation automatically executes at startup (lib/msf/ui/console/driver.rb:196). An attacker-controlled device that lures an operator into running this gather module achieves an arbitrary file write as the operator; because the written msfconsole.rc can load a second written file (a Ruby plugin whose top-level code runs on require), this converts into persistent code execution and an interactive shell as the operator (frequently root) on the pentester's workstation at the next console launch. The same traversal was previously fixed upstream in the recursive downloader (stdapi/fs/dir.rb scrubs separators); this module omitted the equivalent scrub. The fix applies the same separator scrub (or File.basename) to listing entries before building the local path. |
| The Metasploit Framework Web Service REST API (msf-ws) exposes the credential store through Msf::WebServices::CredentialServlet. Every mutating and read route in this servlet calls warden.authenticate! before processing a request, except the update_credential (PUT) and delete_credentials (DELETE) handlers for /api/v1/credentials, which omit the authentication call entirely. Because these handlers call directly into lib/msf/core/db_manager/cred.rb, which performs no authorization check of its own, any client able to reach the web service on its default 0.0.0.0:8080 listener can read, modify, or permanently delete every stored credential record — including passwords, hashes, and private keys stored for a shared team engagement — without presenting any authentication. All published versions of Metasploit Framework through 6.5.4 are affected. The issue is fixed in 6.5.5 by adding warden.authenticate! as the first statement in both handlers, matching the pattern used by every other route in the API. |
| Progress MarkLogic Server 12.x releases before 12.1.0 and 11.x releases before 11.3.7 do not consistently validate TLS certificate hostnames for certain outbound connections. A network-positioned attacker could exploit this weakness to intercept or modify communications with an affected service. |
