Vulnerabilities exploitable today
356,679in 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,662
New KEV · 24H0
Exploit Today ≥ 701,605
Distribution · last window
- Critical2,534
- High10,644
- Medium6,743
- Low670
Window
Severity
Flags
CVECVSSEPSSKEVRExploitTitleMod.
CVE-2025-22009—8.1%
——2——CVE-2024-56668—8.1%
——2——CVE-2026-56236—8.1%
——2——CVE-2025-68289—8.1%
——2——CVE-2023-54298—8.1%
——2——CVE-2026-33739—8.1%
——2——CVE-2025-30419—8.1%
——2——CVE-2025-399657.8 HIG8.1%
——2In the Linux kernel, the following vulnerability has been resolved:
xfrm: xfrm_alloc_spi shouldn't use 0 as SPI
x->id.spi == 0 means "no SPI assigned", but since commit
94f39804d891 ("xfrm: Duplicate SPI Handling"), we now create states
and add them to the byspi list with this value.
__xfrm_state_delete doesn't remove those states from the byspi list,
since they shouldn't be there, and this shows up as a UAF the next
time we go through the byspi list.10dCVE-2022-34434—8.1%
——2——CVE-2025-21962—8.1%
——2——CVE-2025-21992—8.1%
——2——CVE-2025-12574—8.1%
——2——CVE-2021-25414—8.1%
——2——CVE-2024-49294—8.1%
——2——CVE-2024-21814—8.1%
——2——CVE-2023-6361—8.1%
——2——CVE-2024-37236—8.1%
——2——CVE-2026-162124.2 MED8.1%
——2A vulnerability was identified in awesto django-shop up to 1.2.4. Affected is an unknown function of the file shop/models/inventory.py of the component Purchase Stock Handler. The manipulation leads to race condition. The attack is possible to be carried out remotely. The attack is considered to have high complexity. The exploitability is told to be difficult. The exploit is publicly available and might be used. The project was informed of the problem early through an issue report but has not responded yet.19dCVE-2022-27840—8.1%
——2——CVE-2024-29962—8.1%
——2——CVE-2021-47756—8.1%
——2——CVE-2025-61674—8.1%
——2——CVE-2025-22017—8.1%
——2——CVE-2021-34708—8.1%
——2——CVE-2023-53812—8.1%
——2——CVE-2023-53811—8.1%
——2——CVE-2025-40156—8.1%
——2——CVE-2026-23620—8.1%
——2——CVE-2026-35066—8.1%
——2——CVE-2026-46398—8.1%
——2HAX CMS helps manage microsite universe with PHP or NodeJs backends. Starting in version 25.0.0 and prior to version 26.0.0, the haxcms_refresh_token cookie is set without the Secure flag. This allows it to be transmitted over unencrypted HTTP, making it vulnerable to theft via packet sniffing on the network. Version 26.0.0 fixes the issue.17dCVE-2025-40288—8.1%
——2——CVE-2024-6060—8.1%
——2——CVE-2021-0485—8.1%
——2——CVE-2026-283855.0 MED8.1%
——2In Canonical LXD versions 4.12 through 6.9, a Server-Side Request Forgery (SSRF) vulnerability in the image import functionality allows authenticated users with the can_create_images entitlement to interact with internal network infrastructure via the /images endpoint. When importing an image from a URL source, the LXD daemon fails to validate or restrict outbound destination IP addresses, allowing connections to loopback, RFC1918 private ranges, and cloud metadata endpoints. This enables error-based port scanning and unauthorized interaction with internal HTTP services from the daemon's network position.33dCVE-2026-32101—8.1%
——2——CVE-2025-69025—8.1%
——2——CVE-2019-25567—8.1%
——2——CVE-2025-40196—8.1%
——2In the Linux kernel, the following vulnerability has been resolved:
fs: quota: create dedicated workqueue for quota_release_work
There is a kernel panic due to WARN_ONCE when panic_on_warn is set.
This issue occurs when writeback is triggered due to sync call for an
opened file(ie, writeback reason is WB_REASON_SYNC). When f2fs balance
is needed at sync path, flush for quota_release_work is triggered.
By default quota_release_work is queued to "events_unbound" queue which
does not have WQ_MEM_RECLAIM flag. During f2fs balance "writeback"
workqueue tries to flush quota_release_work causing kernel panic due to
MEM_RECLAIM flag mismatch errors.
This patch creates dedicated workqueue with WQ_MEM_RECLAIM flag
for work quota_release_work.
------------[ cut here ]------------
WARNING: CPU: 4 PID: 14867 at kernel/workqueue.c:3721 check_flush_dependency+0x13c/0x148
Call trace:
check_flush_dependency+0x13c/0x148
__flush_work+0xd0/0x398
flush_delayed_work+0x44/0x5c
dquot_writeback_dquots+0x54/0x318
f2fs_do_quota_sync+0xb8/0x1a8
f2fs_write_checkpoint+0x3cc/0x99c
f2fs_gc+0x190/0x750
f2fs_balance_fs+0x110/0x168
f2fs_write_single_data_page+0x474/0x7dc
f2fs_write_data_pages+0x7d0/0xd0c
do_writepages+0xe0/0x2f4
__writeback_single_inode+0x44/0x4ac
writeback_sb_inodes+0x30c/0x538
wb_writeback+0xf4/0x440
wb_workfn+0x128/0x5d4
process_scheduled_works+0x1c4/0x45c
worker_thread+0x32c/0x3e8
kthread+0x11c/0x1b0
ret_from_fork+0x10/0x20
Kernel panic - not syncing: kernel: panic_on_warn set ...15dCVE-2024-581007.8 HIG8.1%
——2In the Linux kernel, the following vulnerability has been resolved:
bpf: check changes_pkt_data property for extension programs
When processing calls to global sub-programs, verifier decides whether
to invalidate all packet pointers in current state depending on the
changes_pkt_data property of the global sub-program.
Because of this, an extension program replacing a global sub-program
must be compatible with changes_pkt_data property of the sub-program
being replaced.
This commit:
- adds changes_pkt_data flag to struct bpf_prog_aux:
- this flag is set in check_cfg() for main sub-program;
- in jit_subprogs() for other sub-programs;
- modifies bpf_check_attach_btf_id() to check changes_pkt_data flag;
- moves call to check_attach_btf_id() after the call to check_cfg(),
because it needs changes_pkt_data flag to be set:
bpf_check:
... ...
- check_attach_btf_id resolve_pseudo_ldimm64
resolve_pseudo_ldimm64 --> bpf_prog_is_offloaded
bpf_prog_is_offloaded check_cfg
check_cfg + check_attach_btf_id
... ...
The following fields are set by check_attach_btf_id():
- env->ops
- prog->aux->attach_btf_trace
- prog->aux->attach_func_name
- prog->aux->attach_func_proto
- prog->aux->dst_trampoline
- prog->aux->mod
- prog->aux->saved_dst_attach_type
- prog->aux->saved_dst_prog_type
- prog->expected_attach_type
Neither of these fields are used by resolve_pseudo_ldimm64() or
bpf_prog_offload_verifier_prep() (for netronome and netdevsim
drivers), so the reordering is safe.4dCVE-2022-50889—8.1%
——2——