| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| An overly-permissive IAM trust policy in the Harmonix on AWS framework may allow IAM principals in the same AWS account to escalate privileges via role assumption. The sample code for the EKS environment provisioning role is configured to trust the account root principal, which may enable any IAM principal in the same AWS account with sts:AssumeRole permissions to assume the role with administrative privileges.
We recommend customers upgrade to Harmonix on AWS v0.4.2 or later if you have deployed the framework using versions v0.3.0 through v0.4.1. |
| FreePBX is an open-source web-based graphical user interface (GUI) that manages Asterisk. Prior to versions 16.0.45 and 17.0.24 of the FreePBX framework, an authenticated local privilege escalation exists in the deprecated FreePBX startup script `amportal`. In the deprecated `amportal` utility, the lookup for the `freepbx_engine` file occurs in `/etc/asterisk/` directories. Typically, these are configured by FreePBX as writable by the **asterisk** user and any members of the **asterisk** group. This means that a member of the **asterisk** group can add their own `freepbx_engine` file in `/etc/asterisk/` and upon `amportal` executing, it would exec that file with root permissions (even though the file was created and placed by a non-root user). Version 16.0.45 and 17.0.24 contain a fix for the issue. Other mitigation strategies are also available. Confirm only trusted local OS system users are members of the `asterisk` group. Look for suspicious files in the `/etc/asterisk/` directory (via Admin -> Config Edit in the GUI, or via CLI). Double-check that `live_dangerously = no` is set (or unconfigured, as the default is **no**) in `/etc/asterisk/asterisk.conf` file. Eliminate any unsafe custom use of Asterisk dial plan applications and functions that potentially can manipulate the file system, e.g., System(), FILE(), etc. |
| The FreePBX module tts (Text to Speech) for FreePBX, an open-source web-based graphical user interface (GUI) that manages Asterisk. Versions prior to 16.0.5 and 17.0.5 are vulnerable to SQL injection by authenticated users with administrator access. Authenticated users with administrative access to the Administrator Control Panel (ACP) can leverage this SQL injection vulnerability to extract sensitive information from the database and execute code on the system as the `asterisk` user with chained elevation to `root` privileges. Users should upgrade to version 16.0.5 or 17.0.5 to receive a fix. |
| An SQL injection vulnerability has been reported to affect several QNAP operating system versions. The remote attackers can then exploit the vulnerability to execute unauthorized code or commands.
We have already fixed the vulnerability in the following versions:
QTS 5.2.7.3297 build 20251024 and later
QuTS hero h5.2.7.3297 build 20251024 and later
QuTS hero h5.3.1.3292 build 20251024 and later |
| An authentication bypass by spoofing vulnerability has been reported to affect several QNAP operating system versions. The remote attackers can then exploit the vulnerability to access resources which are not otherwise accessible without proper authentication.
We have already fixed the vulnerability in the following versions:
QTS 5.2.7.3297 build 20251024 and later
QuTS hero h5.2.7.3297 build 20251024 and later
QuTS hero h5.3.1.3292 build 20251024 and later |
| A remote code execution issue exists in HPE OneView. |
| NVIDIA NeMo Framework contains a vulnerability in model loading that could allow an attacker to exploit improper control mechanisms if a user loads a maliciously crafted file. A successful exploit of this vulnerability might lead to code execution, escalation of privileges, denial of service, and data tampering. |
| NVIDIA NeMo Framework for all platforms contains a vulnerability where malicious data created by an attacker may cause a code injection. A successful exploit of this vulnerability may lead to code execution, escalation of privileges, information disclosure, and data tampering. |
| Apache Commons Text versions prior to 1.10.0 included interpolation features that could be abused when applications passed untrusted input into the text-substitution API. Because some interpolators could trigger actions like executing commands or accessing external resources, an attacker could potentially achieve remote code execution. This vulnerability has been fully addressed in FileMaker Server 22.0.4. |
| Mismatched length fields in Zlib compressed protocol headers may allow a read of uninitialized heap memory by an unauthenticated client. This issue affects all MongoDB Server v7.0 prior to 7.0.28 versions, MongoDB Server v8.0 versions prior to 8.0.17, MongoDB Server v8.2 versions prior to 8.2.3, MongoDB Server v6.0 versions prior to 6.0.27, MongoDB Server v5.0 versions prior to 5.0.32, MongoDB Server v4.4 versions prior to 4.4.30, MongoDB Server v4.2 versions greater than or equal to 4.2.0, MongoDB Server v4.0 versions greater than or equal to 4.0.0, and MongoDB Server v3.6 versions greater than or equal to 3.6.0. |
| In the Linux kernel, the following vulnerability has been resolved:
exfat: fix refcount leak in exfat_find
Fix refcount leaks in `exfat_find` related to `exfat_get_dentry_set`.
Function `exfat_get_dentry_set` would increase the reference counter of
`es->bh` on success. Therefore, `exfat_put_dentry_set` must be called
after `exfat_get_dentry_set` to ensure refcount consistency. This patch
relocate two checks to avoid possible leaks. |
| In the Linux kernel, the following vulnerability has been resolved:
drm/radeon: delete radeon_fence_process in is_signaled, no deadlock
Delete the attempt to progress the queue when checking if fence is
signaled. This avoids deadlock.
dma-fence_ops::signaled can be called with the fence lock in unknown
state. For radeon, the fence lock is also the wait queue lock. This can
cause a self deadlock when signaled() tries to make forward progress on
the wait queue. But advancing the queue is unneeded because incorrectly
returning false from signaled() is perfectly acceptable.
(cherry picked from commit 527ba26e50ec2ca2be9c7c82f3ad42998a75d0db) |
| In the Linux kernel, the following vulnerability has been resolved:
timers: Fix NULL function pointer race in timer_shutdown_sync()
There is a race condition between timer_shutdown_sync() and timer
expiration that can lead to hitting a WARN_ON in expire_timers().
The issue occurs when timer_shutdown_sync() clears the timer function
to NULL while the timer is still running on another CPU. The race
scenario looks like this:
CPU0 CPU1
<SOFTIRQ>
lock_timer_base()
expire_timers()
base->running_timer = timer;
unlock_timer_base()
[call_timer_fn enter]
mod_timer()
...
timer_shutdown_sync()
lock_timer_base()
// For now, will not detach the timer but only clear its function to NULL
if (base->running_timer != timer)
ret = detach_if_pending(timer, base, true);
if (shutdown)
timer->function = NULL;
unlock_timer_base()
[call_timer_fn exit]
lock_timer_base()
base->running_timer = NULL;
unlock_timer_base()
...
// Now timer is pending while its function set to NULL.
// next timer trigger
<SOFTIRQ>
expire_timers()
WARN_ON_ONCE(!fn) // hit
...
lock_timer_base()
// Now timer will detach
if (base->running_timer != timer)
ret = detach_if_pending(timer, base, true);
if (shutdown)
timer->function = NULL;
unlock_timer_base()
The problem is that timer_shutdown_sync() clears the timer function
regardless of whether the timer is currently running. This can leave a
pending timer with a NULL function pointer, which triggers the
WARN_ON_ONCE(!fn) check in expire_timers().
Fix this by only clearing the timer function when actually detaching the
timer. If the timer is running, leave the function pointer intact, which is
safe because the timer will be properly detached when it finishes running. |
| In the Linux kernel, the following vulnerability has been resolved:
tls: Use __sk_dst_get() and dst_dev_rcu() in get_netdev_for_sock().
get_netdev_for_sock() is called during setsockopt(),
so not under RCU.
Using sk_dst_get(sk)->dev could trigger UAF.
Let's use __sk_dst_get() and dst_dev_rcu().
Note that the only ->ndo_sk_get_lower_dev() user is
bond_sk_get_lower_dev(), which uses RCU. |
| In the Linux kernel, the following vulnerability has been resolved:
hfsplus: fix slab-out-of-bounds read in hfsplus_uni2asc()
BUG: KASAN: slab-out-of-bounds in hfsplus_uni2asc+0xa71/0xb90 fs/hfsplus/unicode.c:186
Read of size 2 at addr ffff8880289ef218 by task syz.6.248/14290
CPU: 0 UID: 0 PID: 14290 Comm: syz.6.248 Not tainted 6.16.4 #1 PREEMPT(full)
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014
Call Trace:
<TASK>
__dump_stack lib/dump_stack.c:94 [inline]
dump_stack_lvl+0x116/0x1b0 lib/dump_stack.c:120
print_address_description mm/kasan/report.c:378 [inline]
print_report+0xca/0x5f0 mm/kasan/report.c:482
kasan_report+0xca/0x100 mm/kasan/report.c:595
hfsplus_uni2asc+0xa71/0xb90 fs/hfsplus/unicode.c:186
hfsplus_listxattr+0x5b6/0xbd0 fs/hfsplus/xattr.c:738
vfs_listxattr+0xbe/0x140 fs/xattr.c:493
listxattr+0xee/0x190 fs/xattr.c:924
filename_listxattr fs/xattr.c:958 [inline]
path_listxattrat+0x143/0x360 fs/xattr.c:988
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0xcb/0x4c0 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7fe0e9fae16d
Code: 02 b8 ff ff ff ff c3 66 0f 1f 44 00 00 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007fe0eae67f98 EFLAGS: 00000246 ORIG_RAX: 00000000000000c3
RAX: ffffffffffffffda RBX: 00007fe0ea205fa0 RCX: 00007fe0e9fae16d
RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000200000000000
RBP: 00007fe0ea0480f0 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
R13: 00007fe0ea206038 R14: 00007fe0ea205fa0 R15: 00007fe0eae48000
</TASK>
Allocated by task 14290:
kasan_save_stack+0x24/0x50 mm/kasan/common.c:47
kasan_save_track+0x14/0x30 mm/kasan/common.c:68
poison_kmalloc_redzone mm/kasan/common.c:377 [inline]
__kasan_kmalloc+0xaa/0xb0 mm/kasan/common.c:394
kasan_kmalloc include/linux/kasan.h:260 [inline]
__do_kmalloc_node mm/slub.c:4333 [inline]
__kmalloc_noprof+0x219/0x540 mm/slub.c:4345
kmalloc_noprof include/linux/slab.h:909 [inline]
hfsplus_find_init+0x95/0x1f0 fs/hfsplus/bfind.c:21
hfsplus_listxattr+0x331/0xbd0 fs/hfsplus/xattr.c:697
vfs_listxattr+0xbe/0x140 fs/xattr.c:493
listxattr+0xee/0x190 fs/xattr.c:924
filename_listxattr fs/xattr.c:958 [inline]
path_listxattrat+0x143/0x360 fs/xattr.c:988
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0xcb/0x4c0 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
When hfsplus_uni2asc is called from hfsplus_listxattr,
it actually passes in a struct hfsplus_attr_unistr*.
The size of the corresponding structure is different from that of hfsplus_unistr,
so the previous fix (94458781aee6) is insufficient.
The pointer on the unicode buffer is still going beyond the allocated memory.
This patch introduces two warpper functions hfsplus_uni2asc_xattr_str and
hfsplus_uni2asc_str to process two unicode buffers,
struct hfsplus_attr_unistr* and struct hfsplus_unistr* respectively.
When ustrlen value is bigger than the allocated memory size,
the ustrlen value is limited to an safe size. |
| Building a malicious file with cmd/go can cause can cause a write to an attacker-controlled file with partial control of the file content. The "#cgo pkg-config:" directive in a Go source file provides command-line arguments to provide to the Go pkg-config command. An attacker can provide a "--log-file" argument to this directive, causing pkg-config to write to an attacker-controlled location. |
| Squid is vulnerable to a Denial of Service, where a remote attacker can perform buffer overflow attack by writing up to 2 MB of arbitrary data to heap memory when Squid is configured to accept HTTP Digest Authentication. |
| SQUID is vulnerable to HTTP request smuggling, caused by chunked decoder lenience, allows a remote attacker to perform Request/Response smuggling past firewall and frontend security systems. |
| A flaw was found in Undertow. When an AJP request is sent that exceeds the max-header-size attribute in ajp-listener, JBoss EAP is marked in an error state by mod_cluster in httpd, causing JBoss EAP to close the TCP connection without returning an AJP response. This happens because mod_proxy_cluster marks the JBoss EAP instance as an error worker when the TCP connection is closed from the backend after sending the AJP request without receiving an AJP response, and stops forwarding. This issue could allow a malicious user could to repeatedly send requests that exceed the max-header-size, causing a Denial of Service (DoS). |
| A bug in QEMU could cause a guest I/O operation otherwise addressed to an arbitrary disk offset to be targeted to offset 0 instead (potentially overwriting the VM's boot code). This could be used, for example, by L2 guests with a virtual disk (vdiskL2) stored on a virtual disk of an L1 (vdiskL1) hypervisor to read and/or write data to LBA 0 of vdiskL1, potentially gaining control of L1 at its next reboot. |
