CVE Watch363,850 in full archive

Vulnerabilities exploitable today

363,850in current view

Single score combining CVSS, KEV membership and EPSS. Every CVE with its own record — timeline from publication to active exploitation.

In KEV catalog1,673

New KEV · 24H0

Exploit Today ≥ 701,611

Distribution · last window

Critical
2,926
High
12,038
Medium
7,391
Low
695

Filters

Window

Severity

Flags

Vulnerabilities316,281–316,320 · 363,850

CVECVSSEPSSKEVRExploitTitleMod.

CVE-2024-49349—

12.9%

——4——CVE-2026-654785.4 MED

12.9%

——4Subscriber Broken Access Control in ListingPro <= 2.9.10 versions.29d CVE-2025-66137—

——4——CVE-2025-121316.5 MED

12.9%

——4A truncated 802.15.4 packet can lead to an assert, resulting in a denial of service.22h CVE-2024-54430—

12.9%

——4——CVE-2024-42161—

12.9%

——4——CVE-2026-572658.3 HIG

12.9%

——4GeoWebPlayer (also called "Web Plugin" in the GV-VMS documentation and "WS Player" for VMS-Cloud) is an addon that can be installed with various GeoVision software (GV-VMS, GV-Cloud, ...). It creates a websocket server that expands the capabilities of the various web-interfaces provided by the GeoVision software and may be necessary for them to function properly. The Websocket server can accept various commands coming from localhost. Many of the commands will take an `index` value that is then used to access various arrays to enter critical sections, perform various actions via function calls, etc. However the `index` value is usually not checked for valid range, and as such it can be used to access multiple arrays out-of-bound. #### audio command index-out-of-bound50d CVE-2026-131328.3 HIG

12.9%

——4GeoWebPlayer (also called "Web Plugin" in the GV-VMS documentation and "WS Player" for VMS-Cloud) is an addon that can be installed with various GeoVision software (GV-VMS, GV-Cloud, ...). It creates a websocket server that expands the capabilities of the various web-interfaces provided by the GeoVision software and may be necessary for them to function properly. The Websocket server can accept various commands coming from localhost. Many of the commands will take an `index` value that is then used to access various arrays to enter critical sections, perform various actions via function calls, etc. However the `index` value is usually not checked for valid range, and as such it can be used to access multiple arrays out-of-bound. #### setStream command index-out-of-bound50d CVE-2023-40212—

——4——CVE-2024-467877.8 HIG

12.9%

——4In the Linux kernel, the following vulnerability has been resolved: userfaultfd: fix checks for huge PMDs Patch series "userfaultfd: fix races around pmd_trans_huge() check", v2. The pmd_trans_huge() code in mfill_atomic() is wrong in three different ways depending on kernel version: 1. The pmd_trans_huge() check is racy and can lead to a BUG_ON() (if you hit the right two race windows) - I've tested this in a kernel build with some extra mdelay() calls. See the commit message for a description of the race scenario. On older kernels (before 6.5), I think the same bug can even theoretically lead to accessing transhuge page contents as a page table if you hit the right 5 narrow race windows (I haven't tested this case). 2. As pointed out by Qi Zheng, pmd_trans_huge() is not sufficient for detecting PMDs that don't point to page tables. On older kernels (before 6.5), you'd just have to win a single fairly wide race to hit this. I've tested this on 6.1 stable by racing migration (with a mdelay() patched into try_to_migrate()) against UFFDIO_ZEROPAGE - on my x86 VM, that causes a kernel oops in ptlock_ptr(). 3. On newer kernels (>=6.5), for shmem mappings, khugepaged is allowed to yank page tables out from under us (though I haven't tested that), so I think the BUG_ON() checks in mfill_atomic() are just wrong. I decided to write two separate fixes for these (one fix for bugs 1+2, one fix for bug 3), so that the first fix can be backported to kernels affected by bugs 1+2. This patch (of 2): This fixes two issues. I discovered that the following race can occur: mfill_atomic other thread ============ ============ <zap PMD> pmdp_get_lockless() [reads none pmd] <bail if trans_huge> <if none:> <pagefault creates transhuge zeropage> __pte_alloc [no-op] <zap PMD> <bail if pmd_trans_huge(*dst_pmd)> BUG_ON(pmd_none(*dst_pmd)) I have experimentally verified this in a kernel with extra mdelay() calls; the BUG_ON(pmd_none(*dst_pmd)) triggers. On kernels newer than commit 0d940a9b270b ("mm/pgtable: allow pte_offset_map[_lock]() to fail"), this can't lead to anything worse than a BUG_ON(), since the page table access helpers are actually designed to deal with page tables concurrently disappearing; but on older kernels (<=6.4), I think we could probably theoretically race past the two BUG_ON() checks and end up treating a hugepage as a page table. The second issue is that, as Qi Zheng pointed out, there are other types of huge PMDs that pmd_trans_huge() can't catch: devmap PMDs and swap PMDs (in particular, migration PMDs). On <=6.4, this is worse than the first issue: If mfill_atomic() runs on a PMD that contains a migration entry (which just requires winning a single, fairly wide race), it will pass the PMD to pte_offset_map_lock(), which assumes that the PMD points to a page table. Breakage follows: First, the kernel tries to take the PTE lock (which will crash or maybe worse if there is no "struct page" for the address bits in the migration entry PMD - I think at least on X86 there usually is no corresponding "struct page" thanks to the PTE inversion mitigation, amd64 looks different). If that didn't crash, the kernel would next try to write a PTE into what it wrongly thinks is a page table. As part of fixing these issues, get rid of the check for pmd_trans_huge() before __pte_alloc() - that's redundant, we're going to have to check for that after the __pte_alloc() anyway. Backport note: pmdp_get_lockless() is pmd_read_atomic() in older kernels.17d CVE-2026-598056.5 MED

