Vulnerabilities
All
My stack
Known exploited
Public exploit
Critical (9+)
Likely exploited (EPSS ≥ 50%)
Changed, 24 h
New, 24 h
Sort:
risk
modified
published
CVSS
EPSS
| CVE | CVSS | EPSS | Vendor, product | Description | Modified |
|---|---|---|---|---|---|
| CVE-2026-72057 | 8.2 high | 1.0% | no CPE yet | In the Linux kernel, the following vulnerability has been resolved: net/sched: act_ct: preserve tc_skb_cb across defragmentation tcf_ct_handle_fragments() calls nf_ct_handle_fragments() without saving and restoring skb->cb. The defrag helper clears IPCB/IP6CB, which aliases the tc_skb_cb/qdisc_skb_cb control buffer. Fragmented traffic through act_ct therefore loses qdisc metadata such as pkt_segs and can trigger WARN_ON_ONCE() in qdisc_pkt_segs() when panic_on_warn is enabled. Save and restore the full tc_skb_cb around nf_ct_handle_fragments(), matching the pattern used by ovs_ct_handle_fragments(). | 19 Oct |
| CVE-2026-72035 | 8.2 high | 1.0% | no CPE yet | In the Linux kernel, the following vulnerability has been resolved: net/sched: sch_taprio: Replace direct dequeue call with peek and qdisc_dequeue_peeked When taprio's software path peeks a non-work-conserving child qdisc, the child stashes the peeked skb in its gso_skb; taprio_dequeue_from_txq() then takes the packet with a direct child ->dequeue() call, which ignores that stash, orphans the peeked skb and desyncs the child's qlen/backlog. With a qfq child this re-enters the child on an emptied list and dereferences NULL, panicking the kernel from softirq on ordinary egress. Take the packet through qdisc_dequeue_peeked(), as sch_red and sch_sfb now do. The helper returns the child's stashed skb first and is a no-op when there is none, so a work-conserving child is unaffected and the gated path now consumes the skb whose length was charged to the budget. | 19 Oct |
| CVE-2026-80985 | 8.2 high | 1.0% | no CPE yet | In the Linux kernel, the following vulnerability has been resolved: net/smc: carry oversized SMC-Rv2 LLC messages in the queue entry smc_llc_rmt_delete_rkey() and smc_llc_save_add_link_rkeys() read the part of a v2 message that does not fit into the 44-byte union smc_llc_msg, and both bound themselves by the size of the buffer it landed in, not by what arrived. On a link with a shared v2 receive buffer a 44-byte DELETE_RKEY_V2 declaring 255 rkeys reaches rkey[9..254] in whatever an earlier message left in lgr->wr_rx_buf_v2, and passes each of them to smc_rtoken_delete(). One of those 255 matched a registered rtoken and deleted it. An ADD_LINK on such a link installs up to 255 rtokens from the same bytes. Copy the tail into the queue entry, so its length is the length of the message that arrived, and declare the rkeys that fit inline as a member of the union instead of reaching them through a cast. The same DELETE_RKEY_V2 now processes the 9 rkeys it carries. The copy is limited to the longest tail the two functions can read, so the peer does not pick the size of the entry. The bound the previous patch placed on links without a shared v2 receive buffer is no longer needed. | 19 Oct |
| CVE-2026-11816 | 8.1 high | 1.0% | keras | Keras versions prior to 3.14.0 are vulnerable to a path traversal issue in the archive extraction utilities located in `keras/src/utils/file_utils.py`. The functions `filter_safe_tarinfos()` and `filter_safe_zipinfos()` validate archive member paths against the process current working directory (CWD) instead of the actual extraction destination. When the process runs with CWD set to `/`, which is common in Docker containers, CI/CD runners, and Jupyter environments, the validation boundary becomes the filesystem root, allowing traversal paths to bypass the security check. Additionally, the zip filter contains a bug that causes an `AttributeError` when a blocked entry is encountered, leading to incomplete extraction. Furthermore, Python 3.11 installations lack the `filter="data"` safety net, leaving them entirely reliant on the flawed CWD-based filter. Exploitation of this vulnerability can result in arbitrary file writes outside the intended extraction directory, enabling attackers to overwrite configuration files, inject malicious code, or corrupt machine learning datasets and pipelines. | Mon 26 Oct |
| CVE-2026-70197 | 8.1 high | 1.0% | no CPE yet | Out-of-bounds write in .NET allows an unauthorized attacker to execute code over a network. | Sun 25 Oct |
| CVE-2026-13185 | 8.1 high | 1.0% | progress, telerik_ui_for_asp.net_ajax | In Progress® Telerik® UI for AJAX prior to v2026.2.708, applications using cookie-based storage in RadPersistenceManager or RadDockLayout deserialize attacker-controlled cookie content, allowing unauthenticated remote code execution. | Sat 24 Oct |
| CVE-2026-13186 | 8.1 high | 1.0% | progress, telerik_ui_for_asp.net_ajax | In Progress® Telerik® UI for AJAX prior to v2026.2.708, a path traversal vulnerability in the file-based persistence storage provider can be exploited when the storage key is derived from user-controlled input, enabling attacker-controlled deserialization and remote code execution. | Sat 24 Oct |
| CVE-2026-13190 | 8.1 high | 1.0% | progress, telerik_ui_for_asp.net_ajax | In Progress® Telerik® UI for AJAX prior to v2026.2.708, a deserialization vulnerability in the persistence utilities allows unsafe type instantiation from attacker-influenced persisted state, which can lead to remote code execution. | Sat 24 Oct |
| CVE-2026-89682 | 8.1 high | 1.0% | no CPE yet | In the Linux kernel, the following vulnerability has been resolved: nfsd: fix fcache_disposal UAF by inlining dispose state into nfsd_net nfsd_file_dispose_list_delayed() defers fput() to nfsd service threads via a per-net freeme queue, preventing the shrinker and GC worker from bearing the cost of closing files (see ffb402596147). However, the queue lives in a separately-allocated struct nfsd_fcache_disposal that is freed by nfsd_free_fcache_disposal_net() during per-net teardown. The global shrinker, laundrette, and fsnotify callbacks can still be inside nfsd_file_dispose_list_delayed() dereferencing that pointer, causing a use-after-free. Inline the spinlock and freeme list directly into struct nfsd_net (as fcache_dispose_lock and fcache_dispose_list), eliminating the separately allocated struct nfsd_fcache_disposal entirely. These fields now have the same lifetime as the net namespace itself, so there is no dangling pointer to chase. nfsd_file_cache_start_net() now just initializes the inline fields and cannot fail due to allocation. nfsd_file_cache_shutdown_net() drains the inline list directly instead of freeing a separate struct. The alloc/free helpers are removed. | 21 Oct |
| CVE-2025-40186 | 8.1 high | 1.0% | no CPE yet | In the Linux kernel, the following vulnerability has been resolved: tcp: Don't call reqsk_fastopen_remove() in tcp_conn_request(). syzbot reported the splat below in tcp_conn_request(). [0] If a listener is close()d while a TFO socket is being processed in tcp_conn_request(), inet_csk_reqsk_queue_add() does not set reqsk->sk and calls inet_child_forget(), which calls tcp_disconnect() for the TFO socket. After the cited commit, tcp_disconnect() calls reqsk_fastopen_remove(), where reqsk_put() is called due to !reqsk->sk. Then, reqsk_fastopen_remove() in tcp_conn_request() decrements the last req->rsk_refcnt and frees reqsk, and __reqsk_free() at the drop_and_free label causes the refcount underflow for the listener and double-free of the reqsk. Let's remove reqsk_fastopen_remove() in tcp_conn_request(). Note that other callers make sure tp->fastopen_rsk is not NULL. [0]: refcount_t: underflow; use-after-free. WARNING: CPU: 12 PID: 5563 at lib/refcount.c:28 refcount_warn_saturate (lib/refcount.c:28) Modules linked in: CPU: 12 UID: 0 PID: 5563 Comm: syz-executor Not tainted syzkaller #0 PREEMPT(full) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/12/2025 RIP: 0010:refcount_warn_saturate (lib/refcount.c:28) Code: ab e8 8e b4 98 ff 0f 0b c3 cc cc cc cc cc 80 3d a4 e4 d6 01 00 75 9c c6 05 9b e4 d6 01 01 48 c7 c7 e8 df fb ab e8 6a b4 98 ff <0f> 0b e9 03 5b 76 00 cc 80 3d 7d e4 d6 01 00 0f 85 74 ff ff ff c6 RSP: 0018:ffffa79fc0304a98 EFLAGS: 00010246 RAX: d83af4db1c6b3900 RBX: ffff9f65c7a69020 RCX: d83af4db1c6b3900 RDX: 0000000000000000 RSI: 00000000ffff7fff RDI: ffffffffac78a280 RBP: 000000009d781b60 R08: 0000000000007fff R09: ffffffffac6ca280 R10: 0000000000017ffd R11: 0000000000000004 R12: ffff9f65c7b4f100 R13: ffff9f65c7d23c00 R14: ffff9f65c7d26000 R15: ffff9f65c7a64ef8 FS: 00007f9f962176c0(0000) GS:ffff9f65fcf00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000200000000180 CR3: 000000000dbbe006 CR4: 0000000000372ef0 Call Trace: <IRQ> tcp_conn_request (./include/linux/refcount.h:400 ./include/linux/refcount.h:432 ./include/linux/refcount.h:450 ./include/net/sock.h:1965 ./include/net/request_sock.h:131 net/ipv4/tcp_input.c:7301) tcp_rcv_state_process (net/ipv4/tcp_input.c:6708) tcp_v6_do_rcv (net/ipv6/tcp_ipv6.c:1670) tcp_v6_rcv (net/ipv6/tcp_ipv6.c:1906) ip6_protocol_deliver_rcu (net/ipv6/ip6_input.c:438) ip6_input (net/ipv6/ip6_input.c:500) ipv6_rcv (net/ipv6/ip6_input.c:311) __netif_receive_skb (net/core/dev.c:6104) process_backlog (net/core/dev.c:6456) __napi_poll (net/core/dev.c:7506) net_rx_action (net/core/dev.c:7569 net/core/dev.c:7696) handle_softirqs (kernel/softirq.c:579) do_softirq (kernel/softirq.c:480) </IRQ> | 19 Oct |
| CVE-2026-70175 | 8.1 high | 1.0% | no CPE yet | Improper authentication in ASP.NET Core allows an unauthorized attacker to elevate privileges over a network. | 19 Oct |
| CVE-2026-98069 | 8.1 high | 1.0% | no CPE yet | In the Linux kernel, the following vulnerability has been resolved: net/rds: acquire the fastpath locks in rds_conn_shutdown() rds_conn_shutdown() quiesces the transmit and receive-refill paths by waiting for RDS_IN_XMIT and RDS_RECV_REFILL to be sampled clear, and then runs the transport shutdown and rds_conn_path_reset(). Sampling the bits clear is not the same as owning them: the moment after the wait_event() returns, rds_send_xmit() can re-acquire RDS_IN_XMIT (or rds_ib_recv_refill() can re-acquire RDS_RECV_REFILL) and run concurrently with the teardown. The sender does recheck the connection state after taking the lock, but that recheck is a classic store-buffering pattern: teardown writes the state and reads the bit while the sender writes the bit and reads the state. acquire_in_xmit() is only an acquire operation, so on weakly ordered architectures both sides can miss each other's write, and the transmit path then runs while the transport zeroes its rings (e.g. rds_ib_ring_init()) and rds_send_path_reset() rewrites the transmit state under it. Oracle UEK fixed the same class of crashes - a 14-year tail of BUG_ON()s in rds_ib_sub_signaled(), unexpected op-codes and NULL dereferences in rds_ib_send_cqe_handler() during failover testing - by making the teardown path *acquire* the fastpath bit locks instead of testing them ("rds: Make sure transmit path and connection tear-down does not run concurrently"). Ownership of a single word is decided by RMW atomicity, so no cross-variable ordering is needed. Do the same here: take both locks before calling the transport shutdown, hold them across rds_conn_path_reset(), and release them explicitly with a wake-up afterwards. Both are released with clear_bit_unlock(), so that the ring re-initialization done by the transport shutdown and the transmit state rewritten by rds_send_path_reset() are ordered before either bit is seen clear by the next acquire_in_xmit() or acquire_refill(). The fastpath users of these bits - rds_send_xmit() and rds_ib_recv_refill() - are trylock style and back off while teardown owns the locks, so no new lock dependency is introduced for them. rds_tcp_reset_callbacks() is different: since the previous patch it acquires RDS_IN_XMIT as well, and it blocks doing so, so its wait now spans the teardown instead of at most one send batch. That waiter runs from rds_tcp_accept_one() on the single-threaded krdsd workqueue and holds rds_tcp_accept_lock and t_conn_path_lock while it waits, so a duelling SYN accepted while its path is being torn down parks accept processing for the duration of the teardown - for TCP bounded by the (up to 5 s) drain loop in rds_tcp_conn_path_shutdown(). An IB path's drain in rds_ib_conn_path_shutdown() has no round cap, but no blocking waiter either: rds_tcp_reset_callbacks() is the only blocking acquirer of these bits and waits only on its own TCP path, and the fastpaths are trylock-and-back-off on both transports, so a long IB drain lengthens only that path's own quiesce. The window is narrow: the accept-side state check has to pass before the teardown moves the path to RDS_CONN_DISCONNECTING. Because krdsd is a single global workqueue, everything else queued there - accept processing for other connections and network namespaces, and the flush_workqueue(rds_wq) in rds_tcp_listen_stop() during namespace teardown - waits behind the parked accept worker for that time. It cannot deadlock, although the waits do point at each other: the teardown blocks until the bit's holder releases it, and the holder may be that krdsd accept worker. The holder finishes without needing anything the teardown owns: the sync cancels rds_tcp_reset_callbacks() issues target cp_send_w and cp_recv_w on the path's ordered cp_wq, whose only execution slot is occupied by the blocked cp_down_w itself, so they are pending at most and cancel without flushing - a reliance on cp_wq being ordered that is now noted next to those cancels (on ---truncated--- | 19 Oct |
| CVE-2026-89667 | 8.1 high | 1.0% | no CPE yet | In the Linux kernel, the following vulnerability has been resolved: nfsd: close shrinker/GC/fsnotify vs per-net shutdown race in filecache The shrinker, GC worker, and fsnotify/lease callbacks can unhash an nfsd_file from the rhashtable and then call nfsd_file_dispose_list_delayed() to move it to the per-net dispose list. If nfsd_file_cache_shutdown_net() runs concurrently, its rhashtable walk misses the already-unhashed file, and its drain of the per-net dispose list can run before the file has been queued. The file then sits on the per-net list with no thread to drain it, leaking both the file and its associated state. The GC worker and shrinker already hold nfsd_gc_lock while walking the LRU, but in the original code they release it before calling nfsd_file_dispose_list_delayed(). The fsnotify/lease path (nfsd_file_close_inode) has no synchronization at all. Fix this by: 1. Widening nfsd_gc_lock in both nfsd_file_gc() and nfsd_file_lru_scan() to cover the nfsd_file_dispose_list_delayed() call. 2. Wrapping nfsd_file_close_inode() in nfsd_gc_lock so that all three callers of nfsd_file_dispose_list_delayed() hold the lock. 3. Adding a spin_lock/unlock(nfsd_gc_lock) barrier in nfsd_file_cache_shutdown_net() after the purge, so that any in-progress disposal has fully completed before the per-net list is drained. All operations inside the lock are non-sleeping (rhashtable lookups, atomic bit/refcount ops, list moves, svc_wake_up), so the spinlock is appropriate. | 19 Oct |
| CVE-2025-38052 | 7.8 high | 1.0% | linux, debian, linux_kernel, debian_linux | In the Linux kernel, the following vulnerability has been resolved: net/tipc: fix slab-use-after-free Read in tipc_aead_encrypt_done Syzbot reported a slab-use-after-free with the following call trace: ================================================================== BUG: KASAN: slab-use-after-free in tipc_aead_encrypt_done+0x4bd/0x510 net/tipc/crypto.c:840 Read of size 8 at addr ffff88807a733000 by task kworker/1:0/25 Call Trace: kasan_report+0xd9/0x110 mm/kasan/report.c:601 tipc_aead_encrypt_done+0x4bd/0x510 net/tipc/crypto.c:840 crypto_request_complete include/crypto/algapi.h:266 aead_request_complete include/crypto/internal/aead.h:85 cryptd_aead_crypt+0x3b8/0x750 crypto/cryptd.c:772 crypto_request_complete include/crypto/algapi.h:266 cryptd_queue_worker+0x131/0x200 crypto/cryptd.c:181 process_one_work+0x9fb/0x1b60 kernel/workqueue.c:3231 Allocated by task 8355: kzalloc_noprof include/linux/slab.h:778 tipc_crypto_start+0xcc/0x9e0 net/tipc/crypto.c:1466 tipc_init_net+0x2dd/0x430 net/tipc/core.c:72 ops_init+0xb9/0x650 net/core/net_namespace.c:139 setup_net+0x435/0xb40 net/core/net_namespace.c:343 copy_net_ns+0x2f0/0x670 net/core/net_namespace.c:508 create_new_namespaces+0x3ea/0xb10 kernel/nsproxy.c:110 unshare_nsproxy_namespaces+0xc0/0x1f0 kernel/nsproxy.c:228 ksys_unshare+0x419/0x970 kernel/fork.c:3323 __do_sys_unshare kernel/fork.c:3394 Freed by task 63: kfree+0x12a/0x3b0 mm/slub.c:4557 tipc_crypto_stop+0x23c/0x500 net/tipc/crypto.c:1539 tipc_exit_net+0x8c/0x110 net/tipc/core.c:119 ops_exit_list+0xb0/0x180 net/core/net_namespace.c:173 cleanup_net+0x5b7/0xbf0 net/core/net_namespace.c:640 process_one_work+0x9fb/0x1b60 kernel/workqueue.c:3231 After freed the tipc_crypto tx by delete namespace, tipc_aead_encrypt_done may still visit it in cryptd_queue_worker workqueue. I reproduce this issue by: ip netns add ns1 ip link add veth1 type veth peer name veth2 ip link set veth1 netns ns1 ip netns exec ns1 tipc bearer enable media eth dev veth1 ip netns exec ns1 tipc node set key this_is_a_master_key master ip netns exec ns1 tipc bearer disable media eth dev veth1 ip netns del ns1 The key of reproduction is that, simd_aead_encrypt is interrupted, leading to crypto_simd_usable() return false. Thus, the cryptd_queue_worker is triggered, and the tipc_crypto tx will be visited. tipc_disc_timeout tipc_bearer_xmit_skb tipc_crypto_xmit tipc_aead_encrypt crypto_aead_encrypt // encrypt() simd_aead_encrypt // crypto_simd_usable() is false child = &ctx->cryptd_tfm->base; simd_aead_encrypt crypto_aead_encrypt // encrypt() cryptd_aead_encrypt_enqueue cryptd_aead_enqueue cryptd_enqueue_request // trigger cryptd_queue_worker queue_work_on(smp_processor_id(), cryptd_wq, &cpu_queue->work) Fix this by holding net reference count before encrypt. | 15 Oct |
| CVE-2024-26882 | 7.8 high | 1.0% | linux, linux_kernel | In the Linux kernel, the following vulnerability has been resolved: net: ip_tunnel: make sure to pull inner header in ip_tunnel_rcv() Apply the same fix than ones found in : 8d975c15c0cd ("ip6_tunnel: make sure to pull inner header in __ip6_tnl_rcv()") 1ca1ba465e55 ("geneve: make sure to pull inner header in geneve_rx()") We have to save skb->network_header in a temporary variable in order to be able to recompute the network_header pointer after a pskb_inet_may_pull() call. pskb_inet_may_pull() makes sure the needed headers are in skb->head. syzbot reported: BUG: KMSAN: uninit-value in __INET_ECN_decapsulate include/net/inet_ecn.h:253 [inline] BUG: KMSAN: uninit-value in INET_ECN_decapsulate include/net/inet_ecn.h:275 [inline] BUG: KMSAN: uninit-value in IP_ECN_decapsulate include/net/inet_ecn.h:302 [inline] BUG: KMSAN: uninit-value in ip_tunnel_rcv+0xed9/0x2ed0 net/ipv4/ip_tunnel.c:409 __INET_ECN_decapsulate include/net/inet_ecn.h:253 [inline] INET_ECN_decapsulate include/net/inet_ecn.h:275 [inline] IP_ECN_decapsulate include/net/inet_ecn.h:302 [inline] ip_tunnel_rcv+0xed9/0x2ed0 net/ipv4/ip_tunnel.c:409 __ipgre_rcv+0x9bc/0xbc0 net/ipv4/ip_gre.c:389 ipgre_rcv net/ipv4/ip_gre.c:411 [inline] gre_rcv+0x423/0x19f0 net/ipv4/ip_gre.c:447 gre_rcv+0x2a4/0x390 net/ipv4/gre_demux.c:163 ip_protocol_deliver_rcu+0x264/0x1300 net/ipv4/ip_input.c:205 ip_local_deliver_finish+0x2b8/0x440 net/ipv4/ip_input.c:233 NF_HOOK include/linux/netfilter.h:314 [inline] ip_local_deliver+0x21f/0x490 net/ipv4/ip_input.c:254 dst_input include/net/dst.h:461 [inline] ip_rcv_finish net/ipv4/ip_input.c:449 [inline] NF_HOOK include/linux/netfilter.h:314 [inline] ip_rcv+0x46f/0x760 net/ipv4/ip_input.c:569 __netif_receive_skb_one_core net/core/dev.c:5534 [inline] __netif_receive_skb+0x1a6/0x5a0 net/core/dev.c:5648 netif_receive_skb_internal net/core/dev.c:5734 [inline] netif_receive_skb+0x58/0x660 net/core/dev.c:5793 tun_rx_batched+0x3ee/0x980 drivers/net/tun.c:1556 tun_get_user+0x53b9/0x66e0 drivers/net/tun.c:2009 tun_chr_write_iter+0x3af/0x5d0 drivers/net/tun.c:2055 call_write_iter include/linux/fs.h:2087 [inline] new_sync_write fs/read_write.c:497 [inline] vfs_write+0xb6b/0x1520 fs/read_write.c:590 ksys_write+0x20f/0x4c0 fs/read_write.c:643 __do_sys_write fs/read_write.c:655 [inline] __se_sys_write fs/read_write.c:652 [inline] __x64_sys_write+0x93/0xd0 fs/read_write.c:652 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x63/0x6b Uninit was created at: __alloc_pages+0x9a6/0xe00 mm/page_alloc.c:4590 alloc_pages_mpol+0x62b/0x9d0 mm/mempolicy.c:2133 alloc_pages+0x1be/0x1e0 mm/mempolicy.c:2204 skb_page_frag_refill+0x2bf/0x7c0 net/core/sock.c:2909 tun_build_skb drivers/net/tun.c:1686 [inline] tun_get_user+0xe0a/0x66e0 drivers/net/tun.c:1826 tun_chr_write_iter+0x3af/0x5d0 drivers/net/tun.c:2055 call_write_iter include/linux/fs.h:2087 [inline] new_sync_write fs/read_write.c:497 [inline] vfs_write+0xb6b/0x1520 fs/read_write.c:590 ksys_write+0x20f/0x4c0 fs/read_write.c:643 __do_sys_write fs/read_write.c:655 [inline] __se_sys_write fs/read_write.c:652 [inline] __x64_sys_write+0x93/0xd0 fs/read_write.c:652 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x63/0x6b | 15 Oct |
| CVE-2023-40283 | 7.8 high | 1.0% | linux, debian, linux_kernel, debian_linux, ubuntu_linux | An issue was discovered in l2cap_sock_release in net/bluetooth/l2cap_sock.c in the Linux kernel before 6.4.10. There is a use-after-free because the children of an sk are mishandled. | 15 Oct |
| CVE-2023-31436 | 7.8 high | 1.0% | linux, linux_kernel | qfq_change_class in net/sched/sch_qfq.c in the Linux kernel before 6.2.13 allows an out-of-bounds write because lmax can exceed QFQ_MIN_LMAX. | 14 Oct |
| CVE-2026-67201 | 7.7 high | 1.0% | no CPE yet | V through 0.5.2, fixed in commit 85859f0, contains a server-side request forgery (SSRF) bypass vulnerability that allows attackers to circumvent host-based allowlists by exploiting a parser differential between net.urllib and net.http. Attackers can craft a URL containing a backslash in the authority section such that net.urllib.parse() extracts the trusted host for allowlist validation while net.http.get() normalizes the backslash and connects to the internal host, enabling access to internal network services that the allowlist was intended to block. | Sat 24 Oct |
| CVE-2026-62898 | 7.5 high | 1.0% | microsoft, visual_studio_2022, visual_studio_2026, .net | Use after free in Microsoft QUIC allows an unauthorized attacker to disclose information over a network. | 24 h ago |
| CVE-2026-62901 | 7.5 high | 1.0% | microsoft, visual_studio_2022, visual_studio_2026, .net | Unchecked input for loop condition in .NET allows an unauthorized attacker to deny service over a network. | Wed 28 Oct |
| CVE-2026-57108 | 7.5 high | 1.0% | microsoft, .net | Access of resource using incompatible type ('type confusion') in .NET Core allows an unauthorized attacker to deny service over a network. | Wed 28 Oct |
| CVE-2026-56170 | 7.5 high | 1.0% | microsoft, .net | Allocation of resources without limits or throttling in ASP.NET Core allows an unauthorized attacker to deny service over a network. | Wed 28 Oct |
| CVE-2026-50651 | 7.5 high | 1.0% | microsoft, .net, visual_studio_2022, visual_studio_2026 | Allocation of resources without limits or throttling in .NET allows an unauthorized attacker to deny service over a network. | Wed 28 Oct |
| CVE-2026-50648 | 7.5 high | 1.0% | microsoft, .net_framework, .net, visual_studio_2022 | Allocation of resources without limits or throttling in .NET Framework allows an unauthorized attacker to deny service over a network. | Wed 28 Oct |
| CVE-2026-50527 | 7.5 high | 1.0% | microsoft, .net_framework, .net, visual_studio_2022 | Stack-based buffer overflow in .NET Framework allows an unauthorized attacker to deny service over a network. | Wed 28 Oct |
| CVE-2026-50525 | 7.5 high | 1.0% | microsoft, .net_framework, .net, visual_studio_2022 | Allocation of resources without limits or throttling in .NET allows an unauthorized attacker to deny service over a network. | Wed 28 Oct |
| CVE-2026-50524 | 7.5 high | 1.0% | microsoft, .net, visual_studio_2022, visual_studio_2026 | Improper validation of specified type of input in .NET Framework allows an unauthorized attacker to deny service over a network. | Wed 28 Oct |
| CVE-2026-47302 | 7.5 high | 1.0% | microsoft, .net_framework, .net, visual_studio_2022 | Allocation of resources without limits or throttling in .NET allows an unauthorized attacker to deny service over a network. | Wed 28 Oct |
| CVE-2026-50647 | 7.5 high | 1.0% | microsoft, microsoft .net framework 3.5 and 4.7.2, microsoft .net framework 3.5 and 4.8, microsoft .net framework 3.5 and 4.8.1 | Loop with unreachable exit condition ('infinite loop') in Active Directory Federation Services (AD FS) allows an unauthorized attacker to deny service over a network. | Wed 28 Oct |
| CVE-2026-50411 | 7.5 high | 1.0% | microsoft, microsoft .net framework 3.5 and 4.7.2, microsoft .net framework 3.5 and 4.8, microsoft .net framework 3.5 and 4.8.1 | Stack-based buffer overflow in Active Directory Federation Services (AD FS) allows an unauthorized attacker to deny service over a network. | Wed 28 Oct |
| CVE-2026-50355 | 7.5 high | 1.0% | microsoft, microsoft .net framework 3.5 and 4.7.2, microsoft .net framework 3.5 and 4.8, microsoft .net framework 3.5 and 4.8.1 | Stack-based buffer overflow in Active Directory Federation Services allows an unauthorized attacker to deny service over a network. | Wed 28 Oct |
| CVE-2026-50368 | 7.5 high | 1.0% | microsoft, microsoft .net framework 3.5 and 4.7.2, microsoft .net framework 3.5 and 4.8, microsoft .net framework 3.5 and 4.8.1 | Stack-based buffer overflow in Active Directory Federation Services allows an unauthorized attacker to deny service over a network. | Wed 28 Oct |
| CVE-2026-50304 | 7.5 high | 1.0% | microsoft, microsoft .net framework 3.5 and 4.7.2, microsoft .net framework 3.5 and 4.8, microsoft .net framework 3.5 and 4.8.1 | Stack-based buffer overflow in Active Directory Federation Services allows an unauthorized attacker to deny service over a network. | Wed 28 Oct |
| CVE-2026-45646 | 7.5 high | 1.0% | microsoft, aspnet.odata, aspnetcore.odata | Allocation of resources without limits or throttling in ASP.NET Core allows an unauthorized attacker to deny service over a network. | Wed 28 Oct |
| CVE-2026-50653 | 7.5 high | 1.0% | microsoft, azure active directory, microsoft .net framework 3.5, microsoft .net framework 3.5 and 4.7.2 | Loop with unreachable exit condition ('infinite loop') in Azure Active Directory allows an unauthorized attacker to deny service over a network. | Wed 28 Oct |
| CVE-2026-50506 | 7.5 high | 1.0% | microsoft, aspnet.odata, aspnetcore.odata | Allocation of resources without limits or throttling in ASP.NET Core allows an unauthorized attacker to deny service over a network. | Wed 28 Oct |
| CVE-2026-75589 | 7.5 high | 1.0% | no CPE yet | Net::OAuth versions before 0.33 for Perl check HMAC-SHA1, HMAC-SHA256 and PLAINTEXT signatures with a non-constant-time comparison in verify. Each of the three compares the signature carried in the message against the locally computed one with the eq operator, which returns as soon as the two strings differ. The time taken to reject a signature varies with the length of the matching prefix. RSA-SHA1 is not affected, as it verifies through the RSA key object rather than by comparing strings. A client that can submit messages and time the replies may recover a valid signature one byte at a time rather than searching the whole signature space. Under PLAINTEXT the value compared against is the signature key itself, so the search recovers consumer_secret and token_secret. | Tue 27 Oct |
| CVE-2026-23666 | 7.5 high | 1.0% | microsoft, .net_framework | Improper input validation in .NET Framework allows an unauthorized attacker to deny service over a network. | Mon 26 Oct |
| CVE-2026-49451 | 7.5 high | 1.0% | no CPE yet | The OpenAPI.NET SDK contains a useful object model for OpenAPI documents in .NET along with common serializers to extract raw OpenAPI JSON and YAML documents from the model. From 2.0.0-preview11 until 2.7.5 and 3.5.4, a small OpenAPI document containing a circular schema reference can cause process termination through stack overflow in Microsoft.OpenApi. The issue affects OpenAPI document parsing through public OpenAPI.NET reader APIs and has been confirmed across both JSON and YAML reader paths. This vulnerability is fixed in 2.7.5 and 3.5.4. | Sun 25 Oct |
| CVE-2026-36478 | 7.5 high | 1.0% | no CPE yet | An issue in Technitium DNS Server v.14.3 and before allows a remote attacker to cause a denial of service via the DnsServerApp.exe, DnsServerApp.dll, TechnitiumLibrary.Net/Dns/DnsClient.cs components | Sun 25 Oct |
| CVE-2026-50273 | 7.5 high | 1.0% | no CPE yet | Datadog .NET Tracer is a client library for Datadog APM for .NET applications. Prior to 3.43.0, Datadog tracing libraries that implement W3C baggage propagation parse incoming baggage HTTP headers without enforcing DD_TRACE_BAGGAGE_MAX_ITEMS or DD_TRACE_BAGGAGE_MAX_BYTES on extraction, allowing a remote unauthenticated attacker to send a baggage header with many comma-separated key-value pairs or one very large value and cause unbounded CPU and memory consumption in services with baggage propagation enabled. This issue is fixed in version 3.43.0. | Sat 24 Oct |
| CVE-2026-64194 | 7.5 high | 1.0% | no CPE yet | Net::DNS versions through 1.55 for Perl allow Denial of Service via deep DNS compression pointer chains. Net::DNS::DomainName::decode follows RFC 1035 compression pointers by recursing into itself with no depth limit. It is possible to construct a name which saturates the call stack (at least with larger TCP responses), leading to a potential Denial of Service. The guard `$link < $offset` prevents forward and circular chains, but still allows arbitrarily long backward chains. The per-offset cache (`$cache`) is populated at the start of each call and short-circuits only re-traverses of the same offset - the initial descent through a fresh chain still recurses at full depth. A crafted packet can chain two-byte compression pointers so that each one points two bytes earlier than the previous, producing a chain length of `offset / 2`. For the 14-bit pointer field (max offset 16383) this gives up to ~8191 recursive frames. For a TCP DNS message the limit is the 16-bit length field (~32767 frames). Perl's default C stack handles only a few thousand frames; beyond that the process receives SIGSEGV or similar, which is a denial-of-service for any application parsing untrusted DNS data. The vulnerability is triggered by `Net::DNS::Packet->new(\$wire)` i.e. any point where the library decodes a DNS message from the network. | Sat 24 Oct |
| CVE-2026-98965 | 7.5 high | 1.0% | no CPE yet | In the Linux kernel, the following vulnerability has been resolved: ice: Restore Ordered MMIO Writes for Tx Doorbells The DQL accounting state which tracks the number of bytes queued for the NIC to transmit, namely dql->num_queued, is updated by the ICE driver when it invokes __netdev_tx_sent_queue(). Subsequently the driver updates the hardware queue tail allowing the NIC to begin processing the work queue. The queue accounting update should be ordered before the NIC begins transmitting descriptors. The transmit path currently updates the hardware doorbell using writel_relaxed(), which (on arm64) does not provide the same ordering guarantees between writes to normal memory and writes to MMIO registers that writel() does. This introduces a potential race where the NIC begins transmitting descriptors before the dql->num_queued update is globally visible. If the NIC finishes before the update is observed by dql_completed(), it detects an invalid state where more bytes have been completed than have been queued. When this happens the following BUG_ON is triggered. BUG_ON(count > num_queued - dql->num_completed); This has been observed and manifests as the following crash (note that the trace has been trimmed) in an environment with sustained network load that uses an Intel Corporation Ethernet Controller E810-XXV for SFP (rev 02) on an arm64 machine. Replacing writel_relaxed() with writel() in a test kernel eliminated the crash in the user's workload, which previously reproduced the issue reliably. kernel BUG at lib/dynamic_queue_limits.c:99 Internal error: Oops - BUG: 00000000f2000800 [#1] SMP pc : dql_completed+0x268/0x2a0 lr : ice_clean_tx_irq+0x1d4/0x620 [ice] Call trace: dql_completed+0x268/0x2a0 (P) ice_napi_poll+0x94/0x520 [ice] __napi_poll+0x48/0x3f0 net_rx_action+0x194/0x420 This restores the behaviour prior to commit ccde82e90946 ("ice: add E830 Earliest TxTime First Offload support"), which changed the notification mechanism from writel() to writel_relaxed(). | Sat 24 Oct |
| CVE-2026-98401 | 7.5 high | 1.0% | no CPE yet | In the Linux kernel, the following vulnerability has been resolved: net: iptunnel: fix stale transport header during tunnel decapsulation Syzbot reported a crash in qdisc_pkt_len_segs_init() caused by a stale transport_header offset after tunnel decapsulation. BUG: unable to handle page fault for address: ffffed102091a42e Oops: Oops: 0000 [#1] SMP KASAN NOPTI CPU: 0 UID: 0 PID: 340 Comm: qdisc_uaf_repro Not tainted 7.2.0-rc4-00061-g248951ddc14d #256 PREEMPT(full) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 RIP: 0010:__asan_load2 <IRQ> qdisc_pkt_len_segs_init (net/core/dev.c:4145) __dev_queue_xmit (net/core/dev.c:4787) br_dev_queue_push_xmit (net/bridge/br_forward.c:53) br_handle_frame_finish (net/bridge/br_input.c:229) br_handle_frame (net/bridge/br_input.c:315) __netif_receive_skb_core.constprop.0 (net/core/dev.c:6099) __netif_receive_skb_list_core (net/core/dev.c:6287) netif_receive_skb_list_internal (net/core/dev.c:6445) napi_complete_done (net/core/dev.c:6813) gro_cell_poll (net/core/gro_cells.c:74) __napi_poll (net/core/dev.c:7735) net_rx_action (net/core/dev.c:7798 net/core/dev.c:7955) handle_softirqs (kernel/softirq.c:622) do_softirq (kernel/softirq.c:523 kernel/softirq.c:510 ) __local_bh_enable_ip (kernel/softirq.c:450) tun_get_user (drivers/net/tun.c:1986 (discriminator 1)) tun_chr_write_iter (drivers/net/tun.c:2032) The issue is completely latent until qdisc read transport header in commit 7fb4c1967011 ("net: pull headers in qdisc_pkt_len_segs_init()"). The crash requires four conditions to line up: 1. The incoming packet is encapsulated and carries GSO metadata. The outer transport header offset is stored in skb->transport_header while the packet is still in the outer tunnel context. 2. The tunnel receiver strips the outer headers. skb->data is advanced to the inner frame, but skb->transport_header is left pointing to the now-removed outer L4 header, so it becomes a negative offset relative to the new data. 3. The inner frame is not delivered to the local IP stack. Instead, it is forwarded at L2 by a bridge or HSR, so ip_rcv_core() never runs and the transport header is not reset to the inner L4 offset. 4. The forwarding path calls __dev_queue_xmit(), which enters qdisc_pkt_len_segs_init(). That function computes the GSO header length from skb_transport_offset(skb). Because the offset is negative, the unsigned cast overflows and pskb_may_pull(skb, hdr_len + sizeof(struct tcphdr)) reads past the end of the skb, triggering a KASAN fault or page fault. The issue specifically requires GSO packets (shinfo->gso_size != 0), which are processed/aggregated through gro_cells. Fix this by clearing transport_header to the ~0U sentinel in gro_cell for all tunnnel driver. GTP does not support GRO/GSO, drop the evil GSO packets in GTP directly. | Sat 24 Oct |
| CVE-2026-10686 | 7.5 high | 1.0% | zephyrproject, zephyr | Zephyr's IPv6 forwarding path re-sent routed unicast packets without ever decrementing the IPv6 hop limit. Both routing branches of ipv6_route_packet() (subsys/net/ip) were affected: the explicit-route path (net_route_packet()) and the on-link cross-interface path (net_route_packet_if()). Each set the packet forwarding flag and called net_send_data() with the hop limit untouched and no expiry check. Per RFC 8200 the hop-limit decrement is the mechanism that bounds packet lifetime and terminates routing loops; without it, a device acting as an IPv6 router relays looping packets indefinitely. An on-path attacker who can induce or exploit a transient L3 loop turns it into a permanent forwarding storm, causing CPU/bandwidth resource exhaustion (availability DoS) on the forwarder and adjacent links; path-discovery and loop diagnostics that rely on hop-limit expiry are also defeated. Affected configurations. In every affected release the forwarding path is reached via CONFIG_NET_ROUTE (enabled by default when CONFIG_NET_IPV6_NBR_CACHE is set), together with CONFIG_NET_ROUTING for cross-interface routing. Note that CONFIG_NET_IPV6_FORWARDING and CONFIG_NET_IPV4_FORWARDING — which appear in the fix and in this advisory's evidence notes — were introduced after v4.4.0, when the routing options were split and renamed; they do not exist in any affected release. When auditing a v4.4.1-or-earlier configuration, look for CONFIG_NET_ROUTE and CONFIG_NET_ROUTING. IPv4 is not affected in any release. The IPv4 forwarding path (net_route_ipv4_packet() in route_ipv4.c) was added after v4.4.0 and has never shipped in a release. Its TTL decrement and IPv4 header-checksum recomputation landed on main as part of the same fix, so the evidence notes below discuss it, but no released version is reachable by way of IPv4. Affected releases are v1.8.0 through v4.4.1: v1.8.0 introduced net_route_packet() and v2.2.0 added net_route_packet_if(), and neither decremented the hop limit. v4.3.1 carries the explicit-route fix but not the on-link one, so it is affected as well. Fixed on main by 7d8f1afa7345 (explicit-route path) and 589eadc74efa (on-link path). | Fri 23 Oct |
| CVE-2022-43716 | 7.5 high | 1.0% | siemens, simatic_cp_1242-7_v2_firmware, simatic_cp_1243-1_firmware, simatic_cp_1243-1_dnp3_firmware | A vulnerability has been identified in SIMATIC CP 1242-7 V2 (6GK7242-7KX31-0XE0) (All versions < V3.4.29), SIMATIC CP 1243-1 (6GK7243-1BX30-0XE0) (All versions < V3.4.29), SIMATIC CP 1243-1 DNP3 (incl. SIPLUS variants) (All versions < V3.4.29), SIMATIC CP 1243-1 IEC (incl. SIPLUS variants) (All versions < V3.4.29), SIMATIC CP 1243-7 LTE EU (6GK7243-7KX30-0XE0) (All versions < V3.4.29), SIMATIC CP 1243-7 LTE US (6GK7243-7SX30-0XE0) (All versions < V3.4.29), SIMATIC CP 1243-8 IRC (6GK7243-8RX30-0XE0) (All versions < V3.4.29), SIMATIC CP 1542SP-1 (6GK7542-6UX00-0XE0) (All versions < V2.3), SIMATIC CP 1542SP-1 IRC (6GK7542-6VX00-0XE0) (All versions < V2.3), SIMATIC CP 1543SP-1 (6GK7543-6WX00-0XE0) (All versions < V2.3), SIMATIC CP 443-1 (6GK7443-1EX30-0XE0) (All versions < V3.3), SIMATIC CP 443-1 (6GK7443-1EX30-0XE1) (All versions < V3.3), SIMATIC CP 443-1 Advanced (6GK7443-1GX30-0XE0) (All versions < V3.3), SIPLUS ET 200SP CP 1542SP-1 IRC TX RAIL (6AG2542-6VX00-4XE0) (All versions < V2.3), SIPLUS ET 200SP CP 1543SP-1 ISEC (6AG1543-6WX00-7XE0) (All versions < V2.3), SIPLUS ET 200SP CP 1543SP-1 ISEC TX RAIL (6AG2543-6WX00-4XE0) (All versions < V2.3), SIPLUS NET CP 1242-7 V2 (6AG1242-7KX31-7XE0) (All versions < V3.4.29), SIPLUS NET CP 443-1 (6AG1443-1EX30-4XE0) (All versions < V3.3), SIPLUS NET CP 443-1 Advanced (6AG1443-1GX30-4XE0) (All versions < V3.3), SIPLUS S7-1200 CP 1243-1 (6AG1243-1BX30-2AX0) (All versions < V3.4.29), SIPLUS S7-1200 CP 1243-1 RAIL (6AG2243-1BX30-1XE0) (All versions < V3.4.29), SIPLUS TIM 1531 IRC (6AG1543-1MX00-7XE0) (All versions < V2.3.6), TIM 1531 IRC (6GK7543-1MX00-0XE0) (All versions < V2.3.6). The webserver of the affected products contains a vulnerability that may lead to a denial of service condition. An attacker may cause a denial of service situation which leads to a restart of the webserver of the affected product. | Fri 23 Oct |
| CVE-2022-43767 | 7.5 high | 1.0% | siemens, simatic_cp_1242-7_v2_firmware, simatic_cp_1243-1_firmware, simatic_cp_1243-1_dnp3_firmware | A vulnerability has been identified in SIMATIC CP 1242-7 V2 (6GK7242-7KX31-0XE0) (All versions < V3.4.29), SIMATIC CP 1243-1 (6GK7243-1BX30-0XE0) (All versions < V3.4.29), SIMATIC CP 1243-1 DNP3 (incl. SIPLUS variants) (All versions < V3.4.29), SIMATIC CP 1243-1 IEC (incl. SIPLUS variants) (All versions < V3.4.29), SIMATIC CP 1243-7 LTE EU (6GK7243-7KX30-0XE0) (All versions < V3.4.29), SIMATIC CP 1243-7 LTE US (6GK7243-7SX30-0XE0) (All versions < V3.4.29), SIMATIC CP 1243-8 IRC (6GK7243-8RX30-0XE0) (All versions < V3.4.29), SIMATIC CP 1542SP-1 (6GK7542-6UX00-0XE0) (All versions < V2.3), SIMATIC CP 1542SP-1 IRC (6GK7542-6VX00-0XE0) (All versions < V2.3), SIMATIC CP 1543SP-1 (6GK7543-6WX00-0XE0) (All versions < V2.3), SIMATIC CP 443-1 (6GK7443-1EX30-0XE0) (All versions < V3.3), SIMATIC CP 443-1 (6GK7443-1EX30-0XE1) (All versions < V3.3), SIMATIC CP 443-1 Advanced (6GK7443-1GX30-0XE0) (All versions < V3.3), SIPLUS ET 200SP CP 1542SP-1 IRC TX RAIL (6AG2542-6VX00-4XE0) (All versions < V2.3), SIPLUS ET 200SP CP 1543SP-1 ISEC (6AG1543-6WX00-7XE0) (All versions < V2.3), SIPLUS ET 200SP CP 1543SP-1 ISEC TX RAIL (6AG2543-6WX00-4XE0) (All versions < V2.3), SIPLUS NET CP 1242-7 V2 (6AG1242-7KX31-7XE0) (All versions < V3.4.29), SIPLUS NET CP 443-1 (6AG1443-1EX30-4XE0) (All versions < V3.3), SIPLUS NET CP 443-1 Advanced (6AG1443-1GX30-4XE0) (All versions < V3.3), SIPLUS S7-1200 CP 1243-1 (6AG1243-1BX30-2AX0) (All versions < V3.4.29), SIPLUS S7-1200 CP 1243-1 RAIL (6AG2243-1BX30-1XE0) (All versions < V3.4.29), SIPLUS TIM 1531 IRC (6AG1543-1MX00-7XE0) (All versions < V2.3.6), TIM 1531 IRC (6GK7543-1MX00-0XE0) (All versions < V2.3.6). The webserver of the affected products contains a vulnerability that may lead to a denial of service condition. An attacker may cause a denial of service situation of the webserver of the affected product. | Fri 23 Oct |
| CVE-2022-43768 | 7.5 high | 1.0% | siemens, simatic_cp_1242-7_v2_firmware, simatic_cp_1243-1_firmware, simatic_cp_1243-1_dnp3_firmware | A vulnerability has been identified in SIMATIC CP 1242-7 V2 (6GK7242-7KX31-0XE0) (All versions < V3.4.29), SIMATIC CP 1243-1 (6GK7243-1BX30-0XE0) (All versions < V3.4.29), SIMATIC CP 1243-1 DNP3 (incl. SIPLUS variants) (All versions < V3.4.29), SIMATIC CP 1243-1 IEC (incl. SIPLUS variants) (All versions < V3.4.29), SIMATIC CP 1243-7 LTE EU (6GK7243-7KX30-0XE0) (All versions < V3.4.29), SIMATIC CP 1243-7 LTE US (6GK7243-7SX30-0XE0) (All versions < V3.4.29), SIMATIC CP 1243-8 IRC (6GK7243-8RX30-0XE0) (All versions < V3.4.29), SIMATIC CP 1542SP-1 (6GK7542-6UX00-0XE0) (All versions < V2.3), SIMATIC CP 1542SP-1 IRC (6GK7542-6VX00-0XE0) (All versions < V2.3), SIMATIC CP 1543SP-1 (6GK7543-6WX00-0XE0) (All versions < V2.3), SIMATIC CP 443-1 (6GK7443-1EX30-0XE0) (All versions < V3.3), SIMATIC CP 443-1 (6GK7443-1EX30-0XE1) (All versions < V3.3), SIMATIC CP 443-1 Advanced (6GK7443-1GX30-0XE0) (All versions < V3.3), SIPLUS ET 200SP CP 1542SP-1 IRC TX RAIL (6AG2542-6VX00-4XE0) (All versions < V2.3), SIPLUS ET 200SP CP 1543SP-1 ISEC (6AG1543-6WX00-7XE0) (All versions < V2.3), SIPLUS ET 200SP CP 1543SP-1 ISEC TX RAIL (6AG2543-6WX00-4XE0) (All versions < V2.3), SIPLUS NET CP 1242-7 V2 (6AG1242-7KX31-7XE0) (All versions < V3.4.29), SIPLUS NET CP 443-1 (6AG1443-1EX30-4XE0) (All versions < V3.3), SIPLUS NET CP 443-1 Advanced (6AG1443-1GX30-4XE0) (All versions < V3.3), SIPLUS S7-1200 CP 1243-1 (6AG1243-1BX30-2AX0) (All versions < V3.4.29), SIPLUS S7-1200 CP 1243-1 RAIL (6AG2243-1BX30-1XE0) (All versions < V3.4.29), SIPLUS TIM 1531 IRC (6AG1543-1MX00-7XE0) (All versions < V2.3.6), TIM 1531 IRC (6GK7543-1MX00-0XE0) (All versions < V2.3.6). The webserver of the affected products contains a vulnerability that may lead to a denial of service condition. An attacker may cause a denial of service situation of the webserver of the affected product. | Fri 23 Oct |
| CVE-2026-19566 | 7.5 high | 1.0% | no CPE yet | Net::CIDR::Set versions before 0.23 for Perl allow memory exhaustion and malformed set ranges via unbounded IPv6 prefix lengths. The _encode method accepts any prefix length matching `(0|[1-9][0-9]*)` and passes it to _width2bits(), which builds the mask as `'1' x ($width + 8)`, one character per bit. The _inc() method then unpacks the packed mask into a Perl array of one scalar per byte, so the prefix length alone sets the allocation size: `::/100000000` builds a 100 MB string and a 12.5 million element array. The value being tested is parsed, not just the configured ranges: contains() builds a set from its argument, and _guess_coder() tries the IPv4 coder and then the IPv6 coder, so an IPv4-only set expands an oversized IPv6 prefix length before the mixed address width check rejects it. Any caller that passes untrusted input to contains() or add() can exhaust process memory. A prefix length above 128 is also stored as a range that does not match the requested block: 2001:db8::/129 stringifies back unchanged, contains() of its own base address returns false, and removing it from a set drops the base address while the set still prints as covering it. | Fri 23 Oct |
| CVE-2026-96960 | 7.5 high | 1.0% | microsoft, .net, .net_framework | Asymmetric resource consumption (amplification) in .NET allows an unauthorized attacker to deny service over a network. | Thu 22 Oct |
Download these 1000 as CSV (the first thousand in this order) · subscribe to this list.
EPSS scores: 2026-10-28. NVD cursor: 2026-10-29 00:22. The News page shows only notable CVEs (KEV, your stack, new criticals, EPSS over 50%, or active exploitation per SSVC); this table has all of them.