CVE Database

The Advanced Advertising System plugin for WordPress is vulnerable to Open Redirect in all versions up to, and including, 1.3.1. This is due to insufficient validation on the redirect url supplied via the 'redir' parameter. This makes it possible for unauthenticated attackers to redirect users to potentially malicious sites if they can successfully trick them into performing an action.

The AAWP Obfuscator plugin for WordPress is vulnerable to Stored Cross-Site Scripting via the 'data-aawp-web' parameter in all versions up to, and including, 1.0 due to insufficient input sanitization and output escaping. This makes it possible for authenticated attackers, with Author-level access and above, to inject arbitrary web scripts in pages that will execute whenever a user accesses an injected page.

A vulnerability has been identified in Mendix Runtime V10 (All versions < V10.21.0), Mendix Runtime V10.12 (All versions < V10.12.16), Mendix Runtime V10.18 (All versions < V10.18.5), Mendix Runtime V10.6 (All versions < V10.6.22), Mendix Runtime V8 (All versions < V8.18.35), Mendix Runtime V9 (All versions < V9.24.34). Affected applications allow for entity enumeration due to distinguishable responses in certain client actions. This could allow an unauthenticated remote attacker to list all valid entities and attribute names of a Mendix Runtime-based application.

A vulnerability has been identified in Siemens License Server (SLS) (All versions < V4.3). The affected application does not properly restrict permissions of the users. This could allow a lowly-privileged attacker to escalate their privileges.

A vulnerability has been identified in Siemens License Server (SLS) (All versions < V4.3). The affected application searches for executable files in the application folder without proper validation. This could allow an attacker to execute arbitrary code with administrative privileges by placing a malicious executable in the same directory.

In the Linux kernel, the following vulnerability has been resolved: devlink: fix xa_alloc_cyclic() error handling In case of returning 1 from xa_alloc_cyclic() (wrapping) ERR_PTR(1) will be returned, which will cause IS_ERR() to be false. Which can lead to dereference not allocated pointer (rel). Fix it by checking if err is lower than zero. This wasn't found in real usecase, only noticed. Credit to Pierre.

In the Linux kernel, the following vulnerability has been resolved: dpll: fix xa_alloc_cyclic() error handling In case of returning 1 from xa_alloc_cyclic() (wrapping) ERR_PTR(1) will be returned, which will cause IS_ERR() to be false. Which can lead to dereference not allocated pointer (pin). Fix it by checking if err is lower than zero. This wasn't found in real usecase, only noticed. Credit to Pierre.

In the Linux kernel, the following vulnerability has been resolved: soc: qcom: pdr: Fix the potential deadlock When some client process A call pdr_add_lookup() to add the look up for the service and does schedule locator work, later a process B got a new server packet indicating locator is up and call pdr_locator_new_server() which eventually sets pdr->locator_init_complete to true which process A sees and takes list lock and queries domain list but it will timeout due to deadlock as the response will queued to the same qmi->wq and it is ordered workqueue and process B is not able to complete new server request work due to deadlock on list lock. Fix it by removing the unnecessary list iteration as the list iteration is already being done inside locator work, so avoid it here and just call schedule_work() here. Process A Process B process_scheduled_works() pdr_add_lookup() qmi_data_ready_work() process_scheduled_works() pdr_locator_new_server() pdr->locator_init_complete=true; pdr_locator_work() mutex_lock(&pdr->list_lock); pdr_locate_service() mutex_lock(&pdr->list_lock); pdr_get_domain_list() pr_err("PDR: %s get domain list txn wait failed: %d\n", req->service_name, ret); Timeout error log due to deadlock: " PDR: tms/servreg get domain list txn wait failed: -110 PDR: service lookup for msm/adsp/sensor_pd:tms/servreg failed: -110 " Thanks to Bjorn and Johan for letting me know that this commit also fixes an audio regression when using the in-kernel pd-mapper as that makes it easier to hit this race. [1]