12.9%

——4Gumroad before 2026.07.06.2 contains a broken access control vulnerability in the PurchasesController that allows authenticated sellers to manipulate purchase access for other sellers' products by sending PUT requests to the revoke_access and undo_revoke_access actions without seller ownership validation. Attackers can modify the is_access_revoked status on arbitrary purchases to unauthorized revoke or restore buyer access to products they do not own.42d CVE-2023-25706—

12.9%

——4——CVE-2023-36687—

12.8%

——4——CVE-2026-50606.5 MED

12.9%

——4The MasterStudy LMS WordPress Plugin – for Online Courses and Education plugin for WordPress is vulnerable to Insecure Direct Object Reference in all versions up to, and including, 3.7.14. This is due to the `stm_lms_delete_cover()` function lacking ownership validation on the `file_id` parameter before passing it to `wp_delete_attachment()`. This makes it possible for authenticated attackers, with Instructor-level access and above, to delete arbitrary attachments belonging to any user by enumerating sequential attachment IDs.22d CVE-2025-32427—

12.9%

——4——CVE-2025-696205.0 MED

12.9%

——4A path traversal in Moo Chan Song v4.5.7 allows attackers to cause a Denial of Service (DoS) via writing files to the internal storage.48d CVE-2025-36081—

——4——CVE-2026-352057.8 HIG

12.9%

——4Helm is a package manager for Charts for Kubernetes. From 4.0.0 to 4.1.3, Helm will install plugins missing provenance (.prov file) when signature verification is required. This vulnerability is fixed in 4.1.4.38d CVE-2025-606855.1 MED

12.9%

——4A stack buffer overflow exists in the ToToLink A720R Router firmware V4.1.5cu.614_B20230630 within the sysconf binary (sub_401EE0 function). The binary reads the /proc/stat file using fgets() into a local buffer and subsequently parses the line using sscanf() into a single-byte variable with the %s format specifier. Maliciously crafted /proc/stat content can overwrite adjacent stack memory, potentially allowing an attacker with filesystem write privileges to execute arbitrary code on the device.48d CVE-2024-49570—

——4——CVE-2026-131318.3 HIG

12.9%

——4GeoWebPlayer (also called "Web Plugin" in the GV-VMS documentation and "WS Player" for VMS-Cloud) is an addon that can be installed with various GeoVision software (GV-VMS, GV-Cloud, ...). It creates a websocket server that expands the capabilities of the various web-interfaces provided by the GeoVision software and may be necessary for them to function properly. The Websocket server can accept various commands coming from localhost. Many of the commands will take an `index` value that is then used to access various arrays to enter critical sections, perform various actions via function calls, etc. However the `index` value is usually not checked for valid range, and as such it can be used to access multiple arrays out-of-bound. #### connectInfo command index-out-of-bound50d CVE-2026-463078.3 HIG

12.9%

——4In the Linux kernel, the following vulnerability has been resolved: wifi: ath5k: do not access array OOB Vincent reports: > The ath5k driver seems to do an array-index-out-of-bounds access as > shown by the UBSAN kernel message: > UBSAN: array-index-out-of-bounds in drivers/net/wireless/ath/ath5k/base.c:1741:20 > index 4 is out of range for type 'ieee80211_tx_rate [4]' > ... > Call Trace: > <TASK> > dump_stack_lvl+0x5d/0x80 > ubsan_epilogue+0x5/0x2b > __ubsan_handle_out_of_bounds.cold+0x46/0x4b > ath5k_tasklet_tx+0x4e0/0x560 [ath5k] > tasklet_action_common+0xb5/0x1c0 It is real. 'ts->ts_final_idx' can be 3 on 5212, so: info->status.rates[ts->ts_final_idx + 1].idx = -1; with the array defined as: struct ieee80211_tx_rate rates[IEEE80211_TX_MAX_RATES]; while the size is: #define IEEE80211_TX_MAX_RATES 4 is indeed bogus. Set this 'idx = -1' sentinel only if the array index is less than the array size. As mac80211 will not look at rates beyond the size (IEEE80211_TX_MAX_RATES). Note: The effect of the OOB write is negligible. It just overwrites the next member of info->status, i.e. ack_signal.29d CVE-2026-740045.4 MED

12.9%

——4Subscriber Broken Access Control in Gravity Booster – Styles & Layouts for Gravity Forms <= 6.0 versions.1d CVE-2024-56759—