CyberAlerts is shutting down on June 30th, 2025. Thank you for your support!

Threat and Vulnerability Intelligence Database

Example Searches:

CVE-2025-44885	FW-WGS-804HPT v1.305b241111 was discovered to contain a stack overflow via the remote_ip parameter in the web_snmpv3_remote_engineId_add_post... Description: FW-WGS-804HPT v1.305b241111 was discovered to contain a stack overflow via the remote_ip parameter in the web_snmpv3_remote_engineId_add_post function. EPSS Score: 0.05% Source: CVE May 20th, 2025 (about 1 month ago)
	Mobile carrier Cellcom confirms cyberattack behind extended outages Description: Wisconsin wireless provider Cellcom has confirmed that a cyberattack is responsible for the widespread service outage and disruptions that began on the evening of May 14, 2025. [...] Source: BleepingComputer May 20th, 2025 (about 1 month ago)
	Premium WordPress 'Motors' theme vulnerable to admin takeover attacks Description: A critical privilege escalation vulnerability has been discovered in the premium WordPress theme Motors, which allows unauthenticated attackers to hijack administrator accounts and take complete control of websites. [...] Source: BleepingComputer May 20th, 2025 (about 1 month ago)
	🏴‍☠️ Kairos has just published a new victim : durhamarts.org Description: USA - Durham Arts Council Source: Ransomware.live May 20th, 2025 (about 1 month ago)
	VanHelsing ransomware builder leaked on hacking forum Description: The VanHelsing ransomware-as-a-service operation published the source code for its affiliate panel, data leak blog, and Windows encryptor builder after an old developer tried to sell it on the RAMP cybercrime forum. [...] Source: BleepingComputer May 20th, 2025 (about 1 month ago)
CVE-2025-37991	parisc: Fix double SIGFPE crash Description: In the Linux kernel, the following vulnerability has been resolved: parisc: Fix double SIGFPE crash Camm noticed that on parisc a SIGFPE exception will crash an application with a second SIGFPE in the signal handler. Dave analyzed it, and it happens because glibc uses a double-word floating-point store to atomically update function descriptors. As a result of lazy binding, we hit a floating-point store in fpe_func almost immediately. When the T bit is set, an assist exception trap occurs when when the co-processor encounters any floating-point instruction except for a double store of register %fr0. The latter cancels all pending traps. Let's fix this by clearing the Trap (T) bit in the FP status register before returning to the signal handler in userspace. The issue can be reproduced with this test program: root@parisc:~# cat fpe.c static void fpe_func(int sig, siginfo_t i, void v) { sigset_t set; sigemptyset(&set); sigaddset(&set, SIGFPE); sigprocmask(SIG_UNBLOCK, &set, NULL); printf("GOT signal %d with si_code %ld\n", sig, i->si_code); } int main() { struct sigaction action = { .sa_sigaction = fpe_func, .sa_flags = SA_RESTART\|SA_SIGINFO }; sigaction(SIGFPE, &action, 0); feenableexcept(FE_OVERFLOW); return printf("%lf\n",1.7976931348623158E308*1.7976931348623158E308); } root@parisc:~# gcc fpe.c -lm root@parisc:~# ./a.out Floating point exception root@pa... EPSS Score: 0.06% Source: CVE May 20th, 2025 (about 1 month ago)
CVE-2025-37990	wifi: brcm80211: fmac: Add error handling for brcmf_usb_dl_writeimage() Description: In the Linux kernel, the following vulnerability has been resolved: wifi: brcm80211: fmac: Add error handling for brcmf_usb_dl_writeimage() The function brcmf_usb_dl_writeimage() calls the function brcmf_usb_dl_cmd() but dose not check its return value. The 'state.state' and the 'state.bytes' are uninitialized if the function brcmf_usb_dl_cmd() fails. It is dangerous to use uninitialized variables in the conditions. Add error handling for brcmf_usb_dl_cmd() to jump to error handling path if the brcmf_usb_dl_cmd() fails and the 'state.state' and the 'state.bytes' are uninitialized. Improve the error message to report more detailed error information. EPSS Score: 0.06% Source: CVE May 20th, 2025 (about 1 month ago)
CVE-2025-37989	net: phy: leds: fix memory leak Description: In the Linux kernel, the following vulnerability has been resolved: net: phy: leds: fix memory leak A network restart test on a router led to an out-of-memory condition, which was traced to a memory leak in the PHY LED trigger code. The root cause is misuse of the devm API. The registration function (phy_led_triggers_register) is called from phy_attach_direct, not phy_probe, and the unregister function (phy_led_triggers_unregister) is called from phy_detach, not phy_remove. This means the register and unregister functions can be called multiple times for the same PHY device, but devm-allocated memory is not freed until the driver is unbound. This also prevents kmemleak from detecting the leak, as the devm API internally stores the allocated pointer. Fix this by replacing devm_kzalloc/devm_kcalloc with standard kzalloc/kcalloc, and add the corresponding kfree calls in the unregister path. EPSS Score: 0.03% Source: CVE May 20th, 2025 (about 1 month ago)
CVE-2025-37988	fix a couple of races in MNT_TREE_BENEATH handling by do_move_mount() Description: In the Linux kernel, the following vulnerability has been resolved: fix a couple of races in MNT_TREE_BENEATH handling by do_move_mount() Normally do_lock_mount(path, _) is locking a mountpoint pinned by path and at the time when matching unlock_mount() unlocks that location it is still pinned by the same thing. Unfortunately, for 'beneath' case it's no longer that simple - the object being locked is not the one path points to. It's the mountpoint of path->mnt. The thing is, without sufficient locking ->mnt_parent may change under us and none of the locks are held at that point. The rules are * mount_lock stabilizes m->mnt_parent for any mount m. * namespace_sem stabilizes m->mnt_parent, provided that m is mounted. * if either of the above holds and refcount of m is positive, we are guaranteed the same for refcount of m->mnt_parent. namespace_sem nests inside inode_lock(), so do_lock_mount() has to take inode_lock() before grabbing namespace_sem. It does recheck that path->mnt is still mounted in the same place after getting namespace_sem, and it does take care to pin the dentry. It is needed, since otherwise we might end up with racing mount --move (or umount) happening while we were getting locks; in that case dentry would no longer be a mountpoint and could've been evicted on memory pressure along with its inode - not something you want when grabbing lock on that inode. However, pinning a dentry is not enough - the matching mount is also pinned only by the... EPSS Score: 0.02% Source: CVE May 20th, 2025 (about 1 month ago)
CVE-2025-37987	pds_core: Prevent possible adminq overflow/stuck condition Description: In the Linux kernel, the following vulnerability has been resolved: pds_core: Prevent possible adminq overflow/stuck condition The pds_core's adminq is protected by the adminq_lock, which prevents more than 1 command to be posted onto it at any one time. This makes it so the client drivers cannot simultaneously post adminq commands. However, the completions happen in a different context, which means multiple adminq commands can be posted sequentially and all waiting on completion. On the FW side, the backing adminq request queue is only 16 entries long and the retry mechanism and/or overflow/stuck prevention is lacking. This can cause the adminq to get stuck, so commands are no longer processed and completions are no longer sent by the FW. As an initial fix, prevent more than 16 outstanding adminq commands so there's no way to cause the adminq from getting stuck. This works because the backing adminq request queue will never have more than 16 pending adminq commands, so it will never overflow. This is done by reducing the adminq depth to 16. EPSS Score: 0.02% Source: CVE May 20th, 2025 (about 1 month ago)