| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| Frappe ERPNext before 15.106.0 and 16.x before 16.16.0 contains an SQL injection vulnerability in multiple endpoints caused by missing input validation. Authenticated attackers can send specially crafted requests to these endpoints to manipulate database queries and extract sensitive information from the ERPNext database. |
| Frappe ERPNext before 15.110.0 and 16.x before 16.21.0 contains a missing authorization vulnerability in which certain endpoints fail to enforce proper authorization checks. Authenticated users can query these endpoints to read data beyond what their assigned role permits. |
| Frappe ERPNext before 16.14.0 contains a missing authorization vulnerability that allows authenticated users to modify master data beyond their permitted role. Attackers can send requests to certain endpoints lacking proper authorization checks to make unauthorized changes to master data records. |
| Frappe ERPNext before 15.121.0 and 16.x before 16.33.0 contains a missing authorization vulnerability in which certain endpoints fail to enforce proper authorization checks. Authenticated users can call these endpoints directly to read data beyond what their assigned role permits. |
| Frappe ERPNext before 15.120.0 and 16.x before 16.33.0 contains a missing authorization vulnerability in which certain endpoints fail to enforce proper permission checks. Authenticated low-privileged users can request these endpoints directly to read financial data beyond what their assigned role permits. |
| Frappe ERPNext before 15.121.0 and 16.x before 16.34.0 contains a missing authorization vulnerability in which certain endpoints fail to enforce proper authorization checks. Authenticated users can send requests to the affected endpoints to modify data beyond their permitted role, compromising data integrity. |
| Frappe ERPNext before 15.119.1 and 16.x before 16.32.0 contains an SQL injection vulnerability in some endpoints that lack input validation. Authenticated attackers with low privileges can send specially crafted requests to these endpoints to inject SQL and extract sensitive information from the ERPNext database. |
| In libtirpc before 1.3.3rc1, remote attackers could exhaust the file descriptors of a process that uses libtirpc because idle TCP connections are mishandled. This can, in turn, lead to an svc_run infinite loop without accepting new connections. |
| Due to a lack of user account state validation during authentication, locked user accounts can be successfully authenticated using Magic Link or Pass Key methods. This bypasses the intended security control that should prevent access to accounts that have been locked.
This vulnerability may allow unauthorized access to applications and sensitive data associated with accounts that should have been restricted via the account lock mechanism. It also undermines the effectiveness of the account lock mechanism intended to prevent further login attempts. |
| In Splunk Enterprise versions below 10.4.2, 10.2.6, 10.0.10, and 9.4.15, a user who does not hold the "admin" or "power" Splunk roles could create or edit scripted lookup definitions through raw configuration endpoints. The vulnerability is possible because raw transforms configuration write paths do not apply external lookup capability checks before saving scripted lookup settings. |
| Missing Authorization vulnerability in DEV Institute Restrict User Access – Membership Plugin with Force restrict-user-access allows Exploiting Incorrectly Configured Access Control Security Levels.This issue affects Restrict User Access – Membership Plugin with Force: from n/a through 2.8.1. |
| Nango is an open-source platform for connecting agents and products to third-party APIs. Prior to 0.70.9, on accounts with RBAC enabled through a plan with has_rbac=true, two private flow-read routes, GET /api/v1/integrations/:providerConfigKey/flows and GET /api/v1/flow/:flowName, apply webAuth but omit can({ action: 'read', resource: 'flow', scopedBy: envScope }). A same-team user with the development_full_access role can therefore request env=prod and read production integration flow metadata or named flow configuration despite being denied by guarded production routes. Both controllers use res.locals.environment from the authenticated account, so the issue bypasses the production role boundary but does not cross tenant boundaries. This issue is fixed in version 0.70.9 and managed-1.5.11-0.70.8-aae30d044d7e229807d51a3957c212f3fb689e1a |
| In elfutils 0.183, an infinite loop was found in the function handle_symtab in readelf.c .Which allows attackers to cause a denial of service (infinite loop) via crafted file. |
| libcurl-using applications can ask for a specific client certificate to be used in a transfer. This is done with the `CURLOPT_SSLCERT` option (`--cert` with the command line tool).When libcurl is built to use the macOS native TLS library Secure Transport, an application can ask for the client certificate by name or with a file name - using the same option. If the name exists as a file, it will be used instead of by name.If the appliction runs with a current working directory that is writable by other users (like `/tmp`), a malicious user can create a file name with the same name as the app wants to use by name, and thereby trick the application to use the file based cert instead of the one referred to by name making libcurl send the wrong client certificate in the TLS connection handshake. |
| In Splunk Enterprise versions below 10.4.3, a user that holds a role with the list_spl2_modules capability could use SQL injection in SPL2 module filtering to access all relevant data available through the affected Representational State Transfer (REST) API, including private SPL2 module definitions belonging to other users. The vulnerability is possible because Splunk Enterprise and Splunk Cloud Platform do not parameterize user-supplied values before using them in database queries for SPL2 module filtering. 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.
Splunk Enterprise versions 10.2.x, 10.0.x, and 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 who does not hold the "admin" or "power" Splunk roles could cause Splunk Secure Gateway to sign attacker-controlled payloads. The vulnerability is possible because Splunk Secure Gateway does not verify that the user is authorized to request a signature. Splunk Secure Gateway versions below 3.10.11, 3.9.25, and 3.8.72 are also affected. 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. |
| An Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection') vulnerability [CWE-89] vulnerability in Fortinet FortiAnalyzer 7.6.0 through 7.6.4, FortiAnalyzer 7.4.0 through 7.4.7, FortiAnalyzer 7.2 all versions, FortiAnalyzer Cloud 7.6.2 through 7.6.4, FortiAnalyzer Cloud 7.4.1 through 7.4.7, FortiAnalyzer Cloud 7.2.1 through 7.2.11, FortiManager 7.6.0 through 7.6.4, FortiManager 7.4.0 through 7.4.6, FortiManager 7.2 all versions, FortiManager Cloud 7.6.2 through 7.6.4 may allow a low privileged user to execute arbitrary commands via crafted requests. |
| A missing authorization vulnerability in Fortinet FortiSIEM 7.5.0 may allow attacker to execute unauthorized code or commands via Specially crafted HTTP requests |
| An improper neutralization of special elements used in an SQL Command ("SQL Injection") vulnerability [CWE-89] vulnerability in Fortinet FortiMail 7.6.0 through 7.6.3, FortiMail 7.4.0 through 7.4.5, FortiMail 7.2.0 through 7.2.8 allows an authenticated attacker to execute unauthorized code or commands via specifically crafted HTTP or HTTPS requests. |
| When curl is instructed to download content using the metalink feature, thecontents is verified against a hash provided in the metalink XML file.The metalink XML file points out to the client how to get the same contentfrom a set of different URLs, potentially hosted by different servers and theclient can then download the file from one or several of them. In a serial orparallel manner.If one of the servers hosting the contents has been breached and the contentsof the specific file on that server is replaced with a modified payload, curlshould detect this when the hash of the file mismatches after a completeddownload. It should remove the contents and instead try getting the contentsfrom another URL. This is not done, and instead such a hash mismatch is onlymentioned in text and the potentially malicious content is kept in the file ondisk. |
