CVE Database

Dell PowerProtect DD, version(s) 8.0, 7.13.1.0, 7.10.1.30, 7.7.5.40, contain(s) an Out-of-bounds Write vulnerability. A low privileged attacker with remote access could potentially exploit this vulnerability, leading to Code execution.

A vulnerability in the default configuration of the Simple Network Management Protocol (SNMP) feature of Brocade Fabric OS versions before v9.0.0 could allow an authenticated, remote attacker to read data from an affected device via SNMP. The vulnerability is due to hard-coded, default community string in the configuration file for the SNMP daemon. An attacker could exploit this vulnerability by using the static community string in SNMP version 1 queries to an affected device.

The WP Cookie Consent ( for GDPR, CCPA & ePrivacy ) plugin for WordPress is vulnerable to Stored Cross-Site Scripting via the ‘Client-IP’ header in all versions up to, and including, 3.2.0 due to insufficient input sanitization and output escaping. This makes it possible for unauthenticated attackers to inject arbitrary web scripts in pages that will execute whenever a user accesses an injected page.

pdoc provides API Documentation for Python Projects. Documentation generated with `pdoc --math` linked to JavaScript files from polyfill.io. The polyfill.io CDN has been sold and now serves malicious code. This issue has been fixed in pdoc 14.5.1.

Insecure Access Control in Safe Exam Browser (SEB) = 3.5.0 on Windows. The vulnerability allows an attacker to share clipboard data between the SEB kiosk mode and the underlying system, compromising exam integrity. By exploiting this flaw, an attacker can bypass exam controls and gain an unfair advantage during exams.

In WhatsUp Gold versions released before 2023.1.3, Distributed Edition installations can be exploited by using a deserialization tool to achieve a Remote Code Execution as SYSTEM.  The vulnerability exists in the main message processing routines NmDistributed.DistributedServiceBehavior.OnMessage for server and NmDistributed.DistributedClient.OnMessage for clients.

In WhatsUp Gold versions released before 2023.1.3, an authenticated SSRF vulnerability in Wug.UI.Areas.Wug.Controllers.SessionControler.Update allows a low privileged user to chain this SSRF with an Improper Access Control vulnerability. This can be used to escalate privileges to Admin.

In WhatsUp Gold versions released before 2023.1.3, a Server Side Request Forgery vulnerability exists in the GetASPReport feature. This allows any authenticated user to retrieve ASP reports from an HTML form.

In WhatsUp Gold versions released before 2023.1.3, an unauthenticated Denial of Service vulnerability was identified. An unauthenticated attacker can put the application into the SetAdminPassword installation step, which renders the application non-accessible.

In WhatsUp Gold versions released before 2023.1.3, there is a missing authentication vulnerability in WUGDataAccess.Credentials. This vulnerability allows unauthenticated attackers to disclose Windows Credentials stored in the product Credential Library.

ai-client-html is an Aimeos e-commerce HTML client component. Debug information revealed sensitive information from environment variables in error log. This issue has been patched in versions 2024.04.7, 2023.10.15, 2022.10.13 and 2021.10.22.

An issue in Nepstech Wifi Router xpon (terminal) NTPL-Xpon1GFEVN, hardware verstion 1.0 firmware 2.0.1 allows a remote attacker to execute arbitrary code via the router's Telnet port 2345 without requiring authentication credentials.

Artery AT32F415CBT7 and AT32F421C8T7 devices have Incorrect Access Control.

A security vulnerability has been identified in HPE Athonet Mobile Core software. The core application contains a code injection vulnerability where a threat actor could execute arbitrary commands with the privilege of the underlying container leading to complete takeover of the target system.

In WhatsUp Gold versions released before 2023.1.3, an uncontrolled resource consumption vulnerability exists. A specially crafted unauthenticated HTTP request to the TestController Chart functionality can lead to denial of service.

In WhatsUp Gold versions released before 2023.1.3, a vulnerability exists in the TestController functionality.  A specially crafted unauthenticated HTTP request can lead to a disclosure of sensitive information.

In WhatsUp Gold versions released before 2023.1.3, an Improper Access Control vulnerability in Wug.UI.Controllers.InstallController.SetAdminPassword allows local attackers to modify admin's password.

In WhatsUp Gold versions released before 2023.1.3, an authenticated user with certain permissions can upload an arbitrary file and obtain RCE using Apm.UI.Areas.APM.Controllers.Api.Applications.AppProfileImportController.

