Export limit exceeded: 79196 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (79196 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2025-45058 | 1 Dlink | 2 Di-8300, Di-8300 Firmware | 2026-04-13 | 7.5 High |
| D-Link DI-8300 v16.07.26A1 was discovered to contain a buffer overflow via the fx parameter in the jingx_asp function. This vulnerability allows attackers to cause a Denial of Service (DoS) via a crafted input. | ||||
| CVE-2025-50667 | 2 D-link, Dlink | 3 Di-8003, Di-8003, Di-8003 Firmware | 2026-04-13 | 7.5 High |
| A buffer overflow vulnerability exists in D-Link DI-8003 16.07.26A1 due to improper handling of the iface parameter in the /wan_line_detection.asp endpoint. | ||||
| CVE-2025-50668 | 1 Dlink | 2 Di-8003, Di-8003 Firmware | 2026-04-13 | 7.5 High |
| A buffer overflow vulnerability exists in D-Link DI-8003 16.07.26A1 due to improper handling of the s parameter in the /web_list_opt.asp endpoint. | ||||
| CVE-2025-50669 | 2 D-link, Dlink | 4 Di-8003, Di-8003g, Di-8003 and 1 more | 2026-04-13 | 7.5 High |
| A buffer overflow vulnerability exists in D-Link DI-8003 16.07.26A1 and DI-8003G 19.12.10A1 due to improper handling of the wan_ping parameter in the /wan_ping.asp endpoint. | ||||
| CVE-2025-50670 | 2 D-link, Dlink | 3 Di-8003, Di-8003, Di-8003 Firmware | 2026-04-13 | 7.5 High |
| A buffer overflow vulnerability exists in D-Link DI-8003 16.07.26A1 due to improper handling of parameters in the /xwgl_bwr.asp endpoint. An attacker can exploit this vulnerability by sending a crafted HTTP GET request in the name, qq, and time parameters. | ||||
| CVE-2025-50672 | 1 Dlink | 2 Di-8003, Di-8003 Firmware | 2026-04-13 | 7.5 High |
| A buffer overflow vulnerability exists in D-Link DI-8003 16.07.26A1 due to improper handling of parameters in the /yyxz_dlink.asp endpoint. | ||||
| CVE-2026-23869 | 1 Facebook | 3 React-server-dom-parcel, React-server-dom-turbopack, React-server-dom-webpack | 2026-04-13 | 7.5 High |
| A denial of service vulnerability exists in React Server Components, affecting the following packages: react-server-dom-parcel, react-server-dom-turbopack and react-server-dom-webpack (versions 19.0.0 through 19.0.4, 19.1.0 through 19.1.5, and 19.2.0 through 19.2.4). The vulnerability is triggered by sending specially crafted HTTP requests to Server Function endpoints.The payload of the HTTP request causes excessive CPU usage for up to a minute ending in a thrown error that is catchable. | ||||
| CVE-2026-35525 | 2 Harttle, Liquidjs | 2 Liquidjs, Liquidjs | 2026-04-13 | 7.5 High |
| LiquidJS is a Shopify / GitHub Pages compatible template engine in pure JavaScript. Prior to 10.25.3, for {% include %}, {% render %}, and {% layout %}, LiquidJS checks whether the candidate path is inside the configured partials or layouts roots before reading it. That check is path-based, not realpath-based. Because of that, a file like partials/link.liquid passes the directory containment check as long as its pathname is under the allowed root. If link.liquid is actually a symlink to a file outside the allowed root, the filesystem follows the symlink when the file is opened and LiquidJS renders the external target. So the restriction is applied to the path string that was requested, not to the file that is actually read. This matters in environments where an attacker can place templates or otherwise influence files under a trusted template root, including uploaded themes, extracted archives, mounted content, or repository-controlled template trees. This vulnerability is fixed in 10.25.3. | ||||
| CVE-2026-39859 | 2 Harttle, Liquidjs | 2 Liquidjs, Liquidjs | 2026-04-13 | 7.5 High |
| LiquidJS is a Shopify / GitHub Pages compatible template engine in pure JavaScript. Prior to 10.25.3, liquidjs 10.25.0 documents root as constraining filenames passed to renderFile() and parseFile(), but top-level file loads do not enforce that boundary. A Liquid instance configured with an empty temporary directory as root can return the contents of arbitrary files. This vulnerability is fixed in 10.25.3. | ||||
| CVE-2026-23471 | 1 Linux | 1 Linux Kernel | 2026-04-13 | 7.0 High |
| This CVE ID has been rejected or withdrawn by its CVE Numbering Authority. | ||||
| CVE-2026-21381 | 1 Qualcomm | 207 Ar8035, Ar8035 Firmware, Cologne and 204 more | 2026-04-13 | 7.6 High |
| Transient DOS when receiving a service data frame with excessive length during device matching over a neighborhood awareness network protocol connection. | ||||
| CVE-2026-1519 | 1 Isc | 1 Bind | 2026-04-13 | 7.5 High |
| If a BIND resolver is performing DNSSEC validation and encounters a maliciously crafted zone, the resolver may consume excessive CPU. Authoritative-only servers are generally unaffected, although there are circumstances where authoritative servers may make recursive queries (see: https://kb.isc.org/docs/why-does-my-authoritative-server-make-recursive-queries). This issue affects BIND 9 versions 9.11.0 through 9.16.50, 9.18.0 through 9.18.46, 9.20.0 through 9.20.20, 9.21.0 through 9.21.19, 9.11.3-S1 through 9.16.50-S1, 9.18.11-S1 through 9.18.46-S1, and 9.20.9-S1 through 9.20.20-S1. | ||||
| CVE-2026-31411 | 1 Linux | 1 Linux Kernel | 2026-04-13 | 7.0 High |
| In the Linux kernel, the following vulnerability has been resolved: net: atm: fix crash due to unvalidated vcc pointer in sigd_send() Reproducer available at [1]. The ATM send path (sendmsg -> vcc_sendmsg -> sigd_send) reads the vcc pointer from msg->vcc and uses it directly without any validation. This pointer comes from userspace via sendmsg() and can be arbitrarily forged: int fd = socket(AF_ATMSVC, SOCK_DGRAM, 0); ioctl(fd, ATMSIGD_CTRL); // become ATM signaling daemon struct msghdr msg = { .msg_iov = &iov, ... }; *(unsigned long *)(buf + 4) = 0xdeadbeef; // fake vcc pointer sendmsg(fd, &msg, 0); // kernel dereferences 0xdeadbeef In normal operation, the kernel sends the vcc pointer to the signaling daemon via sigd_enq() when processing operations like connect(), bind(), or listen(). The daemon is expected to return the same pointer when responding. However, a malicious daemon can send arbitrary pointer values. Fix this by introducing find_get_vcc() which validates the pointer by searching through vcc_hash (similar to how sigd_close() iterates over all VCCs), and acquires a reference via sock_hold() if found. Since struct atm_vcc embeds struct sock as its first member, they share the same lifetime. Therefore using sock_hold/sock_put is sufficient to keep the vcc alive while it is being used. Note that there may be a race with sigd_close() which could mark the vcc with various flags (e.g., ATM_VF_RELEASED) after find_get_vcc() returns. However, sock_hold() guarantees the memory remains valid, so this race only affects the logical state, not memory safety. [1]: https://gist.github.com/mrpre/1ba5949c45529c511152e2f4c755b0f3 | ||||
| CVE-2026-31395 | 1 Linux | 1 Linux Kernel | 2026-04-13 | 7.0 High |
| In the Linux kernel, the following vulnerability has been resolved: bnxt_en: fix OOB access in DBG_BUF_PRODUCER async event handler The ASYNC_EVENT_CMPL_EVENT_ID_DBG_BUF_PRODUCER handler in bnxt_async_event_process() uses a firmware-supplied 'type' field directly as an index into bp->bs_trace[] without bounds validation. The 'type' field is a 16-bit value extracted from DMA-mapped completion ring memory that the NIC writes directly to host RAM. A malicious or compromised NIC can supply any value from 0 to 65535, causing an out-of-bounds access into kernel heap memory. The bnxt_bs_trace_check_wrap() call then dereferences bs_trace->magic_byte and writes to bs_trace->last_offset and bs_trace->wrapped, leading to kernel memory corruption or a crash. Fix by adding a bounds check and defining BNXT_TRACE_MAX as DBG_LOG_BUFFER_FLUSH_REQ_TYPE_ERR_QPC_TRACE + 1 to cover all currently defined firmware trace types (0x0 through 0xc). | ||||
| CVE-2026-31394 | 1 Linux | 1 Linux Kernel | 2026-04-13 | 7.0 High |
| In the Linux kernel, the following vulnerability has been resolved: mac80211: fix crash in ieee80211_chan_bw_change for AP_VLAN stations ieee80211_chan_bw_change() iterates all stations and accesses link->reserved.oper via sta->sdata->link[link_id]. For stations on AP_VLAN interfaces (e.g. 4addr WDS clients), sta->sdata points to the VLAN sdata, whose link never participates in chanctx reservations. This leaves link->reserved.oper zero-initialized with chan == NULL, causing a NULL pointer dereference in __ieee80211_sta_cap_rx_bw() when accessing chandef->chan->band during CSA. Resolve the VLAN sdata to its parent AP sdata using get_bss_sdata() before accessing link data. [also change sta->sdata in ARRAY_SIZE even if it doesn't matter] | ||||
| CVE-2026-23306 | 1 Linux | 1 Linux Kernel | 2026-04-13 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: scsi: pm8001: Fix use-after-free in pm8001_queue_command() Commit e29c47fe8946 ("scsi: pm8001: Simplify pm8001_task_exec()") refactors pm8001_queue_command(), however it introduces a potential cause of a double free scenario when it changes the function to return -ENODEV in case of phy down/device gone state. In this path, pm8001_queue_command() updates task status and calls task_done to indicate to upper layer that the task has been handled. However, this also frees the underlying SAS task. A -ENODEV is then returned to the caller. When libsas sas_ata_qc_issue() receives this error value, it assumes the task wasn't handled/queued by LLDD and proceeds to clean up and free the task again, resulting in a double free. Since pm8001_queue_command() handles the SAS task in this case, it should return 0 to the caller indicating that the task has been handled. | ||||
| CVE-2026-23294 | 1 Linux | 1 Linux Kernel | 2026-04-13 | 7 High |
| In the Linux kernel, the following vulnerability has been resolved: bpf: Fix race in devmap on PREEMPT_RT On PREEMPT_RT kernels, the per-CPU xdp_dev_bulk_queue (bq) can be accessed concurrently by multiple preemptible tasks on the same CPU. The original code assumes bq_enqueue() and __dev_flush() run atomically with respect to each other on the same CPU, relying on local_bh_disable() to prevent preemption. However, on PREEMPT_RT, local_bh_disable() only calls migrate_disable() (when PREEMPT_RT_NEEDS_BH_LOCK is not set) and does not disable preemption, which allows CFS scheduling to preempt a task during bq_xmit_all(), enabling another task on the same CPU to enter bq_enqueue() and operate on the same per-CPU bq concurrently. This leads to several races: 1. Double-free / use-after-free on bq->q[]: bq_xmit_all() snapshots cnt = bq->count, then iterates bq->q[0..cnt-1] to transmit frames. If preempted after the snapshot, a second task can call bq_enqueue() -> bq_xmit_all() on the same bq, transmitting (and freeing) the same frames. When the first task resumes, it operates on stale pointers in bq->q[], causing use-after-free. 2. bq->count and bq->q[] corruption: concurrent bq_enqueue() modifying bq->count and bq->q[] while bq_xmit_all() is reading them. 3. dev_rx/xdp_prog teardown race: __dev_flush() clears bq->dev_rx and bq->xdp_prog after bq_xmit_all(). If preempted between bq_xmit_all() return and bq->dev_rx = NULL, a preempting bq_enqueue() sees dev_rx still set (non-NULL), skips adding bq to the flush_list, and enqueues a frame. When __dev_flush() resumes, it clears dev_rx and removes bq from the flush_list, orphaning the newly enqueued frame. 4. __list_del_clearprev() on flush_node: similar to the cpumap race, both tasks can call __list_del_clearprev() on the same flush_node, the second dereferences the prev pointer already set to NULL. The race between task A (__dev_flush -> bq_xmit_all) and task B (bq_enqueue -> bq_xmit_all) on the same CPU: Task A (xdp_do_flush) Task B (ndo_xdp_xmit redirect) ---------------------- -------------------------------- __dev_flush(flush_list) bq_xmit_all(bq) cnt = bq->count /* e.g. 16 */ /* start iterating bq->q[] */ <-- CFS preempts Task A --> bq_enqueue(dev, xdpf) bq->count == DEV_MAP_BULK_SIZE bq_xmit_all(bq, 0) cnt = bq->count /* same 16! */ ndo_xdp_xmit(bq->q[]) /* frames freed by driver */ bq->count = 0 <-- Task A resumes --> ndo_xdp_xmit(bq->q[]) /* use-after-free: frames already freed! */ Fix this by adding a local_lock_t to xdp_dev_bulk_queue and acquiring it in bq_enqueue() and __dev_flush(). These paths already run under local_bh_disable(), so use local_lock_nested_bh() which on non-RT is a pure annotation with no overhead, and on PREEMPT_RT provides a per-CPU sleeping lock that serializes access to the bq. | ||||
| CVE-2026-23288 | 1 Linux | 1 Linux Kernel | 2026-04-13 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: accel/amdxdna: Fix out-of-bounds memset in command slot handling The remaining space in a command slot may be smaller than the size of the command header. Clearing the command header with memset() before verifying the available slot space can result in an out-of-bounds write and memory corruption. Fix this by moving the memset() call after the size validation. | ||||
| CVE-2026-23280 | 1 Linux | 1 Linux Kernel | 2026-04-13 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: accel/amdxdna: Prevent ubuf size overflow The ubuf size calculation may overflow, resulting in an undersized allocation and possible memory corruption. Use check_add_overflow() helpers to validate the size calculation before allocation. | ||||
| CVE-2026-23278 | 1 Linux | 1 Linux Kernel | 2026-04-13 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: always walk all pending catchall elements During transaction processing we might have more than one catchall element: 1 live catchall element and 1 pending element that is coming as part of the new batch. If the map holding the catchall elements is also going away, its required to toggle all catchall elements and not just the first viable candidate. Otherwise, we get: WARNING: ./include/net/netfilter/nf_tables.h:1281 at nft_data_release+0xb7/0xe0 [nf_tables], CPU#2: nft/1404 RIP: 0010:nft_data_release+0xb7/0xe0 [nf_tables] [..] __nft_set_elem_destroy+0x106/0x380 [nf_tables] nf_tables_abort_release+0x348/0x8d0 [nf_tables] nf_tables_abort+0xcf2/0x3ac0 [nf_tables] nfnetlink_rcv_batch+0x9c9/0x20e0 [..] | ||||