In the Linux kernel, the following vulnerability has been resolved: ARM: dts: bcm2711: Fix xHCI power-domain During s2idle tests on the Raspberry CM4 the VPU firmware always crashes on xHCI power-domain resume: root@raspberrypi:/sys/power# echo freeze > state [ 70.724347] xhci_suspend finished [ 70.727730] xhci_plat_suspend finished [ 70.755624] bcm2835-power bcm2835-power: Power grafx off [ 70.761127] USB: Set power to 0 [ 74.653040] USB: Failed to set power to 1 (-110) This seems to be caused because of the mixed usage of raspberrypi-power and bcm2835-power at the same time. So avoid the usage of the VPU firmware power-domain driver, which prevents the VPU crash.

In the Linux kernel, the following vulnerability has been resolved: RDMA/hns: Fix soft lockup during bt pages loop Driver runs a for-loop when allocating bt pages and mapping them with buffer pages. When a large buffer (e.g. MR over 100GB) is being allocated, it may require a considerable loop count. This will lead to soft lockup: watchdog: BUG: soft lockup - CPU#27 stuck for 22s! ... Call trace: hem_list_alloc_mid_bt+0x124/0x394 [hns_roce_hw_v2] hns_roce_hem_list_request+0xf8/0x160 [hns_roce_hw_v2] hns_roce_mtr_create+0x2e4/0x360 [hns_roce_hw_v2] alloc_mr_pbl+0xd4/0x17c [hns_roce_hw_v2] hns_roce_reg_user_mr+0xf8/0x190 [hns_roce_hw_v2] ib_uverbs_reg_mr+0x118/0x290 watchdog: BUG: soft lockup - CPU#35 stuck for 23s! ... Call trace: hns_roce_hem_list_find_mtt+0x7c/0xb0 [hns_roce_hw_v2] mtr_map_bufs+0xc4/0x204 [hns_roce_hw_v2] hns_roce_mtr_create+0x31c/0x3c4 [hns_roce_hw_v2] alloc_mr_pbl+0xb0/0x160 [hns_roce_hw_v2] hns_roce_reg_user_mr+0x108/0x1c0 [hns_roce_hw_v2] ib_uverbs_reg_mr+0x120/0x2bc Add a cond_resched() to fix soft lockup during these loops. In order not to affect the allocation performance of normal-size buffer, set the loop count of a 100GB MR as the threshold to call cond_resched().

In the Linux kernel, the following vulnerability has been resolved: regulator: dummy: force synchronous probing Sometimes I get a NULL pointer dereference at boot time in kobject_get() with the following call stack: anatop_regulator_probe() devm_regulator_register() regulator_register() regulator_resolve_supply() kobject_get() By placing some extra BUG_ON() statements I could verify that this is raised because probing of the 'dummy' regulator driver is not completed ('dummy_regulator_rdev' is still NULL). In the JTAG debugger I can see that dummy_regulator_probe() and anatop_regulator_probe() can be run by different kernel threads (kworker/u4:*). I haven't further investigated whether this can be changed or if there are other possibilities to force synchronization between these two probe routines. On the other hand I don't expect much boot time penalty by probing the 'dummy' regulator synchronously.

In the Linux kernel, the following vulnerability has been resolved: regulator: check that dummy regulator has been probed before using it Due to asynchronous driver probing there is a chance that the dummy regulator hasn't already been probed when first accessing it.

A vulnerability has been identified in SENTRON 7KT PAC1260 Data Manager (All versions). The web interface of affected devices allows to change the login password without knowing the current password. In combination with a prepared CSRF attack (CVE-2024-41795) an unauthenticated attacker could be able to set the password to an attacker-controlled value.

A vulnerability has been identified in SENTRON 7KT PAC1260 Data Manager (All versions). The web interface of affected devices is vulnerable to Cross-Site Request Forgery (CSRF) attacks. This could allow an unauthenticated attacker to change arbitrary device settings by tricking a legitimate device administrator to click on a malicious link.

SAP S4CORE OData meta-data property is vulnerable to data tampering, due to which entity set could be externally modified by an attacker causing low impact on integrity of the application. Confidentiality and availability is not impacted.

Due to insecure file permissions in SAP BusinessObjects Business Intelligence Platform, an attacker who has local access to the system could modify files potentially disrupting operations or cause service downtime hence leading to a high impact on integrity and availability. However, this vulnerability does not disclose any sensitive data.

SAP NetWeaver allows an attacker to bypass authorization checks, enabling them to view portions of ABAP code that would normally require additional validation. Once logged into the ABAP system, the attacker can run a specific transaction that exposes sensitive system code without proper authorization. This vulnerability compromises the confidentiality.