A Path Traversal and Remote File Inclusion (RFI) vulnerability exists in the parisneo/lollms-webui application, affecting versions v9.7 to the latest. The vulnerability arises from insufficient input validation in the `/apply_settings` function, allowing an attacker to manipulate the `discussion_db_name` parameter to traverse the file system and include arbitrary files. This issue is compounded by the bypass of input filtering in the `install_binding`, `reinstall_binding`, and `unInstall_binding` endpoints, despite the presence of a `sanitize_path_from_endpoint(data.name)` filter. Successful exploitation enables an attacker to upload and execute malicious code on the victim's system, leading to Remote Code Execution (RCE).

A vulnerability was found in itsourcecode Simple Online Hotel Reservation System 1.0. It has been declared as critical. This vulnerability affects unknown code of the file index.php. The manipulation of the argument username leads to sql injection. The attack can be initiated remotely. The exploit has been disclosed to the public and may be used. The identifier of this vulnerability is VDB-269620.

HashiCorp’s go-getter library can be coerced into executing Git update on an existing maliciously modified Git Configuration, potentially leading to arbitrary code execution.

pgAdmin <= 8.8 has an installation Directory permission issue. Because of this issue, attackers can gain unauthorised access to the installation directory on the Debian or RHEL 8 platforms.

Due to an improper input validation, an unauthenticated threat actor can send a malicious message to a monitor thread within Rockwell Automation ThinServer™ and cause a denial-of-service condition on the affected device.

In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: add error handle to avoid out-of-bounds if the sdma_v4_0_irq_id_to_seq return -EINVAL, the process should be stop to avoid out-of-bounds read, so directly return -EINVAL.

In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix nilfs_empty_dir() misjudgment and long loop on I/O errors The error handling in nilfs_empty_dir() when a directory folio/page read fails is incorrect, as in the old ext2 implementation, and if the folio/page cannot be read or nilfs_check_folio() fails, it will falsely determine the directory as empty and corrupt the file system. In addition, since nilfs_empty_dir() does not immediately return on a failed folio/page read, but continues to loop, this can cause a long loop with I/O if i_size of the directory's inode is also corrupted, causing the log writer thread to wait and hang, as reported by syzbot. Fix these issues by making nilfs_empty_dir() immediately return a false value (0) if it fails to get a directory folio/page.

In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to do sanity check on i_xattr_nid in sanity_check_inode() syzbot reports a kernel bug as below: F2FS-fs (loop0): Mounted with checkpoint version = 48b305e4 ================================================================== BUG: KASAN: slab-out-of-bounds in f2fs_test_bit fs/f2fs/f2fs.h:2933 [inline] BUG: KASAN: slab-out-of-bounds in current_nat_addr fs/f2fs/node.h:213 [inline] BUG: KASAN: slab-out-of-bounds in f2fs_get_node_info+0xece/0x1200 fs/f2fs/node.c:600 Read of size 1 at addr ffff88807a58c76c by task syz-executor280/5076 CPU: 1 PID: 5076 Comm: syz-executor280 Not tainted 6.9.0-rc5-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024 Call Trace: <TASK> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:114 print_address_description mm/kasan/report.c:377 [inline] print_report+0x169/0x550 mm/kasan/report.c:488 kasan_report+0x143/0x180 mm/kasan/report.c:601 f2fs_test_bit fs/f2fs/f2fs.h:2933 [inline] current_nat_addr fs/f2fs/node.h:213 [inline] f2fs_get_node_info+0xece/0x1200 fs/f2fs/node.c:600 f2fs_xattr_fiemap fs/f2fs/data.c:1848 [inline] f2fs_fiemap+0x55d/0x1ee0 fs/f2fs/data.c:1925 ioctl_fiemap fs/ioctl.c:220 [inline] do_vfs_ioctl+0x1c07/0x2e50 fs/ioctl.c:838 __do_sys_ioctl fs/ioctl.c:902 [inline] __se_sys_ioctl+0x81/0x170 fs/ioctl.c:890 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf5/0x240 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f The root cause is we missed to do sanity check on i_xattr_nid during f2fs_iget(), so that in fiemap() path, current_nat_addr() will access nat_bitmap w/ offset from invalid i_xattr_nid, result in triggering kasan bug report, fix it.

