Export limit exceeded: 390737 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (98022 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2026-68812 | 1 Microsoft | 10 365 Apps, Excel, Excel 2016 and 7 more | 2026-08-13 | 7.8 High |
| Heap-based buffer overflow in Microsoft Office Excel allows an unauthorized attacker to execute code locally. | ||||
| CVE-2026-68805 | 1 Microsoft | 12 365 Apps, Excel, Excel 2016 and 9 more | 2026-08-13 | 7.8 High |
| Heap-based buffer overflow in Microsoft Office Excel allows an unauthorized attacker to execute code locally. | ||||
| CVE-2026-68804 | 1 Microsoft | 10 365 Apps, Excel, Excel 2016 and 7 more | 2026-08-13 | 7.8 High |
| Numeric truncation error in Microsoft Office Excel allows an unauthorized attacker to execute code locally. | ||||
| CVE-2026-68803 | 1 Microsoft | 10 365 Apps, Excel, Excel 2016 and 7 more | 2026-08-13 | 7.8 High |
| Access of resource using incompatible type ('type confusion') in Microsoft Office Excel allows an unauthorized attacker to execute code locally. | ||||
| CVE-2026-68801 | 1 Microsoft | 10 365 Apps, Excel, Excel 2016 and 7 more | 2026-08-13 | 7.8 High |
| Heap-based buffer overflow in Microsoft Office Excel allows an unauthorized attacker to execute code locally. | ||||
| CVE-2024-58366 | 2 Delskayn, Surrealdb | 2 Rquickjs, Surrealdb | 2026-08-13 | 8.5 High |
| SurrealDB before 1.1.1 contains a format string vulnerability in the rquickjs Exception::throw_type function when scripting is enabled. Attackers with scripting privileges can supply format string sequences in error inputs to read arbitrary memory or execute code with SurrealDB process privileges. | ||||
| CVE-2026-68816 | 1 Microsoft | 10 365 Apps, Excel, Excel 2016 and 7 more | 2026-08-13 | 7.8 High |
| Stack-based buffer overflow in Microsoft Office Excel allows an unauthorized attacker to execute code locally. | ||||
| CVE-2026-68811 | 1 Microsoft | 10 365 Apps, Excel, Excel 2016 and 7 more | 2026-08-13 | 7.8 High |
| Access of resource using incompatible type ('type confusion') in Microsoft Office Excel allows an unauthorized attacker to execute code locally. | ||||
| CVE-2026-68810 | 1 Microsoft | 11 365, 365 Apps, Excel and 8 more | 2026-08-13 | 7.8 High |
| Untrusted pointer dereference in Microsoft Office Excel allows an unauthorized attacker to execute code locally. | ||||
| CVE-2026-68806 | 1 Microsoft | 10 365 Apps, Excel, Excel 2016 and 7 more | 2026-08-13 | 7.8 High |
| Out-of-bounds write in Microsoft Office Excel allows an unauthorized attacker to execute code locally. | ||||
| CVE-2026-68796 | 1 Microsoft | 11 365, 365 Apps, Excel and 8 more | 2026-08-13 | 7.8 High |
| Heap-based buffer overflow in Microsoft Office Excel allows an unauthorized attacker to execute code locally. | ||||
| CVE-2026-68795 | 1 Microsoft | 13 365 Apps, Excel, Excel 2016 and 10 more | 2026-08-13 | 7.8 High |
| Stack-based buffer overflow in Microsoft Office Excel allows an unauthorized attacker to execute code locally. | ||||
| CVE-2026-68794 | 1 Microsoft | 10 365 Apps, Excel, Excel 2016 and 7 more | 2026-08-13 | 7.8 High |
| Heap-based buffer overflow in Microsoft Office Excel allows an unauthorized attacker to execute code locally. | ||||
| CVE-2026-62772 | 1 Microsoft | 2 Windows 11 26h1, Windows 11 26h1 | 2026-08-13 | 7.8 High |
| Heap-based buffer overflow in Windows Container Isolation FS Filter Driver (unionfs.sys) allows an authorized attacker to elevate privileges locally. | ||||
| CVE-2026-17022 | 2 Salonbookingsystem, Wordpress | 2 Salon Booking System, Wordpress | 2026-08-13 | 7.5 High |
| The Salon Booking System WordPress plugin before 10.30.34 does not properly validate a booking's ownership token before loading it in its booking-wizard confirmation steps, allowing unauthenticated attackers to disclose other customers' booking records, including personal information, by supplying a sequential booking identifier. | ||||
| CVE-2026-64281 | 1 Linux | 1 Linux Kernel | 2026-08-13 | 7.5 High |
| In the Linux kernel, the following vulnerability has been resolved: svcrdma: wake sq waiters when the transport closes Threads parked in svc_rdma_sq_wait() on sc_sq_ticket_wait or sc_send_wait can hang indefinitely in TASK_UNINTERRUPTIBLE state across transport teardown, pinning svc_xprt references and blocking svc_rdma_free(). The close path sets XPT_CLOSE before invoking xpo_detach and both wait_event predicates include an XPT_CLOSE term, but the predicates are re-evaluated only on wakeup. sc_sq_ticket_wait has no completion-driven wake path; it is advanced solely by the chained ticket handoff inside svc_rdma_sq_wait() itself. Without an explicit wake at close, parked threads never observe XPT_CLOSE, hold their svc_xprt_get reference forever, and svc_rdma_free() blocks on xpt_ref dropping to zero. Two close entry points reach this transport. Local teardown runs svc_rdma_detach() from svc_handle_xprt() -> svc_delete_xprt() -> xpo_detach() on a worker thread. A remote disconnect arrives at svc_rdma_cma_handler(), which calls svc_xprt_deferred_close(): that sets XPT_CLOSE and enqueues the transport but does not access either RDMA waitqueue, so a worker already parked in svc_rdma_sq_wait() never re-evaluates its predicate. With every worker parked on this transport, no thread is available to run the local teardown either, and the wake site there is unreachable. Introduce svc_rdma_xprt_deferred_close(), a thin svcrdma wrapper that calls svc_xprt_deferred_close() and then wakes both sc_sq_ticket_wait and sc_send_wait. Convert the svcrdma producers that called svc_xprt_deferred_close() directly: svc_rdma_cma_handler(), qp_event_handler(), svc_rdma_post_send_err(), svc_rdma_wc_send(), the sendto drop path, the rw completion error paths, and the recvfrom flush and read-list error paths. Wake both waitqueues from svc_rdma_detach() as well. The synchronous svc_xprt_close() path (backchannel ENOTCONN, device removal via svc_rdma_xprt_done) reaches detach without flowing through svc_xprt_deferred_close() and therefore does not invoke the new helper. [ cel: add svc_rdma_xprt_deferred_close() to complete the fix ] | ||||
| CVE-2026-46701 | 2 Jovancoding, Network-ai | 2 Network-ai, Network-ai | 2026-08-13 | 7.6 High |
| Network-AI is a TypeScript/Node.js multi-agent orchestrator. Prior to version 5.4.5, the MCP SSE server defaults to an empty secret (`process.env['NETWORK_AI_MCP_SECRET'] ?? ''` at `bin/mcp-server.ts:89`), which causes `_isAuthorized` (`lib/mcp-transport-sse.ts:254`) to return `true` unconditionally for every request — no `Authorization` header is required. Simultaneously, `_handleRequest` sets `Access-Control-Allow-Origin: *` (`lib/mcp-transport-sse.ts:272`) on every response, so a cross-origin browser fetch can read the result without restriction. An unauthenticated attacker who can lure a user to a malicious web page can invoke all 22 exposed MCP tools — including `config_set`, `agent_spawn`, and `blackboard_write` — against a default-configured localhost server. Version 5.4.5 patches the issue. | ||||
| CVE-2026-64176 | 1 Linux | 1 Linux Kernel | 2026-08-13 | 8.1 High |
| In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: mvm: fix driver-set TX rates on old devices On old devices such as 7265D, rates are still encoded in version 1 format, which doesn't use the CCK/OFDM rate index (0-3/0-7) but rather their PLCP value (e.g. 10 for 1 Mbps CCK rate.) While introducing v3 rates, I changed the driver from internally handling v1 rates and converting to v2, to internally handling v3 and converting to v1 or v2 according to the firmware. I accordingly changed the code in iwl_mvm_mac80211_idx_to_hwrate() to no longer have different values for different APIs. This was correct. However, I later reverted this part of the change, because it was reported that I had broken beacon rates, causing a FW assert/crash. This caused TX_CMD rates to be set incorrectly, potentially causing a warning when reported back from the device as having been used. Fix this (hopefully correctly now) by handling beacon rates in the TX_CMD that's embedded in the beacon template command separately. Restore iwl_mvm_mac80211_idx_to_hwrate() to return only the rate index, not PLCP value, fixing the real TX_CMD. | ||||
| CVE-2026-64175 | 1 Linux | 1 Linux Kernel | 2026-08-13 | 7.5 High |
| In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: mld: stop TX during firmware restart When iwlwifi firmware crashes (e.g., NMI_INTERRUPT_UNKNOWN on Intel BE201/Wi-Fi 7), iwl_mld_nic_error() sets mld->fw_status.in_hw_restart to true. However, iwl_mld_tx_from_txq() does not check this flag before dequeuing frames from mac80211 and pushing them to the transport layer. Since the firmware is dead, iwl_trans_tx() returns -EIO for each frame, which then gets freed immediately. Under high-throughput conditions (e.g., Tailscale UDP traffic or active SSH sessions), this creates a tight dequeue-send-fail-free loop that wastes CPU cycles and generates rapid skb allocation churn, leading to memory pressure from slab fragmentation. The RX path already has this guard (iwl_mld_rx_mpdu checks in_hw_restart at rx.c:1906), and so does the TXQ allocation worker (iwl_mld_add_txqs_wk at tx.c:156). Add the same guard to iwl_mld_tx_from_txq() to stop all TX during firmware restart. Frames left in mac80211's TXQs are naturally drained after restart completes, when queue reallocation triggers iwl_mld_tx_from_txq() via iwl_mld_add_txq_list(), or when new upper-layer traffic invokes wake_tx_queue. Tested on ASUS Zenbook 14 UX3405CA with Intel BE201 (Wi-Fi 7) on kernel 6.19.5 where the firmware crashes approximately every 10-15 minutes under Tailscale traffic. | ||||
| CVE-2026-64172 | 1 Linux | 1 Linux Kernel | 2026-08-13 | 7.1 High |
| In the Linux kernel, the following vulnerability has been resolved: KVM: SVM: Disable AVIC IPI virtualization on Hygon Family 18h (erratum #1235) Hygon Family 18h CPUs are derived from AMD Family 17h (Zen1) silicon and share the same erratum #1235: hardware may read a stale IsRunning=1 bit during ICR write emulation and silently fail to generate an AVIC_IPI_FAILURE_TARGET_NOT_RUNNING VM-Exit on the sending vCPU. The absence of the VM-Exit causes KVM to miss the required wakeup of blocking target vCPUs, leading to hung vCPUs and unbounded delays in guest execution. Extend the existing AMD Family 17h erratum #1235 workaround to also cover Hygon Family 18h. With IPI virtualization disabled, KVM never sets IsRunning=1 in the Physical ID table, so every non-self IPI generates a VM-Exit and is correctly emulated. | ||||