Due to a missing authorization check, an authenticated attacker could upload a file as a template for solution documentation in SAP Solution Manager 7.1. After successful exploitation, an attacker can cause limited impact on the integrity and availability of the application.

Due to incorrect memory address handling in ABAP SQL of SAP NetWeaver and ABAP Platform (Application Server ABAP), an authenticated attacker with high privileges could execute certain forms of SQL queries leading to manipulation of content in the output variable. This vulnerability has a low impact on the confidentiality, integrity and the availability of the application.

SAP ERP BW Business Content is vulnerable to OS Command Injection through certain function modules. These function modules, when executed with elevated privileges, improperly handle user input, allowing attacker to inject arbitrary OS commands. This vulnerability allows the execution of unintended commands on the underlying system, posing a significant security risk to the confidentiality, integrity and availability of the application.

The GreenPay(tm) by Green.Money plugin for WordPress is vulnerable to Sensitive Information Exposure in versions between 3.0.0 and 3.0.9 through the publicly accessible phpinfo.php script. This makes it possible for unauthenticated attackers to view potentially sensitive information contained in the exposed file.

A Missing Authorization Check vulnerability exists in the Virus Scanner Interface of SAP NetWeaver Application Server ABAP. Because of this, an attacker authenticated as a non-administrative user can initiate a transaction, allowing them to access but not modify non-sensitive data without further authorization and with no effect on availability.

Under specific conditions and prerequisites, an unauthenticated attacker could access customer coupon codes exposed in the URL parameters of the Coupon Campaign URL in SAP Commerce. This could allow the attacker to use the disclosed coupon code, hence posing a low impact on confidentiality and integrity of the application.

SAP KMC WPC allows an unauthenticated attacker to remotely retrieve usernames by a simple parameter query which could expose sensitive information causing low impact on confidentiality of the application. This has no effect on integrity and availability.

SAP Commerce Cloud (Public Cloud) does not allow to disable unencrypted HTTP (port 80) entirely, but instead allows a redirect from port 80 to 443 (HTTPS). As a result, Commerce normally communicates securely over HTTPS. However, the confidentiality and integrity of data sent on the first request before the redirect may be impacted if the client is configured to use HTTP and sends confidential data on the first request before the redirect.

SAP NetWeaver Application Server ABAP does not sufficiently encode user-controlled inputs, leading to Stored Cross-Site Scripting (XSS) vulnerability. This enables an attacker, without requiring any privileges, to inject malicious JavaScript into a website. When a user visits the compromised page, the injected script gets executed, potentially compromising the confidentiality and integrity within the scope of the victim�s browser. Availability is not impacted.

The 3DPrint Lite plugin for WordPress is vulnerable to SQL Injection via the 'printer_text' parameter in all versions up to, and including, 2.1.3.6 due to insufficient escaping on the user supplied parameter and lack of sufficient preparation on the existing SQL query. This makes it possible for unauthenticated attackers to append additional SQL queries into already existing queries that can be used to extract sensitive information from the database.

The 3DPrint Lite plugin for WordPress is vulnerable to SQL Injection via the 'material_text' parameter in all versions up to, and including, 2.1.3.6 due to insufficient escaping on the user supplied parameter and lack of sufficient preparation on the existing SQL query. This makes it possible for unauthenticated attackers to append additional SQL queries into already existing queries that can be used to extract sensitive information from the database.

The 3DPrint Lite plugin for WordPress is vulnerable to SQL Injection via the 'coating_text' parameter in all versions up to, and including, 2.1.3.6 due to insufficient escaping on the user supplied parameter and lack of sufficient preparation on the existing SQL query. This makes it possible for unauthenticated attackers to append additional SQL queries into already existing queries that can be used to extract sensitive information from the database.

The 3DPrint Lite plugin for WordPress is vulnerable to SQL Injection via the 'infill_text' parameter in all versions up to, and including, 2.1.3.6 due to insufficient escaping on the user supplied parameter and lack of sufficient preparation on the existing SQL query. This makes it possible for unauthenticated attackers to append additional SQL queries into already existing queries that can be used to extract sensitive information from the database.