π¨ CVE-2025-38209
In the Linux kernel, the following vulnerability has been resolved:
nvme-tcp: remove tag set when second admin queue config fails
Commit 104d0e2f6222 ("nvme-fabrics: reset admin connection for secure
concatenation") modified nvme_tcp_setup_ctrl() to call
nvme_tcp_configure_admin_queue() twice. The first call prepares for
DH-CHAP negotitation, and the second call is required for secure
concatenation. However, this change triggered BUG KASAN slab-use-after-
free in blk_mq_queue_tag_busy_iter(). This BUG can be recreated by
repeating the blktests test case nvme/063 a few times [1].
When the BUG happens, nvme_tcp_create_ctrl() fails in the call chain
below:
nvme_tcp_create_ctrl()
nvme_tcp_alloc_ctrl() new=true ... Alloc nvme_tcp_ctrl and admin_tag_set
nvme_tcp_setup_ctrl() new=true
nvme_tcp_configure_admin_queue() new=true ... Succeed
nvme_alloc_admin_tag_set() ... Alloc the tag set for admin_tag_set
nvme_stop_keep_alive()
nvme_tcp_teardown_admin_queue() remove=false
nvme_tcp_configure_admin_queue() new=false
nvme_tcp_alloc_admin_queue() ... Fail, but do not call nvme_remove_admin_tag_set()
nvme_uninit_ctrl()
nvme_put_ctrl() ... Free up the nvme_tcp_ctrl and admin_tag_set
The first call of nvme_tcp_configure_admin_queue() succeeds with
new=true argument. The second call fails with new=false argument. This
second call does not call nvme_remove_admin_tag_set() on failure, due to
the new=false argument. Then the admin tag set is not removed. However,
nvme_tcp_create_ctrl() assumes that nvme_tcp_setup_ctrl() would call
nvme_remove_admin_tag_set(). Then it frees up struct nvme_tcp_ctrl which
has admin_tag_set field. Later on, the timeout handler accesses the
admin_tag_set field and causes the BUG KASAN slab-use-after-free.
To not leave the admin tag set, call nvme_remove_admin_tag_set() when
the second nvme_tcp_configure_admin_queue() call fails. Do not return
from nvme_tcp_setup_ctrl() on failure. Instead, jump to "destroy_admin"
go-to label to call nvme_tcp_teardown_admin_queue() which calls
nvme_remove_admin_tag_set().
π@cveNotify
In the Linux kernel, the following vulnerability has been resolved:
nvme-tcp: remove tag set when second admin queue config fails
Commit 104d0e2f6222 ("nvme-fabrics: reset admin connection for secure
concatenation") modified nvme_tcp_setup_ctrl() to call
nvme_tcp_configure_admin_queue() twice. The first call prepares for
DH-CHAP negotitation, and the second call is required for secure
concatenation. However, this change triggered BUG KASAN slab-use-after-
free in blk_mq_queue_tag_busy_iter(). This BUG can be recreated by
repeating the blktests test case nvme/063 a few times [1].
When the BUG happens, nvme_tcp_create_ctrl() fails in the call chain
below:
nvme_tcp_create_ctrl()
nvme_tcp_alloc_ctrl() new=true ... Alloc nvme_tcp_ctrl and admin_tag_set
nvme_tcp_setup_ctrl() new=true
nvme_tcp_configure_admin_queue() new=true ... Succeed
nvme_alloc_admin_tag_set() ... Alloc the tag set for admin_tag_set
nvme_stop_keep_alive()
nvme_tcp_teardown_admin_queue() remove=false
nvme_tcp_configure_admin_queue() new=false
nvme_tcp_alloc_admin_queue() ... Fail, but do not call nvme_remove_admin_tag_set()
nvme_uninit_ctrl()
nvme_put_ctrl() ... Free up the nvme_tcp_ctrl and admin_tag_set
The first call of nvme_tcp_configure_admin_queue() succeeds with
new=true argument. The second call fails with new=false argument. This
second call does not call nvme_remove_admin_tag_set() on failure, due to
the new=false argument. Then the admin tag set is not removed. However,
nvme_tcp_create_ctrl() assumes that nvme_tcp_setup_ctrl() would call
nvme_remove_admin_tag_set(). Then it frees up struct nvme_tcp_ctrl which
has admin_tag_set field. Later on, the timeout handler accesses the
admin_tag_set field and causes the BUG KASAN slab-use-after-free.
To not leave the admin tag set, call nvme_remove_admin_tag_set() when
the second nvme_tcp_configure_admin_queue() call fails. Do not return
from nvme_tcp_setup_ctrl() on failure. Instead, jump to "destroy_admin"
go-to label to call nvme_tcp_teardown_admin_queue() which calls
nvme_remove_admin_tag_set().
π@cveNotify
π₯1
π¨ CVE-2018-4878
A use-after-free vulnerability was discovered in Adobe Flash Player before 28.0.0.161. This vulnerability occurs due to a dangling pointer in the Primetime SDK related to media player handling of listener objects. A successful attack can lead to arbitrary code execution. This was exploited in the wild in January and February 2018.
π@cveNotify
A use-after-free vulnerability was discovered in Adobe Flash Player before 28.0.0.161. This vulnerability occurs due to a dangling pointer in the Primetime SDK related to media player handling of listener objects. A successful attack can lead to arbitrary code execution. This was exploited in the wild in January and February 2018.
π@cveNotify
Cisco Talos
Flash 0-Day In The Wild: Group 123 At The Controls
This blog post is authored by Warren Mercer and Paul Rascagneres. Executive Summary The 1st of February, Adobe published an advisory concerning a Flash vulnerability (CVE-2018-4878). This vulnerability is a use after free that allows Remote Code Execute throughβ¦
π¨ CVE-2018-5002
Adobe Flash Player versions 29.0.0.171 and earlier have a Stack-based buffer overflow vulnerability. Successful exploitation could lead to arbitrary code execution in the context of the current user.
π@cveNotify
Adobe Flash Player versions 29.0.0.171 and earlier have a Stack-based buffer overflow vulnerability. Successful exploitation could lead to arbitrary code execution in the context of the current user.
π@cveNotify
π¨ CVE-2024-25189
libjwt 1.15.3 uses strcmp (which is not constant time) to verify authentication, which makes it easier to bypass authentication via a timing side channel.
π@cveNotify
libjwt 1.15.3 uses strcmp (which is not constant time) to verify authentication, which makes it easier to bypass authentication via a timing side channel.
π@cveNotify
GitHub
CVE_Request/benmcollins:libjwt.md at main Β· P3ngu1nW/CVE_Request
Contribute to P3ngu1nW/CVE_Request development by creating an account on GitHub.
π¨ CVE-2024-32122
A storing passwords in a recoverable format in Fortinet FortiOS 7.4.0 through 7.4.8, FortiOS 7.2 all versions, FortiOS 7.0 all versions, FortiOS 6.4 all versions allows attacker to information disclosure via modification of LDAP server IP to point to a malicious server.
π@cveNotify
A storing passwords in a recoverable format in Fortinet FortiOS 7.4.0 through 7.4.8, FortiOS 7.2 all versions, FortiOS 7.0 all versions, FortiOS 6.4 all versions allows attacker to information disclosure via modification of LDAP server IP to point to a malicious server.
π@cveNotify
FortiGuard Labs
PSIRT | FortiGuard Labs
None
π¨ CVE-2025-5552
A vulnerability was found in ChestnutCMS up to 15.1. It has been declared as critical. This vulnerability affects unknown code of the file /dev-api/groovy/exec of the component API Endpoint. The manipulation leads to deserialization. The attack can be initiated remotely. The exploit has been disclosed to the public and may be used.
π@cveNotify
A vulnerability was found in ChestnutCMS up to 15.1. It has been declared as critical. This vulnerability affects unknown code of the file /dev-api/groovy/exec of the component API Endpoint. The manipulation leads to deserialization. The attack can be initiated remotely. The exploit has been disclosed to the public and may be used.
π@cveNotify
GitHub
ChestnutCMS <=15.1 arbitrary code execution Β· Issue #7 Β· byxs0x0/cve
Vulnerability version: ChestnutCMS <= 15.1 Product supplier: https://gitee.com/liweiyi/ChestnutCMS Vulnerability type: Any code execution Vulnerability description: ChestnutCMS is an enterprise-...
π¨ CVE-2025-38196
In the Linux kernel, the following vulnerability has been resolved:
io_uring/rsrc: validate buffer count with offset for cloning
syzbot reports that it can trigger a WARN_ON() for kmalloc() attempt
that's too big:
WARNING: CPU: 0 PID: 6488 at mm/slub.c:5024 __kvmalloc_node_noprof+0x520/0x640 mm/slub.c:5024
Modules linked in:
CPU: 0 UID: 0 PID: 6488 Comm: syz-executor312 Not tainted 6.15.0-rc7-syzkaller-gd7fa1af5b33e #0 PREEMPT
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/07/2025
pstate: 20400005 (nzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
pc : __kvmalloc_node_noprof+0x520/0x640 mm/slub.c:5024
lr : __do_kmalloc_node mm/slub.c:-1 [inline]
lr : __kvmalloc_node_noprof+0x3b4/0x640 mm/slub.c:5012
sp : ffff80009cfd7a90
x29: ffff80009cfd7ac0 x28: ffff0000dd52a120 x27: 0000000000412dc0
x26: 0000000000000178 x25: ffff7000139faf70 x24: 0000000000000000
x23: ffff800082f4cea8 x22: 00000000ffffffff x21: 000000010cd004a8
x20: ffff0000d75816c0 x19: ffff0000dd52a000 x18: 00000000ffffffff
x17: ffff800092f39000 x16: ffff80008adbe9e4 x15: 0000000000000005
x14: 1ffff000139faf1c x13: 0000000000000000 x12: 0000000000000000
x11: ffff7000139faf21 x10: 0000000000000003 x9 : ffff80008f27b938
x8 : 0000000000000002 x7 : 0000000000000000 x6 : 0000000000000000
x5 : 00000000ffffffff x4 : 0000000000400dc0 x3 : 0000000200000000
x2 : 000000010cd004a8 x1 : ffff80008b3ebc40 x0 : 0000000000000001
Call trace:
__kvmalloc_node_noprof+0x520/0x640 mm/slub.c:5024 (P)
kvmalloc_array_node_noprof include/linux/slab.h:1065 [inline]
io_rsrc_data_alloc io_uring/rsrc.c:206 [inline]
io_clone_buffers io_uring/rsrc.c:1178 [inline]
io_register_clone_buffers+0x484/0xa14 io_uring/rsrc.c:1287
__io_uring_register io_uring/register.c:815 [inline]
__do_sys_io_uring_register io_uring/register.c:926 [inline]
__se_sys_io_uring_register io_uring/register.c:903 [inline]
__arm64_sys_io_uring_register+0x42c/0xea8 io_uring/register.c:903
__invoke_syscall arch/arm64/kernel/syscall.c:35 [inline]
invoke_syscall+0x98/0x2b8 arch/arm64/kernel/syscall.c:49
el0_svc_common+0x130/0x23c arch/arm64/kernel/syscall.c:132
do_el0_svc+0x48/0x58 arch/arm64/kernel/syscall.c:151
el0_svc+0x58/0x17c arch/arm64/kernel/entry-common.c:767
el0t_64_sync_handler+0x78/0x108 arch/arm64/kernel/entry-common.c:786
el0t_64_sync+0x198/0x19c arch/arm64/kernel/entry.S:600
which is due to offset + buffer_count being too large. The registration
code checks only the total count of buffers, but given that the indexing
is an array, it should also check offset + count. That can't exceed
IORING_MAX_REG_BUFFERS either, as there's no way to reach buffers beyond
that limit.
There's no issue with registrering a table this large, outside of the
fact that it's pointless to register buffers that cannot be reached, and
that it can trigger this kmalloc() warning for attempting an allocation
that is too large.
π@cveNotify
In the Linux kernel, the following vulnerability has been resolved:
io_uring/rsrc: validate buffer count with offset for cloning
syzbot reports that it can trigger a WARN_ON() for kmalloc() attempt
that's too big:
WARNING: CPU: 0 PID: 6488 at mm/slub.c:5024 __kvmalloc_node_noprof+0x520/0x640 mm/slub.c:5024
Modules linked in:
CPU: 0 UID: 0 PID: 6488 Comm: syz-executor312 Not tainted 6.15.0-rc7-syzkaller-gd7fa1af5b33e #0 PREEMPT
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/07/2025
pstate: 20400005 (nzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
pc : __kvmalloc_node_noprof+0x520/0x640 mm/slub.c:5024
lr : __do_kmalloc_node mm/slub.c:-1 [inline]
lr : __kvmalloc_node_noprof+0x3b4/0x640 mm/slub.c:5012
sp : ffff80009cfd7a90
x29: ffff80009cfd7ac0 x28: ffff0000dd52a120 x27: 0000000000412dc0
x26: 0000000000000178 x25: ffff7000139faf70 x24: 0000000000000000
x23: ffff800082f4cea8 x22: 00000000ffffffff x21: 000000010cd004a8
x20: ffff0000d75816c0 x19: ffff0000dd52a000 x18: 00000000ffffffff
x17: ffff800092f39000 x16: ffff80008adbe9e4 x15: 0000000000000005
x14: 1ffff000139faf1c x13: 0000000000000000 x12: 0000000000000000
x11: ffff7000139faf21 x10: 0000000000000003 x9 : ffff80008f27b938
x8 : 0000000000000002 x7 : 0000000000000000 x6 : 0000000000000000
x5 : 00000000ffffffff x4 : 0000000000400dc0 x3 : 0000000200000000
x2 : 000000010cd004a8 x1 : ffff80008b3ebc40 x0 : 0000000000000001
Call trace:
__kvmalloc_node_noprof+0x520/0x640 mm/slub.c:5024 (P)
kvmalloc_array_node_noprof include/linux/slab.h:1065 [inline]
io_rsrc_data_alloc io_uring/rsrc.c:206 [inline]
io_clone_buffers io_uring/rsrc.c:1178 [inline]
io_register_clone_buffers+0x484/0xa14 io_uring/rsrc.c:1287
__io_uring_register io_uring/register.c:815 [inline]
__do_sys_io_uring_register io_uring/register.c:926 [inline]
__se_sys_io_uring_register io_uring/register.c:903 [inline]
__arm64_sys_io_uring_register+0x42c/0xea8 io_uring/register.c:903
__invoke_syscall arch/arm64/kernel/syscall.c:35 [inline]
invoke_syscall+0x98/0x2b8 arch/arm64/kernel/syscall.c:49
el0_svc_common+0x130/0x23c arch/arm64/kernel/syscall.c:132
do_el0_svc+0x48/0x58 arch/arm64/kernel/syscall.c:151
el0_svc+0x58/0x17c arch/arm64/kernel/entry-common.c:767
el0t_64_sync_handler+0x78/0x108 arch/arm64/kernel/entry-common.c:786
el0t_64_sync+0x198/0x19c arch/arm64/kernel/entry.S:600
which is due to offset + buffer_count being too large. The registration
code checks only the total count of buffers, but given that the indexing
is an array, it should also check offset + count. That can't exceed
IORING_MAX_REG_BUFFERS either, as there's no way to reach buffers beyond
that limit.
There's no issue with registrering a table this large, outside of the
fact that it's pointless to register buffers that cannot be reached, and
that it can trigger this kmalloc() warning for attempting an allocation
that is too large.
π@cveNotify
π¨ CVE-2025-38199
In the Linux kernel, the following vulnerability has been resolved:
wifi: ath12k: Fix memory leak due to multiple rx_stats allocation
rx_stats for each arsta is allocated when adding a station.
arsta->rx_stats will be freed when a station is removed.
Redundant allocations are occurring when the same station is added
multiple times. This causes ath12k_mac_station_add() to be called
multiple times, and rx_stats is allocated each time. As a result there
is memory leaks.
Prevent multiple allocations of rx_stats when ath12k_mac_station_add()
is called repeatedly by checking if rx_stats is already allocated
before allocating again. Allocate arsta->rx_stats if arsta->rx_stats
is NULL respectively.
Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.3.1-00173-QCAHKSWPL_SILICONZ-1
Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.0.c5-00481-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3
π@cveNotify
In the Linux kernel, the following vulnerability has been resolved:
wifi: ath12k: Fix memory leak due to multiple rx_stats allocation
rx_stats for each arsta is allocated when adding a station.
arsta->rx_stats will be freed when a station is removed.
Redundant allocations are occurring when the same station is added
multiple times. This causes ath12k_mac_station_add() to be called
multiple times, and rx_stats is allocated each time. As a result there
is memory leaks.
Prevent multiple allocations of rx_stats when ath12k_mac_station_add()
is called repeatedly by checking if rx_stats is already allocated
before allocating again. Allocate arsta->rx_stats if arsta->rx_stats
is NULL respectively.
Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.3.1-00173-QCAHKSWPL_SILICONZ-1
Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.0.c5-00481-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3
π@cveNotify
π¨ CVE-2025-38201
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nft_set_pipapo: clamp maximum map bucket size to INT_MAX
Otherwise, it is possible to hit WARN_ON_ONCE in __kvmalloc_node_noprof()
when resizing hashtable because __GFP_NOWARN is unset.
Similar to:
b541ba7d1f5a ("netfilter: conntrack: clamp maximum hashtable size to INT_MAX")
π@cveNotify
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nft_set_pipapo: clamp maximum map bucket size to INT_MAX
Otherwise, it is possible to hit WARN_ON_ONCE in __kvmalloc_node_noprof()
when resizing hashtable because __GFP_NOWARN is unset.
Similar to:
b541ba7d1f5a ("netfilter: conntrack: clamp maximum hashtable size to INT_MAX")
π@cveNotify
π¨ CVE-2025-38205
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Avoid divide by zero by initializing dummy pitch to 1
[Why]
If the dummy values in `populate_dummy_dml_surface_cfg()` aren't updated
then they can lead to a divide by zero in downstream callers like
CalculateVMAndRowBytes()
[How]
Initialize dummy value to a value to avoid divide by zero.
π@cveNotify
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Avoid divide by zero by initializing dummy pitch to 1
[Why]
If the dummy values in `populate_dummy_dml_surface_cfg()` aren't updated
then they can lead to a divide by zero in downstream callers like
CalculateVMAndRowBytes()
[How]
Initialize dummy value to a value to avoid divide by zero.
π@cveNotify
π¨ CVE-2025-38207
In the Linux kernel, the following vulnerability has been resolved:
mm: fix uprobe pte be overwritten when expanding vma
Patch series "Fix uprobe pte be overwritten when expanding vma".
This patch (of 4):
We encountered a BUG alert triggered by Syzkaller as follows:
BUG: Bad rss-counter state mm:00000000b4a60fca type:MM_ANONPAGES val:1
And we can reproduce it with the following steps:
1. register uprobe on file at zero offset
2. mmap the file at zero offset:
addr1 = mmap(NULL, 2 * 4096, PROT_NONE, MAP_PRIVATE, fd, 0);
3. mremap part of vma1 to new vma2:
addr2 = mremap(addr1, 4096, 2 * 4096, MREMAP_MAYMOVE);
4. mremap back to orig addr1:
mremap(addr2, 4096, 4096, MREMAP_MAYMOVE | MREMAP_FIXED, addr1);
In step 3, the vma1 range [addr1, addr1 + 4096] will be remap to new vma2
with range [addr2, addr2 + 8192], and remap uprobe anon page from the vma1
to vma2, then unmap the vma1 range [addr1, addr1 + 4096].
In step 4, the vma2 range [addr2, addr2 + 4096] will be remap back to the
addr range [addr1, addr1 + 4096]. Since the addr range [addr1 + 4096,
addr1 + 8192] still maps the file, it will take vma_merge_new_range to
expand the range, and then do uprobe_mmap in vma_complete. Since the
merged vma pgoff is also zero offset, it will install uprobe anon page to
the merged vma. However, the upcomming move_page_tables step, which use
set_pte_at to remap the vma2 uprobe pte to the merged vma, will overwrite
the newly uprobe pte in the merged vma, and lead that pte to be orphan.
Since the uprobe pte will be remapped to the merged vma, we can remove the
unnecessary uprobe_mmap upon merged vma.
This problem was first found in linux-6.6.y and also exists in the
community syzkaller:
https://lore.kernel.org/all/000000000000ada39605a5e71711@google.com/T/
π@cveNotify
In the Linux kernel, the following vulnerability has been resolved:
mm: fix uprobe pte be overwritten when expanding vma
Patch series "Fix uprobe pte be overwritten when expanding vma".
This patch (of 4):
We encountered a BUG alert triggered by Syzkaller as follows:
BUG: Bad rss-counter state mm:00000000b4a60fca type:MM_ANONPAGES val:1
And we can reproduce it with the following steps:
1. register uprobe on file at zero offset
2. mmap the file at zero offset:
addr1 = mmap(NULL, 2 * 4096, PROT_NONE, MAP_PRIVATE, fd, 0);
3. mremap part of vma1 to new vma2:
addr2 = mremap(addr1, 4096, 2 * 4096, MREMAP_MAYMOVE);
4. mremap back to orig addr1:
mremap(addr2, 4096, 4096, MREMAP_MAYMOVE | MREMAP_FIXED, addr1);
In step 3, the vma1 range [addr1, addr1 + 4096] will be remap to new vma2
with range [addr2, addr2 + 8192], and remap uprobe anon page from the vma1
to vma2, then unmap the vma1 range [addr1, addr1 + 4096].
In step 4, the vma2 range [addr2, addr2 + 4096] will be remap back to the
addr range [addr1, addr1 + 4096]. Since the addr range [addr1 + 4096,
addr1 + 8192] still maps the file, it will take vma_merge_new_range to
expand the range, and then do uprobe_mmap in vma_complete. Since the
merged vma pgoff is also zero offset, it will install uprobe anon page to
the merged vma. However, the upcomming move_page_tables step, which use
set_pte_at to remap the vma2 uprobe pte to the merged vma, will overwrite
the newly uprobe pte in the merged vma, and lead that pte to be orphan.
Since the uprobe pte will be remapped to the merged vma, we can remove the
unnecessary uprobe_mmap upon merged vma.
This problem was first found in linux-6.6.y and also exists in the
community syzkaller:
https://lore.kernel.org/all/000000000000ada39605a5e71711@google.com/T/
π@cveNotify
π¨ CVE-2025-24990
Microsoft is aware of vulnerabilities in the third party Agere Modem driver that ships natively with supported Windows operating systems. This is an announcement of the upcoming removal of ltmdm64.sys driver. The driver has been removed in the October cumulative update.
Fax modem hardware dependent on this specific driver will no longer work on Windows.
Microsoft recommends removing any existing dependencies on this hardware.
π@cveNotify
Microsoft is aware of vulnerabilities in the third party Agere Modem driver that ships natively with supported Windows operating systems. This is an announcement of the upcoming removal of ltmdm64.sys driver. The driver has been removed in the October cumulative update.
Fax modem hardware dependent on this specific driver will no longer work on Windows.
Microsoft recommends removing any existing dependencies on this hardware.
π@cveNotify
π¨ CVE-2025-63709
A Cross-Site Scripting (XSS) vulnerability exists in SourceCodester Simple To-Do List System 1.0 in the "Add Tasks" text input. An authenticated user can submit HTML/JavaScript that is not correctly sanitized or encoded on output. The injected script is stored and later rendered in the browser of any user who views the task, allowing execution of arbitrary script in the context of the victim's browser.
π@cveNotify
A Cross-Site Scripting (XSS) vulnerability exists in SourceCodester Simple To-Do List System 1.0 in the "Add Tasks" text input. An authenticated user can submit HTML/JavaScript that is not correctly sanitized or encoded on output. The injected script is stored and later rendered in the browser of any user who views the task, allowing execution of arbitrary script in the context of the victim's browser.
π@cveNotify
GitHub
CVE-Research-2025/CVE-2025-63709 at main Β· floccocam-cpu/CVE-Research-2025
Contribute to floccocam-cpu/CVE-Research-2025 development by creating an account on GitHub.
π¨ CVE-2025-63712
Cross-Site Request Forgery (CSRF) in SourceCodester Product Expiry Management System. The User Management module (delete-user.php) allows remote attackers to delete arbitrary user accounts via forged cross-origin GET requests because the endpoint relies solely on session cookies and lacks CSRF protection.
π@cveNotify
Cross-Site Request Forgery (CSRF) in SourceCodester Product Expiry Management System. The User Management module (delete-user.php) allows remote attackers to delete arbitrary user accounts via forged cross-origin GET requests because the endpoint relies solely on session cookies and lacks CSRF protection.
π@cveNotify
GitHub
CVE-Research-2025/CVE-2025-63712/README4.md at main Β· floccocam-cpu/CVE-Research-2025
Contribute to floccocam-cpu/CVE-Research-2025 development by creating an account on GitHub.
π¨ CVE-2025-63147
Tenda AX3 V16.03.12.10_CN was discovered to contain a stack overflow in the deviceId parameter of the saveParentControlInfo function. This vulnerability allows attackers to cause a Denial of Service (DoS) via a crafted request.
π@cveNotify
Tenda AX3 V16.03.12.10_CN was discovered to contain a stack overflow in the deviceId parameter of the saveParentControlInfo function. This vulnerability allows attackers to cause a Denial of Service (DoS) via a crafted request.
π@cveNotify
GitHub
VulnbyCola/Tenda/AX-3/5/1.md at main Β· 0-fool/VulnbyCola
Contribute to 0-fool/VulnbyCola development by creating an account on GitHub.
π¨ CVE-2025-63456
Tenda AX-1803 v1.0.0.1 was discovered to contain a stack overflow via the time parameter in the SetSysTimeCfg function. This vulnerability allows attackers to cause a Denial of Service (DoS) via a crafted request.
π@cveNotify
Tenda AX-1803 v1.0.0.1 was discovered to contain a stack overflow via the time parameter in the SetSysTimeCfg function. This vulnerability allows attackers to cause a Denial of Service (DoS) via a crafted request.
π@cveNotify
GitHub
VulnbyCola/Tenda/AX-1803/3/1.md at main Β· 0-fool/VulnbyCola
Contribute to 0-fool/VulnbyCola development by creating an account on GitHub.
π¨ CVE-2025-63457
Tenda AX-1803 v1.0.0.1 was discovered to contain a stack overflow via the wanMTU parameter in the sub_4F55C function. This vulnerability allows attackers to cause a Denial of Service (DoS) via a crafted request.
π@cveNotify
Tenda AX-1803 v1.0.0.1 was discovered to contain a stack overflow via the wanMTU parameter in the sub_4F55C function. This vulnerability allows attackers to cause a Denial of Service (DoS) via a crafted request.
π@cveNotify
GitHub
VulnbyCola/Tenda/AX-1803/1/1.md at main Β· 0-fool/VulnbyCola
Contribute to 0-fool/VulnbyCola development by creating an account on GitHub.
π¨ CVE-2025-63834
A stored cross-site scripting (XSS) vulnerability was discovered in Tenda AC18 v15.03.05.05_multi. The vulnerability exists in the ssid parameter of the wireless settings. Remote attackers can inject malicious payloads that execute when any user visits the router's homepage.
π@cveNotify
A stored cross-site scripting (XSS) vulnerability was discovered in Tenda AC18 v15.03.05.05_multi. The vulnerability exists in the ssid parameter of the wireless settings. Remote attackers can inject malicious payloads that execute when any user visits the router's homepage.
π@cveNotify
GitHub
cve_report/cve_report/tenda/tendaAC18/wifiset_ssid_xss/README.md at main Β· babraink/cve_report
δΈζ₯cveζΌζ΄δ»εΊ. Contribute to babraink/cve_report development by creating an account on GitHub.
π¨ CVE-2025-63835
A stack-based buffer overflow vulnerability was discovered in Tenda AC18 v15.03.05.05_multi. The vulnerability exists in the guestSsid parameter of the /goform/WifiGuestSet interface. Remote attackers can exploit this vulnerability by sending oversized data to the guestSsid parameter, leading to denial of service (device crash) or potential remote code execution.
π@cveNotify
A stack-based buffer overflow vulnerability was discovered in Tenda AC18 v15.03.05.05_multi. The vulnerability exists in the guestSsid parameter of the /goform/WifiGuestSet interface. Remote attackers can exploit this vulnerability by sending oversized data to the guestSsid parameter, leading to denial of service (device crash) or potential remote code execution.
π@cveNotify
GitHub
cve_report/cve_report/tenda/tendaAC18/2_wifiguest_guestssid_overflow/README.md at main Β· babraink/cve_report
δΈζ₯cveζΌζ΄δ»εΊ. Contribute to babraink/cve_report development by creating an account on GitHub.
π¨ CVE-2016-15056
Ubee EVW3226 cable modem/routers firmware versions up to and including 1.0.20 store configuration backup files in the web root after they are generated for download. These backup files remain accessible without authentication until the next reboot. A remote attacker on the local network can request 'Configuration_file.cfg' directly to obtain the backup archive. Because backup files are not encrypted, they expose sensitive information including the plaintext admin password, allowing full compromise of the device.
π@cveNotify
Ubee EVW3226 cable modem/routers firmware versions up to and including 1.0.20 store configuration backup files in the web root after they are generated for download. These backup files remain accessible without authentication until the next reboot. A remote attacker on the local network can request 'Configuration_file.cfg' directly to obtain the backup archive. Because backup files are not encrypted, they expose sensitive information including the plaintext admin password, allowing full compromise of the device.
π@cveNotify
seclists.org
Full Disclosure: [SEARCH-LAB advisory] Ubee EVW3226 modem/router multiple vulnerabilities
π¨ CVE-2021-4465
ReQuest Serious Play F3 Media Server versions 7.0.3.4968 (Pro), 7.0.2.4954, 6.5.2.4954, 6.4.2.4681, 6.3.2.4203, and 2.0.1.823 contain a remote denial-of-service vulnerability. The device can be shut down or rebooted by an unauthenticated attacker through a single crafted HTTP GET request, allowing remote interruption of service availability.
π@cveNotify
ReQuest Serious Play F3 Media Server versions 7.0.3.4968 (Pro), 7.0.2.4954, 6.5.2.4954, 6.4.2.4681, 6.3.2.4203, and 2.0.1.823 contain a remote denial-of-service vulnerability. The device can be shut down or rebooted by an unauthenticated attacker through a single crafted HTTP GET request, allowing remote interruption of service availability.
π@cveNotify
Request
[AWS] ReQuest Serious Play: Premium Multi-room Music and Movie Solutions
ReQuest: premium whole-house music and video entertainment systems for the home, office or yacht. Built-in integration with iTunes, multi-location sync, and anywhere streaming.