| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| The Header Footer Code Manager Pro plugin for WordPress is vulnerable to Reflected Cross-Site Scripting via the message parameter in all versions up to, and including, 1.0.16 due to insufficient input sanitization and output escaping. This makes it possible for unauthenticated attackers to inject arbitrary web scripts in pages that execute if they can successfully trick a user into performing an action such as clicking on a link. |
| In the module RSI PDF/HTML catalog evolution (prestapdf) <= 7.0.0 from RSI for PrestaShop, a guest can perform SQL injection via `PrestaPDFProductListModuleFrontController::queryDb().' |
| An issue was discovered in Centreon centreon-bam 24.04, 23.10, 23.04, and 22.10. SQL injection can occur in the user-settings form. Exploitation is only accessible to authenticated users with high-privileged access. |
| An unauthenticated directory traversal vulnerability exists in Polyaxon, affecting the latest version. This vulnerability allows an attacker to retrieve directory information and file contents from the server without proper authorization, leading to sensitive information disclosure. The issue enables access to system directories such as `/etc`, potentially resulting in significant security risks. |
| An issue was discovered in Centreon centreon-dsm-server 24.10.x before 24.10.0, 24.04.x before 24.04.3, 23.10.x before 23.10.1, 23.04.x before 23.04.3, and 22.10.x before 22.10.2. SQL injection can occur in the form to configure Centreon DSM slots. Exploitation is only accessible to authenticated users with high-privileged access. |
| OS command injection vulnerability exists in awkblog v0.0.1 (commit hash:7b761b192d0e0dc3eef0f30630e00ece01c8d552) and earlier. If a remote unauthenticated attacker sends a specially crafted HTTP request, an arbitrary OS command may be executed with the privileges of the affected product on the machine running the product. |
| In the Linux kernel, the following vulnerability has been resolved:
blk-cgroup: fix possible deadlock while configuring policy
Following deadlock can be triggered easily by lockdep:
WARNING: possible circular locking dependency detected
6.17.0-rc3-00124-ga12c2658ced0 #1665 Not tainted
------------------------------------------------------
check/1334 is trying to acquire lock:
ff1100011d9d0678 (&q->sysfs_lock){+.+.}-{4:4}, at: blk_unregister_queue+0x53/0x180
but task is already holding lock:
ff1100011d9d00e0 (&q->q_usage_counter(queue)#3){++++}-{0:0}, at: del_gendisk+0xba/0x110
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #2 (&q->q_usage_counter(queue)#3){++++}-{0:0}:
blk_queue_enter+0x40b/0x470
blkg_conf_prep+0x7b/0x3c0
tg_set_limit+0x10a/0x3e0
cgroup_file_write+0xc6/0x420
kernfs_fop_write_iter+0x189/0x280
vfs_write+0x256/0x490
ksys_write+0x83/0x190
__x64_sys_write+0x21/0x30
x64_sys_call+0x4608/0x4630
do_syscall_64+0xdb/0x6b0
entry_SYSCALL_64_after_hwframe+0x76/0x7e
-> #1 (&q->rq_qos_mutex){+.+.}-{4:4}:
__mutex_lock+0xd8/0xf50
mutex_lock_nested+0x2b/0x40
wbt_init+0x17e/0x280
wbt_enable_default+0xe9/0x140
blk_register_queue+0x1da/0x2e0
__add_disk+0x38c/0x5d0
add_disk_fwnode+0x89/0x250
device_add_disk+0x18/0x30
virtblk_probe+0x13a3/0x1800
virtio_dev_probe+0x389/0x610
really_probe+0x136/0x620
__driver_probe_device+0xb3/0x230
driver_probe_device+0x2f/0xe0
__driver_attach+0x158/0x250
bus_for_each_dev+0xa9/0x130
driver_attach+0x26/0x40
bus_add_driver+0x178/0x3d0
driver_register+0x7d/0x1c0
__register_virtio_driver+0x2c/0x60
virtio_blk_init+0x6f/0xe0
do_one_initcall+0x94/0x540
kernel_init_freeable+0x56a/0x7b0
kernel_init+0x2b/0x270
ret_from_fork+0x268/0x4c0
ret_from_fork_asm+0x1a/0x30
-> #0 (&q->sysfs_lock){+.+.}-{4:4}:
__lock_acquire+0x1835/0x2940
lock_acquire+0xf9/0x450
__mutex_lock+0xd8/0xf50
mutex_lock_nested+0x2b/0x40
blk_unregister_queue+0x53/0x180
__del_gendisk+0x226/0x690
del_gendisk+0xba/0x110
sd_remove+0x49/0xb0 [sd_mod]
device_remove+0x87/0xb0
device_release_driver_internal+0x11e/0x230
device_release_driver+0x1a/0x30
bus_remove_device+0x14d/0x220
device_del+0x1e1/0x5a0
__scsi_remove_device+0x1ff/0x2f0
scsi_remove_device+0x37/0x60
sdev_store_delete+0x77/0x100
dev_attr_store+0x1f/0x40
sysfs_kf_write+0x65/0x90
kernfs_fop_write_iter+0x189/0x280
vfs_write+0x256/0x490
ksys_write+0x83/0x190
__x64_sys_write+0x21/0x30
x64_sys_call+0x4608/0x4630
do_syscall_64+0xdb/0x6b0
entry_SYSCALL_64_after_hwframe+0x76/0x7e
other info that might help us debug this:
Chain exists of:
&q->sysfs_lock --> &q->rq_qos_mutex --> &q->q_usage_counter(queue)#3
Possible unsafe locking scenario:
CPU0 CPU1
---- ----
lock(&q->q_usage_counter(queue)#3);
lock(&q->rq_qos_mutex);
lock(&q->q_usage_counter(queue)#3);
lock(&q->sysfs_lock);
Root cause is that queue_usage_counter is grabbed with rq_qos_mutex
held in blkg_conf_prep(), while queue should be freezed before
rq_qos_mutex from other context.
The blk_queue_enter() from blkg_conf_prep() is used to protect against
policy deactivation, which is already protected with blkcg_mutex, hence
convert blk_queue_enter() to blkcg_mutex to fix this problem. Meanwhile,
consider that blkcg_mutex is held after queue is freezed from policy
deactivation, also convert blkg_alloc() to use GFP_NOIO. |
| tgt (aka Linux target framework) before 1.0.93 attempts to achieve entropy by calling rand without srand. The PRNG seed is always 1, and thus the sequence of challenges is always identical. |
| A transient execution vulnerability in some AMD processors may allow an attacker to infer data in the L1D cache, potentially resulting in the leakage of sensitive information across privileged boundaries. |
| A transient execution vulnerability in some AMD processors may allow an attacker to infer data from previous stores, potentially resulting in the leakage of privileged information. |
| A vulnerability has been identified in SIPROTEC 5 6MD84 (CP300) (All versions < V9.90), SIPROTEC 5 6MD85 (CP200) (All versions), SIPROTEC 5 6MD85 (CP300) (All versions < V9.90), SIPROTEC 5 6MD86 (CP200) (All versions), SIPROTEC 5 6MD86 (CP300) (All versions < V9.90), SIPROTEC 5 6MD89 (CP300) (All versions < V9.90), SIPROTEC 5 6MU85 (CP300) (All versions < V9.90), SIPROTEC 5 7KE85 (CP200) (All versions), SIPROTEC 5 7KE85 (CP300) (All versions < V10.0), SIPROTEC 5 7SA82 (CP100) (All versions < V8.90), SIPROTEC 5 7SA82 (CP150) (All versions < V9.90), SIPROTEC 5 7SA86 (CP200) (All versions), SIPROTEC 5 7SA86 (CP300) (All versions < V9.90), SIPROTEC 5 7SA87 (CP200) (All versions), SIPROTEC 5 7SA87 (CP300) (All versions < V9.90), SIPROTEC 5 7SD82 (CP100) (All versions < V8.90), SIPROTEC 5 7SD82 (CP150) (All versions < V9.90), SIPROTEC 5 7SD86 (CP200) (All versions), SIPROTEC 5 7SD86 (CP300) (All versions < V9.90), SIPROTEC 5 7SD87 (CP200) (All versions), SIPROTEC 5 7SD87 (CP300) (All versions < V9.90), SIPROTEC 5 7SJ81 (CP100) (All versions < V8.90), SIPROTEC 5 7SJ81 (CP150) (All versions < V9.90), SIPROTEC 5 7SJ82 (CP100) (All versions < V8.90), SIPROTEC 5 7SJ82 (CP150) (All versions < V9.90), SIPROTEC 5 7SJ85 (CP200) (All versions), SIPROTEC 5 7SJ85 (CP300) (All versions < V9.90), SIPROTEC 5 7SJ86 (CP200) (All versions), SIPROTEC 5 7SJ86 (CP300) (All versions < V9.90), SIPROTEC 5 7SK82 (CP100) (All versions < V8.90), SIPROTEC 5 7SK82 (CP150) (All versions < V9.90), SIPROTEC 5 7SK85 (CP200) (All versions), SIPROTEC 5 7SK85 (CP300) (All versions < V9.90), SIPROTEC 5 7SL82 (CP100) (All versions < V8.90), SIPROTEC 5 7SL82 (CP150) (All versions < V9.90), SIPROTEC 5 7SL86 (CP200) (All versions), SIPROTEC 5 7SL86 (CP300) (All versions < V9.90), SIPROTEC 5 7SL87 (CP200) (All versions), SIPROTEC 5 7SL87 (CP300) (All versions < V9.90), SIPROTEC 5 7SS85 (CP200) (All versions), SIPROTEC 5 7SS85 (CP300) (All versions < V9.90), SIPROTEC 5 7ST85 (CP200) (All versions), SIPROTEC 5 7ST85 (CP300) (All versions < V10.0), SIPROTEC 5 7ST86 (CP300) (All versions < V10.0), SIPROTEC 5 7SX82 (CP150) (All versions < V9.90), SIPROTEC 5 7SX85 (CP300) (All versions < V9.90), SIPROTEC 5 7SY82 (CP150) (All versions < V9.90), SIPROTEC 5 7UM85 (CP300) (All versions < V9.90), SIPROTEC 5 7UT82 (CP100) (All versions < V8.90), SIPROTEC 5 7UT82 (CP150) (All versions < V9.90), SIPROTEC 5 7UT85 (CP200) (All versions), SIPROTEC 5 7UT85 (CP300) (All versions < V9.90), SIPROTEC 5 7UT86 (CP200) (All versions), SIPROTEC 5 7UT86 (CP300) (All versions < V9.90), SIPROTEC 5 7UT87 (CP200) (All versions), SIPROTEC 5 7UT87 (CP300) (All versions < V9.90), SIPROTEC 5 7VE85 (CP300) (All versions < V9.90), SIPROTEC 5 7VK87 (CP200) (All versions), SIPROTEC 5 7VK87 (CP300) (All versions < V9.90), SIPROTEC 5 7VU85 (CP300) (All versions < V9.90), SIPROTEC 5 Compact 7SX800 (CP050) (All versions < V9.90). Affected devices do not properly limit access to a development shell accessible over a physical interface. This could allow an unauthenticated attacker with physical access to the device to execute arbitrary commands on the device. |
| An issue in TheGreenBow Windows Standard VPN Client 6.87.108 (and older), Windows Enterprise VPN Client 6.87.109 (and older), Windows Enterprise VPN Client 7.5.007 (and older), Android VPN Client 6.4.5 (and older) VPN Client Linux 3.4 (and older), VPN Client MacOS 2.4.10 (and older) allows a remote attacker to execute arbitrary code via the IKEv2 Authentication phase, it accepts malformed ECDSA signatures and establishes the tunnel. |
| A transient execution vulnerability in some AMD processors may allow a user process to infer TSC_AUX even when such a read is disabled, potentially resulting in information leakage. |
| An issue was discovered in Trusted Firmware-M through 2.1.0. User provided (and controlled) mailbox messages contain a pointer to a list of input arguments (in_vec) and output arguments (out_vec). These list pointers are never validated. Each argument list contains a buffer pointer and a buffer length field. After a PSA call, the length of the output arguments behind the unchecked pointer is updated in mailbox_direct_reply, regardless of the call result. This allows an attacker to write anywhere in the secure firmware, which can be used to take over the control flow, leading to remote code execution (RCE). |
| Improper signature verification in AMD CPU ROM microcode patch loader may allow an attacker with local administrator privilege to load malicious microcode, potentially resulting in loss of integrity of x86 instruction execution, loss of confidentiality and integrity of data in x86 CPU privileged context and compromise of SMM execution environment. |
| A vulnerability in Node.js has been identified, allowing for a Denial of Service (DoS) attack through resource exhaustion when using the fetch() function to retrieve content from an untrusted URL.
The vulnerability stems from the fact that the fetch() function in Node.js always decodes Brotli, making it possible for an attacker to cause resource exhaustion when fetching content from an untrusted URL.
An attacker controlling the URL passed into fetch() can exploit this vulnerability to exhaust memory, potentially leading to process termination, depending on the system configuration. |
| Improper input validation in the GPU driver could allow an attacker to exploit a heap overflow potentially resulting in arbitrary code execution. |
| Use of hard-coded, the same among all vulnerable installations SQLite credentials vulnerability in SIGNUM-NET FARA allows to read and manipulate local-stored database.This issue affects FARA: through 5.0.80.34. |
| An attacker could obtain firmware files and reverse engineer their
intended use leading to loss of confidentiality and integrity of the
hardware devices enabled by the Qardio iOS and Android applications. |
| When uploading organism or sequence data via the web interface,
GMOD Apollo
will unzip and inspect the files and will not check for path
traversal in supported archive types. |
