Export limit exceeded: 417100 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (107563 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2026-96522 | 3 Adobe, Apple, Microsoft | 3 Photoshop, Macos, Windows | 2026-10-16 | 7.8 High |
| Photoshop Desktop is affected by an out-of-bounds write vulnerability that could result in arbitrary code execution in the context of the current user. Exploitation of this issue requires user interaction in that a victim must open a malicious file. | ||||
| CVE-2026-96523 | 3 Adobe, Apple, Microsoft | 3 Photoshop, Macos, Windows | 2026-10-16 | 7.8 High |
| Photoshop Desktop is affected by an out-of-bounds write vulnerability that could result in arbitrary code execution in the context of the current user. Exploitation of this issue requires user interaction in that a victim must open a malicious file. | ||||
| CVE-2025-61662 | 2 Gnu, Redhat | 10 Grub2, Enterprise Linux, Enterprise Linux Eus and 7 more | 2026-10-16 | 7.8 High |
| A Use-After-Free vulnerability has been discovered in GRUB's gettext module. This flaw stems from a programming error where the gettext command remains registered in memory after its module is unloaded. An attacker can exploit this condition by invoking the orphaned command, causing the application to access a memory location that is no longer valid. An attacker could exploit this vulnerability to cause grub to crash, leading to a Denial of Service. Possible data integrity or confidentiality compromise is not discarded. | ||||
| CVE-2026-97748 | 1 Microsoft | 14 365 Apps, Microsoft 365, Microsoft 365 Apps For Enterprise and 11 more | 2026-10-16 | 8.8 High |
| Heap-based buffer overflow in Microsoft Office Excel allows an unauthorized attacker to execute code over a network. | ||||
| CVE-2026-97742 | 1 Microsoft | 14 365 Apps, Microsoft 365, Microsoft 365 Apps For Enterprise and 11 more | 2026-10-16 | 8.8 High |
| Stack-based buffer overflow in Microsoft Office Excel allows an unauthorized attacker to execute code over a network. | ||||
| CVE-2026-89603 | 1 Linux | 1 Linux Kernel | 2026-10-16 | 7.8 High |
| This CVE ID has been rejected or withdrawn by its CVE Numbering Authority. | ||||
| CVE-2026-85634 | 1 Redhat | 4 Jboss Enterprise Application Platform, Jboss Fuse, Jbosseapxp and 1 more | 2026-10-16 | 8.8 High |
| A flaw was found in the ContentRepositoryImpl.copyExplodedContent function of the wildfly-core library, which is used by WildFly and JBoss EAP to manage server deployments. The issue occurs when the library processes an unsanitized deployment name. Due to a missing containment check, an attacker with the Deployer RBAC role can use path traversal sequences to access files outside the restricted deployment directory. This can allow the attacker to delete arbitrary directories or create files with arbitrary content, leading to a full privilege escalation to the management SuperUser role. | ||||
| CVE-2026-110449 | 1 Nixos | 1 Nix | 2026-10-16 | 7.5 High |
| Nix before 2.35.3 and Lix before 2.95.4 have an integer overflow and resultant out-of-bounds write when evaluating untrusted expressions because list allocation is mishandled. | ||||
| CVE-2026-109468 | 1 Microsoft | 3 Microsoft Visual Studio 2026 Version 18.10, System.formats.cbor, Visual Studio 2022 | 2026-10-16 | 7.5 High |
| Allocation of resources without limits or throttling in ASP.NET Core allows an unauthorized attacker to deny service over a network. | ||||
| CVE-2026-98392 | 1 Linux | 1 Linux Kernel | 2026-10-15 | 7.0 High |
| In the Linux kernel, the following vulnerability has been resolved: Bluetooth: btintel_pcie: fix tx_handle bounds off-by-one Valid indices into txq->urbd0s/tfds/bufs are 0..txq->count-1, so tfd_index == txq->count is already out of range. Change the guard in btintel_pcie_msix_tx_handle() from '> txq->count' to '>= txq->count'. This issue was reported by Claude Mythos. | ||||
| CVE-2026-98403 | 1 Linux | 1 Linux Kernel | 2026-10-15 | 7.0 High |
| In the Linux kernel, the following vulnerability has been resolved: s390/boot: Avoid IPL parameter append past command line A command line may occupy all but the terminating byte of COMMAND_LINE_SIZE. In that case append_ipl_block_parm() passes a zero size to the IPL parameter conversion helpers and points the destination one byte past early_command_line. The helpers subtract one from the unsigned size and write the converted parameter outside the command line buffer. Convert the IPL parameter in the command line parsing buffer first. A parameter beginning with '=' can then replace the existing command line regardless of its length, while other parameters are appended only when space remains. | ||||
| CVE-2026-94449 | 1 Redhat | 5 Apicurio Registry, Camel Quarkus, Exploit Intelligence and 2 more | 2026-10-15 | 7.5 High |
| A flaw was found in the SmallRye Fault Tolerance library, which is used by Quarkus to provide strategies like retries and circuit breakers for microservices. The issue occurs when using the ApplyGuard or ApplyFaultTolerance annotations, where the library fails to release internal tracking objects after each request. This causes a steady increase in memory usage that eventually leads to the application slowing down and crashing due to lack of memory. | ||||
| CVE-2026-98426 | 1 Linux | 1 Linux Kernel | 2026-10-15 | 7.0 High |
| In the Linux kernel, the following vulnerability has been resolved: wifi: mwifiex: fix IRQ leak using wrong index in MSI-X error path mwifiex_pcie_request_irq() registers each MSI-X vector with a per-index dev_id (&card->msix_ctx[i]). On a request_irq() failure the cleanup loop "for (j = 0; j < i; j++)" frees msix_entries[j].vector but passes the failed index's &card->msix_ctx[i] as the dev_id. free_irq() matches on (irq, dev_id), so it fails to find the action registered with &card->msix_ctx[j]: the already-requested IRQ j is not freed (leaked) and free_irq() warns about freeing a non-existent IRQ. Use &card->msix_ctx[j]. | ||||
| CVE-2026-98430 | 1 Linux | 1 Linux Kernel | 2026-10-15 | 7.0 High |
| In the Linux kernel, the following vulnerability has been resolved: RDMA/efa: Keep admin queues alive while IRQ is registered The management IRQ handler accesses both the admin completion queue and the async event queue. The driver registered the IRQ before constructing these queues and destroyed them before freeing the IRQ, so the handler's lifetime was not contained by the resources it accesses. Initialize the queues with interrupts masked, request the IRQ, and then switch to interrupt mode. On removal, reset the device and free the IRQ before destroying the queues. Also reset the device before destroying the queues if IRQ registration fails, because the device already has their DMA addresses. | ||||
| CVE-2026-98428 | 1 Linux | 1 Linux Kernel | 2026-10-15 | 7.0 High |
| In the Linux kernel, the following vulnerability has been resolved: ALSA: usb: 6fire: Avoid embedded URBs The USB 6fire driver uses URBs embedded in different structs for PCM, MIDI and communication, and this is basically a buggy implementation nowadays; since a URB is managed with a refcount, this may lead to a UAF when the URB is released asynchronously. For addressing the problem, this patch converts those embedded URBs to ones that are properly allocated via usb_alloc_urb(). The pcm_urb.packets[] is gone, as it's allocated by usb_alloc_urb(), hence it's found in urb.iso_frame_desc[] instead. The conversions are rather straightforward; each embedded struct urb is changed to a pointer, and its callers are updated accordingly. The resource for those structs are released in the common destructor functions (usb6fire_comm_free(), etc), which are called at both the init error path and the disconnect. No functional changes, only compile-tested. | ||||
| CVE-2026-98429 | 1 Linux | 1 Linux Kernel | 2026-10-15 | 7.0 High |
| In the Linux kernel, the following vulnerability has been resolved: RDMA/efa: Keep EQ resources alive while IRQ is registered The completion IRQ handler accesses the EQ state and DMA buffer. Its IRQ was registered before that state was initialized, while teardown released the buffer before free_irq() synchronized the handler. Initialize the EQ without arming it, register the IRQ, and then arm it. Reverse the resource order during teardown by freeing the IRQ before destroying the EQ. | ||||
| CVE-2026-97801 | 1 Microsoft | 2 .net, .net Framework | 2026-10-15 | 7.5 High |
| Improper validation of specified type of input in .NET Framework allows an unauthorized attacker to perform tampering over a network. | ||||
| CVE-2026-88164 | 1 Microsoft | 1 Sharepoint Server | 2026-10-15 | 8.8 High |
| Missing authorization in Microsoft Office SharePoint allows an authorized attacker to elevate privileges over a network. | ||||
| CVE-2026-70183 | 1 Microsoft | 3 Asp.net Core, Microsoft Visual Studio 2026 Version 18.10, Visual Studio 2022 | 2026-10-15 | 7.5 High |
| Concurrent execution using shared resource with improper synchronization ('race condition') in ASP.NET Core allows an authorized attacker to elevate privileges over a network. | ||||
| CVE-2025-68304 | 1 Linux | 1 Linux Kernel | 2026-10-15 | 8.8 High |
| In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_core: lookup hci_conn on RX path on protocol side The hdev lock/lookup/unlock/use pattern in the packet RX path doesn't ensure hci_conn* is not concurrently modified/deleted. This locking appears to be leftover from before conn_hash started using RCU commit bf4c63252490b ("Bluetooth: convert conn hash to RCU") and not clear if it had purpose since then. Currently, there are code paths that delete hci_conn* from elsewhere than the ordered hdev->workqueue where the RX work runs in. E.g. commit 5af1f84ed13a ("Bluetooth: hci_sync: Fix UAF on hci_abort_conn_sync") introduced some of these, and there probably were a few others before it. It's better to do the locking so that even if these run concurrently no UAF is possible. Move the lookup of hci_conn and associated socket-specific conn to protocol recv handlers, and do them within a single critical section to cover hci_conn* usage and lookup. syzkaller has reported a crash that appears to be this issue: [Task hdev->workqueue] [Task 2] hci_disconnect_all_sync l2cap_recv_acldata(hcon) hci_conn_get(hcon) hci_abort_conn_sync(hcon) hci_dev_lock hci_dev_lock hci_conn_del(hcon) v-------------------------------- hci_dev_unlock hci_conn_put(hcon) conn = hcon->l2cap_data (UAF) | ||||