In the Linux kernel, the following vulnerability has been resolved: 9p: add missing locking around taking dentry fid list Fix a use-after-free on dentry's d_fsdata fid list when a thread looks up a fid through dentry while another thread unlinks it: UAF thread: refcount_t: addition on 0; use-after-free. p9_fid_get linux/./include/net/9p/client.h:262 v9fs_fid_find+0x236/0x280 linux/fs/9p/fid.c:129 v9fs_fid_lookup_with_uid linux/fs/9p/fid.c:181 v9fs_fid_lookup+0xbf/0xc20 linux/fs/9p/fid.c:314 v9fs_vfs_getattr_dotl+0xf9/0x360 linux/fs/9p/vfs_inode_dotl.c:400 vfs_statx+0xdd/0x4d0 linux/fs/stat.c:248 Freed by: p9_fid_destroy (inlined) p9_client_clunk+0xb0/0xe0 linux/net/9p/client.c:1456 p9_fid_put linux/./include/net/9p/client.h:278 v9fs_dentry_release+0xb5/0x140 linux/fs/9p/vfs_dentry.c:55 v9fs_remove+0x38f/0x620 linux/fs/9p/vfs_inode.c:518 vfs_unlink+0x29a/0x810 linux/fs/namei.c:4335 The problem is that d_fsdata was not accessed under d_lock, because d_release() normally is only called once the dentry is otherwise no longer accessible but since we also call it explicitly in v9fs_remove that lock is required: move the hlist out of the dentry under lock then unref its fids once they are no longer accessible.

In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix potential kernel bug due to lack of writeback flag waiting Destructive writes to a block device on which nilfs2 is mounted can cause a kernel bug in the folio/page writeback start routine or writeback end routine (__folio_start_writeback in the log below): kernel BUG at mm/page-writeback.c:3070! Oops: invalid opcode: 0000 [#1] PREEMPT SMP KASAN PTI ... RIP: 0010:__folio_start_writeback+0xbaa/0x10e0 Code: 25 ff 0f 00 00 0f 84 18 01 00 00 e8 40 ca c6 ff e9 17 f6 ff ff e8 36 ca c6 ff 4c 89 f7 48 c7 c6 80 c0 12 84 e8 e7 b3 0f 00 90 <0f> 0b e8 1f ca c6 ff 4c 89 f7 48 c7 c6 a0 c6 12 84 e8 d0 b3 0f 00 ... Call Trace: <TASK> nilfs_segctor_do_construct+0x4654/0x69d0 [nilfs2] nilfs_segctor_construct+0x181/0x6b0 [nilfs2] nilfs_segctor_thread+0x548/0x11c0 [nilfs2] kthread+0x2f0/0x390 ret_from_fork+0x4b/0x80 ret_from_fork_asm+0x1a/0x30 </TASK> This is because when the log writer starts a writeback for segment summary blocks or a super root block that use the backing device's page cache, it does not wait for the ongoing folio/page writeback, resulting in an inconsistent writeback state. Fix this issue by waiting for ongoing writebacks when putting folios/pages on the backing device into writeback state.

In the Linux kernel, the following vulnerability has been resolved: x86/xen: Drop USERGS_SYSRET64 paravirt call commit afd30525a659ac0ae0904f0cb4a2ca75522c3123 upstream. USERGS_SYSRET64 is used to return from a syscall via SYSRET, but a Xen PV guest will nevertheless use the IRET hypercall, as there is no sysret PV hypercall defined. So instead of testing all the prerequisites for doing a sysret and then mangling the stack for Xen PV again for doing an iret just use the iret exit from the beginning. This can easily be done via an ALTERNATIVE like it is done for the sysenter compat case already. It should be noted that this drops the optimization in Xen for not restoring a few registers when returning to user mode, but it seems as if the saved instructions in the kernel more than compensate for this drop (a kernel build in a Xen PV guest was slightly faster with this patch applied). While at it remove the stale sysret32 remnants. [ pawan: Brad Spengler and Salvatore Bonaccorso <carnil@debian.org> reported a problem with the 5.10 backport commit edc702b4a820 ("x86/entry_64: Add VERW just before userspace transition"). When CONFIG_PARAVIRT_XXL=y, CLEAR_CPU_BUFFERS is not executed in syscall_return_via_sysret path as USERGS_SYSRET64 is runtime patched to: .cpu_usergs_sysret64 = { 0x0f, 0x01, 0xf8, 0x48, 0x0f, 0x07 }, // swapgs; sysretq which is missing CLEAR_CPU_BUFFERS. It turns out dropping USERGS_SYSRET64 simplifies the code, allowing CLEAR_CPU_BUFFERS to be explicitly added to syscall_return_via_sysret path. Below is with CONFIG_PARAVIRT_XXL=y and this patch applied: syscall_return_via_sysret: ... <+342>: swapgs <+345>: xchg %ax,%ax <+347>: verw -0x1a2(%rip) <------ <+354>: sysretq ]

PX4-Autopilot v1.14.3 was discovered to contain a buffer overflow via the topic_name parameter at /logger/logged_topics.cpp.