Export limit exceeded: 349905 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (349905 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2026-43203 | 1 Linux | 1 Linux Kernel | 2026-05-11 | 7.5 High |
| In the Linux kernel, the following vulnerability has been resolved: atm: fore200e: fix use-after-free in tasklets during device removal When the PCA-200E or SBA-200E adapter is being detached, the fore200e is deallocated. However, the tx_tasklet or rx_tasklet may still be running or pending, leading to use-after-free bug when the already freed fore200e is accessed again in fore200e_tx_tasklet() or fore200e_rx_tasklet(). One of the race conditions can occur as follows: CPU 0 (cleanup) | CPU 1 (tasklet) fore200e_pca_remove_one() | fore200e_interrupt() fore200e_shutdown() | tasklet_schedule() kfree(fore200e) | fore200e_tx_tasklet() | fore200e-> // UAF Fix this by ensuring tx_tasklet or rx_tasklet is properly canceled before the fore200e is released. Add tasklet_kill() in fore200e_shutdown() to synchronize with any pending or running tasklets. Moreover, since fore200e_reset() could prevent further interrupts or data transfers, the tasklet_kill() should be placed after fore200e_reset() to prevent the tasklet from being rescheduled in fore200e_interrupt(). Finally, it only needs to do tasklet_kill() when the fore200e state is greater than or equal to FORE200E_STATE_IRQ, since tasklets are uninitialized in earlier states. In a word, the tasklet_kill() should be placed in the FORE200E_STATE_IRQ branch within the switch...case structure. This bug was identified through static analysis. | ||||
| CVE-2026-28950 | 1 Apple | 3 Ios And Ipados, Ipados, Iphone Os | 2026-05-11 | 6.2 Medium |
| A logging issue was addressed with improved data redaction. This issue is fixed in iOS 15.8.8 and iPadOS 15.8.8, iOS 16.7.16 and iPadOS 16.7.16, iOS 18.7.8 and iPadOS 18.7.8, iOS 26.4.2 and iPadOS 26.4.2, iPadOS 17.7.11. Notifications marked for deletion could be unexpectedly retained on the device. | ||||
| CVE-2026-28877 | 1 Apple | 6 Ios And Ipados, Ipados, Iphone Os and 3 more | 2026-05-11 | 5.5 Medium |
| An authorization issue was addressed with improved state management. This issue is fixed in iOS 18.7.9 and iPadOS 18.7.9, iOS 26.4 and iPadOS 26.4, macOS Sequoia 15.7.5, macOS Sonoma 14.8.5, macOS Tahoe 26.4, visionOS 26.4, watchOS 26.4. An app may be able to access sensitive user data. | ||||
| CVE-2024-26971 | 1 Linux | 1 Linux Kernel | 2026-05-11 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: clk: qcom: gcc-ipq5018: fix terminating of frequency table arrays The frequency table arrays are supposed to be terminated with an empty element. Add such entry to the end of the arrays where it is missing in order to avoid possible out-of-bound access when the table is traversed by functions like qcom_find_freq() or qcom_find_freq_floor(). | ||||
| CVE-2024-26943 | 1 Linux | 1 Linux Kernel | 2026-05-11 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: nouveau/dmem: handle kcalloc() allocation failure The kcalloc() in nouveau_dmem_evict_chunk() will return null if the physical memory has run out. As a result, if we dereference src_pfns, dst_pfns or dma_addrs, the null pointer dereference bugs will happen. Moreover, the GPU is going away. If the kcalloc() fails, we could not evict all pages mapping a chunk. So this patch adds a __GFP_NOFAIL flag in kcalloc(). Finally, as there is no need to have physically contiguous memory, this patch switches kcalloc() to kvcalloc() in order to avoid failing allocations. | ||||
| CVE-2026-43204 | 1 Linux | 1 Linux Kernel | 2026-05-11 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: ASoC: qcom: q6asm: drop DSP responses for closed data streams 'Commit a354f030dbce ("ASoC: qcom: q6asm: handle the responses after closing")' attempted to ignore DSP responses arriving after a stream had been closed. However, those responses were still handled, causing lockups. Fix this by unconditionally dropping all DSP responses associated with closed data streams. | ||||
| CVE-2024-26876 | 1 Linux | 1 Linux Kernel | 2026-05-11 | 4.4 Medium |
| In the Linux kernel, the following vulnerability has been resolved: drm/bridge: adv7511: fix crash on irq during probe Moved IRQ registration down to end of adv7511_probe(). If an IRQ already is pending during adv7511_probe (before adv7511_cec_init) then cec_received_msg_ts could crash using uninitialized data: Unable to handle kernel read from unreadable memory at virtual address 00000000000003d5 Internal error: Oops: 96000004 [#1] PREEMPT_RT SMP Call trace: cec_received_msg_ts+0x48/0x990 [cec] adv7511_cec_irq_process+0x1cc/0x308 [adv7511] adv7511_irq_process+0xd8/0x120 [adv7511] adv7511_irq_handler+0x1c/0x30 [adv7511] irq_thread_fn+0x30/0xa0 irq_thread+0x14c/0x238 kthread+0x190/0x1a8 | ||||
| CVE-2024-26874 | 1 Linux | 1 Linux Kernel | 2026-05-11 | 4.4 Medium |
| In the Linux kernel, the following vulnerability has been resolved: drm/mediatek: Fix a null pointer crash in mtk_drm_crtc_finish_page_flip It's possible that mtk_crtc->event is NULL in mtk_drm_crtc_finish_page_flip(). pending_needs_vblank value is set by mtk_crtc->event, but in mtk_drm_crtc_atomic_flush(), it's is not guarded by the same lock in mtk_drm_finish_page_flip(), thus a race condition happens. Consider the following case: CPU1 CPU2 step 1: mtk_drm_crtc_atomic_begin() mtk_crtc->event is not null, step 1: mtk_drm_crtc_atomic_flush: mtk_drm_crtc_update_config( !!mtk_crtc->event) step 2: mtk_crtc_ddp_irq -> mtk_drm_finish_page_flip: lock mtk_crtc->event set to null, pending_needs_vblank set to false unlock pending_needs_vblank set to true, step 2: mtk_crtc_ddp_irq -> mtk_drm_finish_page_flip called again, pending_needs_vblank is still true //null pointer Instead of guarding the entire mtk_drm_crtc_atomic_flush(), it's more efficient to just check if mtk_crtc->event is null before use. | ||||
| CVE-2024-26867 | 1 Linux | 1 Linux Kernel | 2026-05-11 | 4.4 Medium |
| In the Linux kernel, the following vulnerability has been resolved: comedi: comedi_8255: Correct error in subdevice initialization The refactoring done in commit 5c57b1ccecc7 ("comedi: comedi_8255: Rework subdevice initialization functions") to the initialization of the io field of struct subdev_8255_private broke all cards using the drivers/comedi/drivers/comedi_8255.c module. Prior to 5c57b1ccecc7, __subdev_8255_init() initialized the io field in the newly allocated struct subdev_8255_private to the non-NULL callback given to the function, otherwise it used a flag parameter to select between subdev_8255_mmio and subdev_8255_io. The refactoring removed that logic and the flag, as subdev_8255_mm_init() and subdev_8255_io_init() now explicitly pass subdev_8255_mmio and subdev_8255_io respectively to __subdev_8255_init(), only __subdev_8255_init() never sets spriv->io to the supplied callback. That spriv->io is NULL leads to a later BUG: BUG: kernel NULL pointer dereference, address: 0000000000000000 PGD 0 P4D 0 Oops: 0010 [#1] SMP PTI CPU: 1 PID: 1210 Comm: systemd-udevd Not tainted 6.7.3-x86_64 #1 Hardware name: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX RIP: 0010:0x0 Code: Unable to access opcode bytes at 0xffffffffffffffd6. RSP: 0018:ffffa3f1c02d7b78 EFLAGS: 00010202 RAX: 0000000000000000 RBX: ffff91f847aefd00 RCX: 000000000000009b RDX: 0000000000000003 RSI: 0000000000000001 RDI: ffff91f840f6fc00 RBP: ffff91f840f6fc00 R08: 0000000000000000 R09: 0000000000000001 R10: 0000000000000000 R11: 000000000000005f R12: 0000000000000000 R13: 0000000000000000 R14: ffffffffc0102498 R15: ffff91f847ce6ba8 FS: 00007f72f4e8f500(0000) GS:ffff91f8d5c80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffffffffffffd6 CR3: 000000010540e000 CR4: 00000000000406f0 Call Trace: <TASK> ? __die_body+0x15/0x57 ? page_fault_oops+0x2ef/0x33c ? insert_vmap_area.constprop.0+0xb6/0xd5 ? alloc_vmap_area+0x529/0x5ee ? exc_page_fault+0x15a/0x489 ? asm_exc_page_fault+0x22/0x30 __subdev_8255_init+0x79/0x8d [comedi_8255] pci_8255_auto_attach+0x11a/0x139 [8255_pci] comedi_auto_config+0xac/0x117 [comedi] ? __pfx___driver_attach+0x10/0x10 pci_device_probe+0x88/0xf9 really_probe+0x101/0x248 __driver_probe_device+0xbb/0xed driver_probe_device+0x1a/0x72 __driver_attach+0xd4/0xed bus_for_each_dev+0x76/0xb8 bus_add_driver+0xbe/0x1be driver_register+0x9a/0xd8 comedi_pci_driver_register+0x28/0x48 [comedi_pci] ? __pfx_pci_8255_driver_init+0x10/0x10 [8255_pci] do_one_initcall+0x72/0x183 do_init_module+0x5b/0x1e8 init_module_from_file+0x86/0xac __do_sys_finit_module+0x151/0x218 do_syscall_64+0x72/0xdb entry_SYSCALL_64_after_hwframe+0x6e/0x76 RIP: 0033:0x7f72f50a0cb9 Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 47 71 0c 00 f7 d8 64 89 01 48 RSP: 002b:00007ffd47e512d8 EFLAGS: 00000246 ORIG_RAX: 0000000000000139 RAX: ffffffffffffffda RBX: 0000562dd06ae070 RCX: 00007f72f50a0cb9 RDX: 0000000000000000 RSI: 00007f72f52d32df RDI: 000000000000000e RBP: 0000000000000000 R08: 00007f72f5168b20 R09: 0000000000000000 R10: 0000000000000050 R11: 0000000000000246 R12: 00007f72f52d32df R13: 0000000000020000 R14: 0000562dd06785c0 R15: 0000562dcfd0e9a8 </TASK> Modules linked in: 8255_pci(+) comedi_8255 comedi_pci comedi intel_gtt e100(+) acpi_cpufreq rtc_cmos usbhid CR2: 0000000000000000 ---[ end trace 0000000000000000 ]--- RIP: 0010:0x0 Code: Unable to access opcode bytes at 0xffffffffffffffd6. RSP: 0018:ffffa3f1c02d7b78 EFLAGS: 00010202 RAX: 0000000000000000 RBX: ffff91f847aefd00 RCX: 000000000000009b RDX: 0000000000000003 RSI: 0000000000000001 RDI: ffff91f840f6fc00 RBP: ffff91f840f6fc00 R08: 0000000000000000 R09: 0000000000000001 R10: 0000000000000000 R11: 000000000000005f R12: 0000000000000000 R13: 0000000000000000 R14: ffffffffc0102498 R15: ffff91f847ce6ba8 FS: ---truncated--- | ||||
| CVE-2024-26862 | 2 Linux, Redhat | 2 Linux Kernel, Enterprise Linux | 2026-05-11 | 4.7 Medium |
| In the Linux kernel, the following vulnerability has been resolved: packet: annotate data-races around ignore_outgoing ignore_outgoing is read locklessly from dev_queue_xmit_nit() and packet_getsockopt() Add appropriate READ_ONCE()/WRITE_ONCE() annotations. syzbot reported: BUG: KCSAN: data-race in dev_queue_xmit_nit / packet_setsockopt write to 0xffff888107804542 of 1 bytes by task 22618 on cpu 0: packet_setsockopt+0xd83/0xfd0 net/packet/af_packet.c:4003 do_sock_setsockopt net/socket.c:2311 [inline] __sys_setsockopt+0x1d8/0x250 net/socket.c:2334 __do_sys_setsockopt net/socket.c:2343 [inline] __se_sys_setsockopt net/socket.c:2340 [inline] __x64_sys_setsockopt+0x66/0x80 net/socket.c:2340 do_syscall_64+0xd3/0x1d0 entry_SYSCALL_64_after_hwframe+0x6d/0x75 read to 0xffff888107804542 of 1 bytes by task 27 on cpu 1: dev_queue_xmit_nit+0x82/0x620 net/core/dev.c:2248 xmit_one net/core/dev.c:3527 [inline] dev_hard_start_xmit+0xcc/0x3f0 net/core/dev.c:3547 __dev_queue_xmit+0xf24/0x1dd0 net/core/dev.c:4335 dev_queue_xmit include/linux/netdevice.h:3091 [inline] batadv_send_skb_packet+0x264/0x300 net/batman-adv/send.c:108 batadv_send_broadcast_skb+0x24/0x30 net/batman-adv/send.c:127 batadv_iv_ogm_send_to_if net/batman-adv/bat_iv_ogm.c:392 [inline] batadv_iv_ogm_emit net/batman-adv/bat_iv_ogm.c:420 [inline] batadv_iv_send_outstanding_bat_ogm_packet+0x3f0/0x4b0 net/batman-adv/bat_iv_ogm.c:1700 process_one_work kernel/workqueue.c:3254 [inline] process_scheduled_works+0x465/0x990 kernel/workqueue.c:3335 worker_thread+0x526/0x730 kernel/workqueue.c:3416 kthread+0x1d1/0x210 kernel/kthread.c:388 ret_from_fork+0x4b/0x60 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:243 value changed: 0x00 -> 0x01 Reported by Kernel Concurrency Sanitizer on: CPU: 1 PID: 27 Comm: kworker/u8:1 Tainted: G W 6.8.0-syzkaller-08073-g480e035fc4c7 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/29/2024 Workqueue: bat_events batadv_iv_send_outstanding_bat_ogm_packet | ||||
| CVE-2024-26858 | 2 Linux, Redhat | 2 Linux Kernel, Enterprise Linux | 2026-05-11 | 4.1 Medium |
| In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: Use a memory barrier to enforce PTP WQ xmit submission tracking occurs after populating the metadata_map Just simply reordering the functions mlx5e_ptp_metadata_map_put and mlx5e_ptpsq_track_metadata in the mlx5e_txwqe_complete context is not good enough since both the compiler and CPU are free to reorder these two functions. If reordering does occur, the issue that was supposedly fixed by 7e3f3ba97e6c ("net/mlx5e: Track xmit submission to PTP WQ after populating metadata map") will be seen. This will lead to NULL pointer dereferences in mlx5e_ptpsq_mark_ts_cqes_undelivered in the NAPI polling context due to the tracking list being populated before the metadata map. | ||||
| CVE-2024-26856 | 1 Linux | 1 Linux Kernel | 2026-05-11 | 4.4 Medium |
| In the Linux kernel, the following vulnerability has been resolved: net: sparx5: Fix use after free inside sparx5_del_mact_entry Based on the static analyzis of the code it looks like when an entry from the MAC table was removed, the entry was still used after being freed. More precise the vid of the mac_entry was used after calling devm_kfree on the mac_entry. The fix consists in first using the vid of the mac_entry to delete the entry from the HW and after that to free it. | ||||
| CVE-2026-5720 | 1 Miniupnp Project | 1 Miniupnpd | 2026-05-11 | 9.1 Critical |
| miniupnpd contains an integer underflow vulnerability in SOAPAction header parsing that allows remote attackers to cause a denial of service or information disclosure by sending a malformed SOAPAction header with a single quote. Attackers can trigger an out-of-bounds memory read by exploiting improper length validation in ParseHttpHeaders(), where the parsed length underflows to a large unsigned value when passed to memchr(), causing the process to scan memory far beyond the allocated HTTP request buffer. | ||||
| CVE-2024-26850 | 1 Linux | 1 Linux Kernel | 2026-05-11 | 4.4 Medium |
| In the Linux kernel, the following vulnerability has been resolved: mm/debug_vm_pgtable: fix BUG_ON with pud advanced test Architectures like powerpc add debug checks to ensure we find only devmap PUD pte entries. These debug checks are only done with CONFIG_DEBUG_VM. This patch marks the ptes used for PUD advanced test devmap pte entries so that we don't hit on debug checks on architecture like ppc64 as below. WARNING: CPU: 2 PID: 1 at arch/powerpc/mm/book3s64/radix_pgtable.c:1382 radix__pud_hugepage_update+0x38/0x138 .... NIP [c0000000000a7004] radix__pud_hugepage_update+0x38/0x138 LR [c0000000000a77a8] radix__pudp_huge_get_and_clear+0x28/0x60 Call Trace: [c000000004a2f950] [c000000004a2f9a0] 0xc000000004a2f9a0 (unreliable) [c000000004a2f980] [000d34c100000000] 0xd34c100000000 [c000000004a2f9a0] [c00000000206ba98] pud_advanced_tests+0x118/0x334 [c000000004a2fa40] [c00000000206db34] debug_vm_pgtable+0xcbc/0x1c48 [c000000004a2fc10] [c00000000000fd28] do_one_initcall+0x60/0x388 Also kernel BUG at arch/powerpc/mm/book3s64/pgtable.c:202! .... NIP [c000000000096510] pudp_huge_get_and_clear_full+0x98/0x174 LR [c00000000206bb34] pud_advanced_tests+0x1b4/0x334 Call Trace: [c000000004a2f950] [000d34c100000000] 0xd34c100000000 (unreliable) [c000000004a2f9a0] [c00000000206bb34] pud_advanced_tests+0x1b4/0x334 [c000000004a2fa40] [c00000000206db34] debug_vm_pgtable+0xcbc/0x1c48 [c000000004a2fc10] [c00000000000fd28] do_one_initcall+0x60/0x388 | ||||
| CVE-2024-26802 | 2 Linux, Redhat | 2 Linux Kernel, Enterprise Linux | 2026-05-11 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: stmmac: Clear variable when destroying workqueue Currently when suspending driver and stopping workqueue it is checked whether workqueue is not NULL and if so, it is destroyed. Function destroy_workqueue() does drain queue and does clear variable, but it does not set workqueue variable to NULL. This can cause kernel/module panic if code attempts to clear workqueue that was not initialized. This scenario is possible when resuming suspended driver in stmmac_resume(), because there is no handling for failed stmmac_hw_setup(), which can fail and return if DMA engine has failed to initialize, and workqueue is initialized after DMA engine. Should DMA engine fail to initialize, resume will proceed normally, but interface won't work and TX queue will eventually timeout, causing 'Reset adapter' error. This then does destroy workqueue during reset process. And since workqueue is initialized after DMA engine and can be skipped, it will cause kernel/module panic. To secure against this possible crash, set workqueue variable to NULL when destroying workqueue. Log/backtrace from crash goes as follows: [88.031977]------------[ cut here ]------------ [88.031985]NETDEV WATCHDOG: eth0 (sxgmac): transmit queue 1 timed out [88.032017]WARNING: CPU: 0 PID: 0 at net/sched/sch_generic.c:477 dev_watchdog+0x390/0x398 <Skipping backtrace for watchdog timeout> [88.032251]---[ end trace e70de432e4d5c2c0 ]--- [88.032282]sxgmac 16d88000.ethernet eth0: Reset adapter. [88.036359]------------[ cut here ]------------ [88.036519]Call trace: [88.036523] flush_workqueue+0x3e4/0x430 [88.036528] drain_workqueue+0xc4/0x160 [88.036533] destroy_workqueue+0x40/0x270 [88.036537] stmmac_fpe_stop_wq+0x4c/0x70 [88.036541] stmmac_release+0x278/0x280 [88.036546] __dev_close_many+0xcc/0x158 [88.036551] dev_close_many+0xbc/0x190 [88.036555] dev_close.part.0+0x70/0xc0 [88.036560] dev_close+0x24/0x30 [88.036564] stmmac_service_task+0x110/0x140 [88.036569] process_one_work+0x1d8/0x4a0 [88.036573] worker_thread+0x54/0x408 [88.036578] kthread+0x164/0x170 [88.036583] ret_from_fork+0x10/0x20 [88.036588]---[ end trace e70de432e4d5c2c1 ]--- [88.036597]Unable to handle kernel NULL pointer dereference at virtual address 0000000000000004 | ||||
| CVE-2026-43209 | 1 Linux | 1 Linux Kernel | 2026-05-11 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: minix: Add required sanity checking to minix_check_superblock() The fs/minix implementation of the minix filesystem does not currently support any other value for s_log_zone_size than 0. This is also the only value supported in util-linux; see mkfs.minix.c line 511. In addition, this patch adds some sanity checking for the other minix superblock fields, and moves the minix_blocks_needed() checks for the zmap and imap also to minix_check_super_block(). This also closes a related syzbot bug report. | ||||
| CVE-2024-26631 | 2 Linux, Redhat | 2 Linux Kernel, Enterprise Linux | 2026-05-11 | 2.5 Low |
| In the Linux kernel, the following vulnerability has been resolved: ipv6: mcast: fix data-race in ipv6_mc_down / mld_ifc_work idev->mc_ifc_count can be written over without proper locking. Originally found by syzbot [1], fix this issue by encapsulating calls to mld_ifc_stop_work() (and mld_gq_stop_work() for good measure) with mutex_lock() and mutex_unlock() accordingly as these functions should only be called with mc_lock per their declarations. [1] BUG: KCSAN: data-race in ipv6_mc_down / mld_ifc_work write to 0xffff88813a80c832 of 1 bytes by task 3771 on cpu 0: mld_ifc_stop_work net/ipv6/mcast.c:1080 [inline] ipv6_mc_down+0x10a/0x280 net/ipv6/mcast.c:2725 addrconf_ifdown+0xe32/0xf10 net/ipv6/addrconf.c:3949 addrconf_notify+0x310/0x980 notifier_call_chain kernel/notifier.c:93 [inline] raw_notifier_call_chain+0x6b/0x1c0 kernel/notifier.c:461 __dev_notify_flags+0x205/0x3d0 dev_change_flags+0xab/0xd0 net/core/dev.c:8685 do_setlink+0x9f6/0x2430 net/core/rtnetlink.c:2916 rtnl_group_changelink net/core/rtnetlink.c:3458 [inline] __rtnl_newlink net/core/rtnetlink.c:3717 [inline] rtnl_newlink+0xbb3/0x1670 net/core/rtnetlink.c:3754 rtnetlink_rcv_msg+0x807/0x8c0 net/core/rtnetlink.c:6558 netlink_rcv_skb+0x126/0x220 net/netlink/af_netlink.c:2545 rtnetlink_rcv+0x1c/0x20 net/core/rtnetlink.c:6576 netlink_unicast_kernel net/netlink/af_netlink.c:1342 [inline] netlink_unicast+0x589/0x650 net/netlink/af_netlink.c:1368 netlink_sendmsg+0x66e/0x770 net/netlink/af_netlink.c:1910 ... write to 0xffff88813a80c832 of 1 bytes by task 22 on cpu 1: mld_ifc_work+0x54c/0x7b0 net/ipv6/mcast.c:2653 process_one_work kernel/workqueue.c:2627 [inline] process_scheduled_works+0x5b8/0xa30 kernel/workqueue.c:2700 worker_thread+0x525/0x730 kernel/workqueue.c:2781 ... | ||||
| CVE-2026-23866 | 1 Whatsapp | 3 Whatsapp, Whatsapp For Android, Whatsapp For Ios | 2026-05-11 | 4.3 Medium |
| Incomplete validation of AI rich response messages for Instagram Reels in WhatsApp for iOS v2.25.8.0 to v2.26.15.72 and WhatsApp for Android v2.25.8.0 to v2.26.7.10 could have allowed a user to trigger processing of media content from an arbitrary URL on another user’s device, including triggering OS-controlled custom URL scheme handlers. We have not seen evidence of exploitation in the wild. | ||||
| CVE-2025-71251 | 2 Google, Unisoc | 17 Android, Sc7731e, Sc9832e and 14 more | 2026-05-11 | 7.5 High |
| In IMS, there is a possible system crash due to improper input validation. This could lead to remote denial of service with no additional execution privileges needed. | ||||
| CVE-2026-34086 | 1 Wikimedia | 1 Abusefilter | 2026-05-11 | N/A |
| Vulnerability in Wikimedia Foundation AbuseFilter. This issue affects AbuseFilter: from * before 1.43.7, 1.44.4, 1.45.2. | ||||