Total
8686 CVE
| CVE | Vendors | Products | Updated | CVSS v2 | CVSS v3 |
|---|---|---|---|---|---|
| CVE-2026-57238 | 2 Foxit, Microsoft | 3 Pdf Editor, Pdf Reader, Windows | 2026-07-09 | N/A | 7.8 HIGH |
| After the application opened the PDF, JavaScript deleted the form field object. Subsequently, it attempted to access the invalid object, which caused the application to crash. | |||||
| CVE-2026-57242 | 2 Foxit, Microsoft | 3 Pdf Editor, Pdf Reader, Windows | 2026-07-09 | N/A | 7.8 HIGH |
| The application opens the PDF, and JavaScript modifies the form. However, the related objects on the page lack complete lifecycle management and null value validation; when the page state changes, the application continuously dereferences invalid objects, eventually leading to a crash. | |||||
| CVE-2026-13126 | 2 Foxit, Microsoft | 3 Pdf Editor, Pdf Reader, Windows | 2026-07-09 | N/A | 7.8 HIGH |
| The embedded JavaScript in the PDF deleted the pages, making the object invalid. The application attempted to perform a write operation on the invalid pop-up annotations, resulting in the program crashing. | |||||
| CVE-2026-57237 | 3 Apple, Foxit, Microsoft | 4 Macos, Pdf Editor, Pdf Reader and 1 more | 2026-07-09 | N/A | 7.8 HIGH |
| When the application opens a PDF and JavaScript modifies the properties of form fields, it causes the state of the underlying objects referenced by the program to become invalid. Eventually, it reads an illegal memory address, which leads to the crash of the application. | |||||
| CVE-2026-57244 | 3 Apple, Foxit, Microsoft | 4 Macos, Pdf Editor, Pdf Reader and 1 more | 2026-07-09 | N/A | 7.8 HIGH |
| After JavaScript resetting the form, the synchronization process lacks re-entry protection and object lifecycle verification, resulting in the failure of the control pointer during the traversal process. After the pointer fails, it still continues to dereference, causing the application to crash. | |||||
| CVE-2026-13129 | 2 Foxit, Microsoft | 3 Pdf Editor, Pdf Reader, Windows | 2026-07-09 | N/A | 7.8 HIGH |
| When the application opens a PDF file, JavaScript uses the damaged field tree to trigger field traversal, resulting in the program holding an invalid form object when accessing the field property path. Eventually, the application crashes due to reading an invalid pointer. | |||||
| CVE-2026-13128 | 2 Foxit, Microsoft | 3 Pdf Editor, Pdf Reader, Windows | 2026-07-09 | N/A | 7.8 HIGH |
| Embedding JavaScript within a PDF file will cause the page to be deleted. Subsequent scripts will continue to access the relevant properties of the document view, eventually leading to the crash of the application. | |||||
| CVE-2026-13127 | 2 Foxit, Microsoft | 3 Pdf Editor, Pdf Reader, Windows | 2026-07-09 | N/A | 7.8 HIGH |
| The application opens the PDF file. JavaScript then rewrites the document to modify the page structure, resulting in the invalidation of the page objects. However, the thumbnails still use the invalid page objects, ultimately causing the application to crash. | |||||
| CVE-2026-57245 | 2 Foxit, Microsoft | 3 Pdf Editor, Pdf Reader, Windows | 2026-07-09 | N/A | 7.8 HIGH |
| When the application opens a PDF, traverses and builds the annotation elements related to hyperlinks, it fails to validate the abnormal annotation relationships and field combinations. This results in the internal objects entering an invalid state. Eventually, during the destruction phase, an invalid pointer write occurred, causing the application to crash. | |||||
| CVE-2026-57250 | 3 Apple, Foxit, Microsoft | 4 Macos, Pdf Editor, Pdf Reader and 1 more | 2026-07-09 | N/A | 7.8 HIGH |
| When the application opens a PDF and JavaScript resets the form fields, the script re-enters the interface. The underlying native object is damaged, but the application does not perform validation. The function call on the damaged object leads to the application crashing. | |||||
| CVE-2026-57247 | 3 Apple, Foxit, Microsoft | 4 Macos, Pdf Editor, Pdf Reader and 1 more | 2026-07-09 | N/A | 7.8 HIGH |
| The application re-enters the document structure via field processing and deletes the current page, and then continues using the field objects obtained before deletion, triggering an illegal read and crashing. | |||||
| CVE-2026-57249 | 2 Foxit, Microsoft | 3 Pdf Editor, Pdf Reader, Windows | 2026-07-09 | N/A | 7.8 HIGH |
| After the application opened the PDF file, the script first reset the annotation status, then triggered the reset form event by additional action. During the re-entry process, the application access invalid objects and crashed. | |||||
| CVE-2026-57252 | 2 Foxit, Microsoft | 3 Pdf Editor, Pdf Reader, Windows | 2026-07-09 | N/A | 7.8 HIGH |
| When the application opens a PDF file, during the process of JavaScript deleting pages and removing attachment annotations, it will cause the attachment panel to continue accessing invalid pointers, eventually leading to the application crashing. | |||||
| CVE-2023-30186 | 1 Onlyoffice | 1 Document Server | 2026-07-09 | N/A | 9.8 CRITICAL |
| A use after free issue discovered in ONLYOFFICE DocumentServer 4.0.3 through 7.3.2 allows remote attackers to run arbitrary code via crafted JavaScript file. | |||||
| CVE-2020-27418 | 1 Fedoraproject | 1 Fedora Linux Kernel | 2026-07-09 | N/A | 4.4 MEDIUM |
| A Use After Free vulnerability in Fedora Linux kernel 5.9.0-rc9 allows attackers to obatin sensitive information via vgacon_invert_region() function. | |||||
| CVE-2026-48090 | 1 Envoyproxy | 1 Envoy | 2026-07-08 | N/A | 5.9 MEDIUM |
| Envoy is an open source edge and service proxy designed for cloud-native applications. From 1.37.0 until 1.37.5 and 1.38.3, the HTTP OAuth2 filter (envoy.filters.http.oauth2) can leave an in-flight async token exchange attached to a downstream stream that has already been torn down. A late AsyncClient completion can still invoke OAuth2Filter methods that use StreamDecoderFilterCallbacks after that object’s lifetime has ended, causing undefined behavior, worker crashes (availability loss), and use-after-free / invalid-vptr failures under AddressSanitizer. This is a memory-safety / lifetime issue in the data plane, not a trivial config bug. Remote code execution is not claimed here; the primary demonstrated impact is DoS via crash and UB; any further impact would be deployment- and allocator-dependent. This vulnerability is fixed in 1.37.5 and 1.38.3. | |||||
| CVE-2026-53234 | 1 Linux | 1 Linux Kernel | 2026-07-08 | N/A | 7.8 HIGH |
| In the Linux kernel, the following vulnerability has been resolved: net: ibm: emac: Fix use-after-free during device removal The driver was using devm_register_netdev() which causes unregister_netdev() to be deferred until the devres cleanup phase, which runs after emac_remove() returns. This creates a use-after-free window where: 1. emac_remove() is called, which tears down hardware (cancels work, detaches modules, unregisters from MAL) 2. emac_remove() returns 3. devres cleanup runs and finally calls unregister_netdev() During step 3, the network stack might still process packets, triggering emac_irq(), emac_poll(), or other handlers that access now-freed hardware resources (dev->emacp, dev->mal, etc.). Fix this by replacing devm_register_netdev() with manual register_netdev() and calling unregister_netdev() at the beginning of emac_remove(), before any hardware teardown. This ensures the network device is fully stopped and unregistered before hardware resources are released. The change is safe because: - dev->ndev is assigned very early in probe (before any error paths that could bypass emac_remove) - platform_set_drvdata() is only called after successful registration, so emac_remove() only runs for fully registered devices - unregister_netdev() is idempotent and safe to call on any registered device | |||||
| CVE-2026-53256 | 1 Linux | 1 Linux Kernel | 2026-07-08 | N/A | 8.0 HIGH |
| In the Linux kernel, the following vulnerability has been resolved: Bluetooth: RFCOMM: hold listener socket in rfcomm_connect_ind() rfcomm_get_sock_by_channel() scans rfcomm_sk_list under the list lock, but returns the selected listener after dropping that lock without taking a reference. rfcomm_connect_ind() then locks the listener, queues a child socket on it, and may notify it after unlocking it. The buggy scenario involves two paths, with each column showing the order within that path: rfcomm_connect_ind(): listener close: 1. Find parent in 1. close() enters rfcomm_get_sock_by_channel() rfcomm_sock_release(). 2. Drop rfcomm_sk_list.lock 2. rfcomm_sock_shutdown() without pinning parent. closes the listener. 3. Call lock_sock(parent) and 3. rfcomm_sock_kill() bt_accept_enqueue(parent, unlinks and puts parent. sk, true). 4. Read parent flags and may 4. parent can be freed. call sk_state_change(). If close wins the race, parent can be freed before rfcomm_connect_ind() reaches lock_sock(), bt_accept_enqueue(), or the deferred-setup callback. Take a reference on the listener before leaving rfcomm_sk_list.lock. After lock_sock() succeeds, recheck that it is still in BT_LISTEN before queueing a child, cache the deferred-setup bit while the parent is locked, and drop the reference after the last parent use. KASAN reported a slab-use-after-free in lock_sock_nested() from rfcomm_connect_ind(), with the freeing stack going through rfcomm_sock_kill() and rfcomm_sock_release(). | |||||
| CVE-2026-53259 | 1 Linux | 1 Linux Kernel | 2026-07-08 | N/A | 7.8 HIGH |
| In the Linux kernel, the following vulnerability has been resolved: ipv6: anycast: insert aca into global hash under idev->lock syzbot reported a splat [1]: a slab-use-after-free in ipv6_chk_acast_addr(), which walks the global inet6_acaddr_lst[] hash under RCU and dereferences a struct ifacaddr6 that has already been freed while still linked in the hash, so a later reader walks into a dangling node. In __ipv6_dev_ac_inc() the aca is allocated with refcount 1, then aca_get() bumps it to 2 to keep it alive across the unlocked region. It is published to idev->ac_list under idev->lock, but ipv6_add_acaddr_hash() runs after write_unlock_bh(). A concurrent teardown (ipv6_ac_destroy_dev() from addrconf_ifdown(), under RTNL) can slip into that window: CPU0 __ipv6_dev_ac_inc CPU1 ipv6_ac_destroy_dev (RTNL) ------------------------------ ------------------------------------ aca_alloc() refcnt 1 aca_get() refcnt 2 write_lock_bh(idev->lock) add aca to ac_list write_unlock_bh(idev->lock) write_lock_bh(idev->lock) pull aca off ac_list write_unlock_bh(idev->lock) ipv6_del_acaddr_hash(aca) hlist_del_init_rcu() is a no-op, aca is not in the hash yet aca_put() refcnt 2->1 ipv6_add_acaddr_hash(aca) aca now inserted into the hash aca_put() refcnt 1->0 call_rcu(aca_free_rcu) -> kfree(aca) The hash removal becomes a no-op because the insertion has not happened yet, so once CPU0 inserts and drops the last reference, the aca is freed while still linked in inet6_acaddr_lst[], and readers dereference freed memory after the slab slot is reused. This window opened once RTNL stopped serializing the join path against device teardown. Move ipv6_add_acaddr_hash() inside the idev->lock section so the ac_list and hash insertions are atomic with respect to teardown: a racing remover now either misses the aca entirely or finds it in both lists. acaddr_hash_lock is now nested under idev->lock, which is acquired in softirq context, so switch all acaddr_hash_lock sites to spin_lock_bh() to avoid the irq lock inversion reported in [2]. [1] https://syzkaller.appspot.com/bug?extid=a01df04303c131efbf3a [2] https://lore.kernel.org/netdev/6a194ef7.ba3b1513.1890b4.0000.GAE@google.com/ | |||||
| CVE-2026-53240 | 1 Linux | 1 Linux Kernel | 2026-07-08 | N/A | 8.8 HIGH |
| In the Linux kernel, the following vulnerability has been resolved: xfrm: iptfs: fix use-after-free on first_skb in __input_process_payload __input_process_payload() stores first_skb into xtfs->ra_newskb under drop_lock when starting partial reassembly, then unlocks and breaks out of the processing loop. The post-loop check reads xtfs->ra_newskb without the lock to decide whether first_skb is still owned: if (first_skb && first_iplen && !defer && first_skb != xtfs->ra_newskb) Between spin_unlock and this read, a concurrent CPU running iptfs_reassem_cont() (or the drop_timer hrtimer) can complete reassembly, NULL xtfs->ra_newskb, and free the skb. The check then evaluates first_skb != NULL as true, and pskb_trim/ip_summed/consume_skb operate on the freed skb — a use-after-free in skbuff_head_cache. Replace the unlocked read with a local bool that records whether first_skb was handed to the reassembly state in the current call. The flag is set after the existing spin_unlock, before the break, using the pointer equality that is stable at that point (first_skb == skb iff first_skb was stored in ra_newskb). | |||||