| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| 1Panel versions 1.10.33 through 2.0.15 contain a cross-site request forgery (CSRF) vulnerability in the panel name management functionality. The affected endpoint does not implement CSRF defenses such as anti-CSRF tokens or Origin/Referer validation. An attacker can craft a malicious webpage that submits a panel-name change request; if a victim visits the page while authenticated, the browser includes valid session cookies and the request succeeds. This allows a remote attacker to change the victim’s panel name to an arbitrary value without consent. |
| 1Panel versions 1.10.33 - 2.0.15 contain a cross-site request forgery (CSRF) vulnerability in the web port configuration functionality. The port-change endpoint lacks CSRF defenses such as anti-CSRF tokens or Origin/Referer validation. An attacker can craft a malicious webpage that submits a port-change request; when a victim visits it while authenticated, the browser includes valid session cookies and the request succeeds. This allows an attacker to change the port on which the 1Panel web service listens, causing loss of access on the original port and resulting in service disruption or denial of service, and may unintentionally expose the service on an attacker-chosen port. |
| MailEnable versions prior to 10.54 contain an unsafe DLL loading vulnerability that can lead to local arbitrary code execution. The MailEnable administrative executable attempts to load MEAIAU.DLL from its installation directory without sufficient integrity validation or a secure search order. A local attacker with write access to that directory can plant a malicious MEAIAU.DLL, which is then loaded on execution, resulting in attacker-controlled code running with the privileges of the process. |
| In the Linux kernel, the following vulnerability has been resolved:
ftrace: Fix possible use-after-free issue in ftrace_location()
KASAN reports a bug:
BUG: KASAN: use-after-free in ftrace_location+0x90/0x120
Read of size 8 at addr ffff888141d40010 by task insmod/424
CPU: 8 PID: 424 Comm: insmod Tainted: G W 6.9.0-rc2+
[...]
Call Trace:
<TASK>
dump_stack_lvl+0x68/0xa0
print_report+0xcf/0x610
kasan_report+0xb5/0xe0
ftrace_location+0x90/0x120
register_kprobe+0x14b/0xa40
kprobe_init+0x2d/0xff0 [kprobe_example]
do_one_initcall+0x8f/0x2d0
do_init_module+0x13a/0x3c0
load_module+0x3082/0x33d0
init_module_from_file+0xd2/0x130
__x64_sys_finit_module+0x306/0x440
do_syscall_64+0x68/0x140
entry_SYSCALL_64_after_hwframe+0x71/0x79
The root cause is that, in lookup_rec(), ftrace record of some address
is being searched in ftrace pages of some module, but those ftrace pages
at the same time is being freed in ftrace_release_mod() as the
corresponding module is being deleted:
CPU1 | CPU2
register_kprobes() { | delete_module() {
check_kprobe_address_safe() { |
arch_check_ftrace_location() { |
ftrace_location() { |
lookup_rec() // USE! | ftrace_release_mod() // Free!
To fix this issue:
1. Hold rcu lock as accessing ftrace pages in ftrace_location_range();
2. Use ftrace_location_range() instead of lookup_rec() in
ftrace_location();
3. Call synchronize_rcu() before freeing any ftrace pages both in
ftrace_process_locs()/ftrace_release_mod()/ftrace_free_mem(). |
| Redis is an open source, in-memory database that persists on disk. In versions starting from 7.0.0 to before 8.0.2, a stack-based buffer overflow exists in redis-check-aof due to the use of memcpy with strlen(filepath) when copying a user-supplied file path into a fixed-size stack buffer. This allows an attacker to overflow the stack and potentially achieve code execution. This issue has been patched in version 8.0.2. |
| In the Linux kernel, the following vulnerability has been resolved:
RDMA/hns: Fix UAF for cq async event
The refcount of CQ is not protected by locks. When CQ asynchronous
events and CQ destruction are concurrent, CQ may have been released,
which will cause UAF.
Use the xa_lock() to protect the CQ refcount. |
| MailEnable versions prior to 10.54 contain an unsafe DLL loading vulnerability that can lead to local arbitrary code execution. The MailEnable administrative executable attempts to load MEAIPC.DLL from its installation directory without sufficient integrity validation or a secure search order. A local attacker with write access to that directory can plant a malicious MEAIPC.DLL, which is then loaded on execution, resulting in attacker-controlled code running with the privileges of the process. |
| Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling') vulnerability in Quest Coexistence Manager for Notes (Free/Busy Connector modules) allows HTTP Request Smuggling via the Content-Length-Transfer-Encoding (CL.TE) attack vector. This could allow an attacker to bypass access controls, poison web caches, hijack sessions, or trigger unintended internal requests. This issue affects Coexistence Manager for Notes 3.8.2045. Other versions may also be affected. |
| Flatnux 2021-03.25 contains an authenticated file upload vulnerability that allows administrative users to upload arbitrary PHP files through the file manager. Attackers with admin credentials can upload malicious PHP scripts to the web root directory, enabling remote code execution on the server. |
| AspEmail 5.6.0.2 contains a binary permission vulnerability that allows local users to escalate privileges through the Persits Software EmailAgent service. Attackers can exploit full write permissions in the BIN directory to replace the service executable and gain elevated system access. |
| ActFax 10.10 contains an unquoted service path vulnerability that allows local attackers to potentially escalate privileges by exploiting the ActiveFaxServiceNT service configuration. Attackers with write permissions to Program Files directories can inject a malicious ActSrvNT.exe executable to gain elevated system access when the service restarts. |
| Ever Gauzy v0.281.9 contains a JWT authentication vulnerability that allows attackers to exploit weak HMAC secret key implementation. Attackers can leverage the exposed JWT token to authenticate and gain unauthorized access with administrative permissions. |
| InnovaStudio WYSIWYG Editor 5.4 contains an unrestricted file upload vulnerability that allows attackers to bypass file extension restrictions through filename manipulation. Attackers can upload malicious ASP shells by using null byte techniques and alternate file extensions to circumvent upload controls in the asset manager. |
| Arcsoft PhotoStudio 6.0.0.172 contains an unquoted service path vulnerability in the ArcSoft Exchange Service that allows local attackers to escalate privileges. Attackers can place a malicious executable in the unquoted path and trigger the service to execute arbitrary code with system-level permissions. |
| OCS Inventory NG 2.3.0.0 contains an unquoted service path vulnerability that allows local attackers to escalate privileges to system level. Attackers can place a malicious executable in the unquoted service path and trigger the service restart to execute code with elevated system privileges. |
| Lilac-Reloaded for Nagios 2.0.8 contains a remote code execution vulnerability in the autodiscovery feature that allows attackers to inject arbitrary commands. Attackers can exploit the lack of input filtering in the nmap_binary parameter to execute a reverse shell by sending a crafted POST request to the autodiscovery endpoint. |
| In the Linux kernel, the following vulnerability has been resolved:
team: Move team device type change at the end of team_port_add
Attempting to add a port device that is already up will expectedly fail,
but not before modifying the team device header_ops.
In the case of the syzbot reproducer the gre0 device is
already in state UP when it attempts to add it as a
port device of team0, this fails but before that
header_ops->create of team0 is changed from eth_header to ipgre_header
in the call to team_dev_type_check_change.
Later when we end up in ipgre_header() struct ip_tunnel* points to nonsense
as the private data of the device still holds a struct team.
Example sequence of iproute2 commands to reproduce the hang/BUG():
ip link add dev team0 type team
ip link add dev gre0 type gre
ip link set dev gre0 up
ip link set dev gre0 master team0
ip link set dev team0 up
ping -I team0 1.1.1.1
Move team_dev_type_check_change down where all other checks have passed
as it changes the dev type with no way to restore it in case
one of the checks that follow it fail.
Also make sure to preserve the origial mtu assignment:
- If port_dev is not the same type as dev, dev takes mtu from port_dev
- If port_dev is the same type as dev, port_dev takes mtu from dev
This is done by adding a conditional before the call to dev_set_mtu
to prevent it from assigning port_dev->mtu = dev->mtu and instead
letting team_dev_type_check_change assign dev->mtu = port_dev->mtu.
The conditional is needed because the patch moves the call to
team_dev_type_check_change past dev_set_mtu.
Testing:
- team device driver in-tree selftests
- Add/remove various devices as slaves of team device
- syzbot |
| In the Linux kernel, the following vulnerability has been resolved:
atm/fore200e: Fix possible data race in fore200e_open()
Protect access to fore200e->available_cell_rate with rate_mtx lock in the
error handling path of fore200e_open() to prevent a data race.
The field fore200e->available_cell_rate is a shared resource used to track
available bandwidth. It is concurrently accessed by fore200e_open(),
fore200e_close(), and fore200e_change_qos().
In fore200e_open(), the lock rate_mtx is correctly held when subtracting
vcc->qos.txtp.max_pcr from available_cell_rate to reserve bandwidth.
However, if the subsequent call to fore200e_activate_vcin() fails, the
function restores the reserved bandwidth by adding back to
available_cell_rate without holding the lock.
This introduces a race condition because available_cell_rate is a global
device resource shared across all VCCs. If the error path in
fore200e_open() executes concurrently with operations like
fore200e_close() or fore200e_change_qos() on other VCCs, a
read-modify-write race occurs.
Specifically, the error path reads the rate without the lock. If another
CPU acquires the lock and modifies the rate (e.g., releasing bandwidth in
fore200e_close()) between this read and the subsequent write, the error
path will overwrite the concurrent update with a stale value. This results
in incorrect bandwidth accounting. |
| KEDA is a Kubernetes-based Event Driven Autoscaling component. Prior to versions 2.17.3 and 2.18.3, an Arbitrary File Read vulnerability has been identified in KEDA, potentially affecting any KEDA resource that uses TriggerAuthentication to configure HashiCorp Vault authentication. The vulnerability stems from an incorrect or insufficient path validation when loading the Service Account Token specified in spec.hashiCorpVault.credential.serviceAccount. An attacker with permissions to create or modify a TriggerAuthentication resource can exfiltrate the content of any file from the node's filesystem (where the KEDA pod resides) by directing the file's content to a server under their control, as part of the Vault authentication request. The potential impact includes the exfiltration of sensitive system information, such as secrets, keys, or the content of files like /etc/passwd. This issue has been patched in versions 2.17.3 and 2.18.3. |
| In the Linux kernel, the following vulnerability has been resolved:
usb: uas: fix urb unmapping issue when the uas device is remove during ongoing data transfer
When a UAS device is unplugged during data transfer, there is
a probability of a system panic occurring. The root cause is
an access to an invalid memory address during URB callback handling.
Specifically, this happens when the dma_direct_unmap_sg() function
is called within the usb_hcd_unmap_urb_for_dma() interface, but the
sg->dma_address field is 0 and the sg data structure has already been
freed.
The SCSI driver sends transfer commands by invoking uas_queuecommand_lck()
in uas.c, using the uas_submit_urbs() function to submit requests to USB.
Within the uas_submit_urbs() implementation, three URBs (sense_urb,
data_urb, and cmd_urb) are sequentially submitted. Device removal may
occur at any point during uas_submit_urbs execution, which may result
in URB submission failure. However, some URBs might have been successfully
submitted before the failure, and uas_submit_urbs will return the -ENODEV
error code in this case. The current error handling directly calls
scsi_done(). In the SCSI driver, this eventually triggers scsi_complete()
to invoke scsi_end_request() for releasing the sgtable. The successfully
submitted URBs, when being unlinked to giveback, call
usb_hcd_unmap_urb_for_dma() in hcd.c, leading to exceptions during sg
unmapping operations since the sg data structure has already been freed.
This patch modifies the error condition check in the uas_submit_urbs()
function. When a UAS device is removed but one or more URBs have already
been successfully submitted to USB, it avoids immediately invoking
scsi_done() and save the cmnd to devinfo->cmnd array. If the successfully
submitted URBs is completed before devinfo->resetting being set, then
the scsi_done() function will be called within uas_try_complete() after
all pending URB operations are finalized. Otherwise, the scsi_done()
function will be called within uas_zap_pending(), which is executed after
usb_kill_anchored_urbs().
The error handling only takes effect when uas_queuecommand_lck() calls
uas_submit_urbs() and returns the error value -ENODEV . In this case,
the device is disconnected, and the flow proceeds to uas_disconnect(),
where uas_zap_pending() is invoked to call uas_try_complete(). |
