Total
297034 CVE
| CVE | Vendors | Products | Updated | CVSS v2 | CVSS v3 |
|---|---|---|---|---|---|
| CVE-2025-22252 | 1 Fortinet | 3 Fortios, Fortiproxy, Fortiswitchmanager | 2025-06-04 | N/A | 9.8 CRITICAL |
| A missing authentication for critical function in Fortinet FortiProxy versions 7.6.0 through 7.6.1, FortiSwitchManager version 7.2.5, and FortiOS versions 7.4.4 through 7.4.6 and version 7.6.0 may allow an attacker with knowledge of an existing admin account to access the device as a valid admin via an authentication bypass. | |||||
| CVE-2024-54020 | 1 Fortinet | 1 Fortimanager | 2025-06-04 | N/A | 2.3 LOW |
| A missing authorization in Fortinet FortiManager versions 7.2.0 through 7.2.1, and versions 7.0.0 through 7.0.7 may allow an authenticated attacker to overwrite global threat feeds via crafted update requests. | |||||
| CVE-2025-25029 | 1 Ibm | 1 Security Guardium | 2025-06-04 | N/A | 4.9 MEDIUM |
| IBM Security Guardium 12.0 could allow a privileged user to download any file on the system due to improper escaping of input. | |||||
| CVE-2025-25026 | 1 Ibm | 1 Security Guardium | 2025-06-04 | N/A | 4.3 MEDIUM |
| IBM Security Guardium 12.0 could allow an authenticated user to obtain sensitive information due to an incorrect authentication check. | |||||
| CVE-2025-25025 | 1 Ibm | 1 Security Guardium | 2025-06-04 | N/A | 4.3 MEDIUM |
| IBM Security Guardium 12.0 could allow a remote attacker to obtain sensitive information when a detailed technical error message is returned in the browser. This information could be used in further attacks against the system. | |||||
| CVE-2025-48485 | 1 Freescout | 1 Freescout | 2025-06-04 | N/A | 5.4 MEDIUM |
| FreeScout is a free self-hosted help desk and shared mailbox. Prior to version 1.8.180, the application is vulnerable to Cross-Site Scripting (XSS) attacks due to incorrect input validation and sanitization of user-input data when an authenticated user updates the profile of an arbitrary customer. This issue has been patched in version 1.8.180. | |||||
| CVE-2025-5371 | 1 Razormist | 1 Health Center Patient Record Management System | 2025-06-04 | 7.5 HIGH | 7.3 HIGH |
| A vulnerability, which was classified as critical, has been found in SourceCodester Health Center Patient Record Management System 1.0. Affected by this issue is some unknown functionality of the file /admin/admin.php. The manipulation of the argument Username leads to sql injection. The attack may be launched remotely. The exploit has been disclosed to the public and may be used. | |||||
| CVE-2025-32598 | 1 Wptablebuilder | 1 Wp Table Builder | 2025-06-04 | N/A | 7.1 HIGH |
| Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting') vulnerability in WP Table Builder WP Table Builder allows Reflected XSS. This issue affects WP Table Builder: from n/a through 2.0.4. | |||||
| CVE-2025-30408 | 2025-06-04 | N/A | 6.7 MEDIUM | ||
| Local privilege escalation due to insecure folder permissions. The following products are affected: Acronis Cyber Protect Cloud Agent (Windows) before build 39904, Acronis Cyber Protect 16 (Windows) before build 39938. | |||||
| CVE-2024-55539 | 2025-06-04 | N/A | 2.5 LOW | ||
| Weak algorithm used to sign RPM package. The following products are affected: Acronis Cyber Protect Cloud Agent (Linux) before build 39185, Acronis Cyber Protect 16 (Linux) before build 39938. | |||||
| CVE-2023-48677 | 2025-06-04 | N/A | 7.8 HIGH | ||
| Local privilege escalation due to DLL hijacking vulnerability. The following products are affected: Acronis Cyber Protect Home Office (Windows) before build 40901, Acronis Cyber Protect Cloud Agent (Windows) before build 39378, Acronis Cyber Protect 16 (Windows) before build 39938. | |||||
| CVE-2025-22777 | 1 Givewp | 1 Givewp | 2025-06-04 | N/A | 9.8 CRITICAL |
| Deserialization of Untrusted Data vulnerability in GiveWP GiveWP allows Object Injection.This issue affects GiveWP: from n/a through 3.19.3. | |||||
| CVE-2025-37998 | 2025-06-04 | N/A | N/A | ||
| In the Linux kernel, the following vulnerability has been resolved: openvswitch: Fix unsafe attribute parsing in output_userspace() This patch replaces the manual Netlink attribute iteration in output_userspace() with nla_for_each_nested(), which ensures that only well-formed attributes are processed. | |||||
| CVE-2025-37997 | 2025-06-04 | N/A | N/A | ||
| In the Linux kernel, the following vulnerability has been resolved: netfilter: ipset: fix region locking in hash types Region locking introduced in v5.6-rc4 contained three macros to handle the region locks: ahash_bucket_start(), ahash_bucket_end() which gave back the start and end hash bucket values belonging to a given region lock and ahash_region() which should give back the region lock belonging to a given hash bucket. The latter was incorrect which can lead to a race condition between the garbage collector and adding new elements when a hash type of set is defined with timeouts. | |||||
| CVE-2025-37995 | 2025-06-04 | N/A | N/A | ||
| In the Linux kernel, the following vulnerability has been resolved: module: ensure that kobject_put() is safe for module type kobjects In 'lookup_or_create_module_kobject()', an internal kobject is created using 'module_ktype'. So call to 'kobject_put()' on error handling path causes an attempt to use an uninitialized completion pointer in 'module_kobject_release()'. In this scenario, we just want to release kobject without an extra synchronization required for a regular module unloading process, so adding an extra check whether 'complete()' is actually required makes 'kobject_put()' safe. | |||||
| CVE-2025-37994 | 2025-06-04 | N/A | N/A | ||
| In the Linux kernel, the following vulnerability has been resolved: usb: typec: ucsi: displayport: Fix NULL pointer access This patch ensures that the UCSI driver waits for all pending tasks in the ucsi_displayport_work workqueue to finish executing before proceeding with the partner removal. | |||||
| CVE-2025-37992 | 2025-06-04 | N/A | N/A | ||
| In the Linux kernel, the following vulnerability has been resolved: net_sched: Flush gso_skb list too during ->change() Previously, when reducing a qdisc's limit via the ->change() operation, only the main skb queue was trimmed, potentially leaving packets in the gso_skb list. This could result in NULL pointer dereference when we only check sch->limit against sch->q.qlen. This patch introduces a new helper, qdisc_dequeue_internal(), which ensures both the gso_skb list and the main queue are properly flushed when trimming excess packets. All relevant qdiscs (codel, fq, fq_codel, fq_pie, hhf, pie) are updated to use this helper in their ->change() routines. | |||||
| CVE-2025-37991 | 2025-06-04 | N/A | N/A | ||
| 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@parisc:~# strace -f ./a.out execve("./a.out", ["./a.out"], 0xf9ac7034 /* 20 vars */) = 0 getrlimit(RLIMIT_STACK, {rlim_cur=8192*1024, rlim_max=RLIM_INFINITY}) = 0 ... rt_sigaction(SIGFPE, {sa_handler=0x1110a, sa_mask=[], sa_flags=SA_RESTART|SA_SIGINFO}, NULL, 8) = 0 --- SIGFPE {si_signo=SIGFPE, si_code=FPE_FLTOVF, si_addr=0x1078f} --- --- SIGFPE {si_signo=SIGFPE, si_code=FPE_FLTOVF, si_addr=0xf8f21237} --- +++ killed by SIGFPE +++ Floating point exception | |||||
| CVE-2025-37990 | 2025-06-04 | N/A | N/A | ||
| 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. | |||||
| CVE-2025-37987 | 2025-06-04 | N/A | N/A | ||
| 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. | |||||