Export limit exceeded: 10574 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Export limit exceeded: 28497 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Export limit exceeded: 419152 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Export limit exceeded: 419152 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Export limit exceeded: 419152 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (419152 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2026-114421 | 2026-11-04 | N/A | ||
| SEPPmail Secure Email Gateway before 15.1.1 permits password recovery for a created but unregistered GINA account whose initial password is empty without adequately verifying ownership. A remote unauthenticated attacker who identifies such an account can set a new password, authenticate as that account, and prevent the intended recipient from using it until recovery. | ||||
| CVE-2026-114420 | 2026-11-04 | N/A | ||
| SEPPmail Secure Email Gateway before 15.1.1 does not neutralize LDAP metacharacters in an unauthenticated account-selection input in its GINA web interface. A remote unauthenticated attacker can enumerate email addresses. | ||||
| CVE-2026-114425 | 2026-11-04 | N/A | ||
| SEPPmail Secure Email Gateway before 15.1.1 trusts a file path supplied in externally provided Large File Transfer attachment metadata. An unauthenticated remote sender can cause the mail-processing worker to disclose, move, or delete an accessible regular file when LFT is enabled and the message reaches an affected secure-mail processing path. The validated workers ran as root. | ||||
| CVE-2026-114426 | 2026-11-04 | N/A | ||
| SEPPmail Secure Email Gateway before 15.1.1 processes and writes v1 file-interface upload data before authenticating the caller and without an absolute request-size limit. An unauthenticated remote attacker can occupy workers and consume temporary storage with concurrent or slow requests, causing service unavailability. | ||||
| CVE-2026-114424 | 2026-11-04 | N/A | ||
| SEPPmail Secure Email Gateway before 15.1.1 can evaluate attacker-influenced replacement text as Perl code in sender or recipient replacement rules. An unauthenticated remote sender can execute operating-system commands in the mail-processing worker context when an active rule uses message-derived replacement data and its search condition matches. The validated worker context was root. | ||||
| CVE-2026-121035 | 1 Google | 1 Chrome | 2026-11-04 | 9.6 Critical |
| Use after free in Prerender in Google Chrome prior to 157.0.8103.38 allowed a remote attacker to execute arbitrary code outside the sandbox via a crafted HTML page. (Chromium security severity: Critical) | ||||
| CVE-2026-121052 | 1 Google | 1 Chrome | 2026-11-04 | 8.8 High |
| Use after free in GPU in Google Chrome prior to 157.0.8103.38 allowed a remote attacker to execute arbitrary code inside the sandbox via a crafted HTML page. (Chromium security severity: High) | ||||
| CVE-2026-121057 | 1 Google | 1 Chrome | 2026-11-04 | 8.8 High |
| Type confusion in V8 in Google Chrome prior to 157.0.8103.38 allowed a remote attacker to execute arbitrary code inside the sandbox via a crafted HTML page. (Chromium security severity: High) | ||||
| CVE-2026-121068 | 1 Google | 1 Chrome | 2026-11-04 | 8.8 High |
| Type confusion in V8 in Google Chrome prior to 157.0.8103.38 allowed a remote attacker to execute arbitrary code inside the sandbox via a crafted HTML page. (Chromium security severity: High) | ||||
| CVE-2026-121034 | 1 Google | 1 Chrome | 2026-11-04 | 9.6 Critical |
| Use after free in Views in Google Chrome on on Windows prior to 157.0.8103.38 allowed a remote attacker leveraging social engineering to execute arbitrary code outside the sandbox via a crafted HTML page. (Chromium security severity: High) | ||||
| CVE-2026-121060 | 1 Google | 1 Chrome | 2026-11-04 | 9.6 Critical |
| Incorrect authorization in FileSystem in Google Chrome prior to 157.0.8103.38 allowed a remote attacker leveraging social engineering to potentially execute arbitrary code outside the sandbox via a crafted HTML page. (Chromium security severity: High) | ||||
| CVE-2026-121070 | 1 Google | 1 Chrome | 2026-11-04 | 8.8 High |
| Use after free in WTF in Google Chrome prior to 157.0.8103.38 allowed a remote attacker to execute arbitrary code inside the sandbox via a crafted HTML page. (Chromium security severity: Medium) | ||||
| CVE-2026-121069 | 1 Google | 1 Chrome | 2026-11-04 | 8.8 High |
| Use after free in Track in Google Chrome prior to 157.0.8103.38 allowed a remote attacker to execute arbitrary code inside the sandbox via a crafted HTML page. (Chromium security severity: Low) | ||||
| CVE-2026-19731 | 2026-11-04 | 3.3 Low | ||
| Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal') vulnerability in TÜBİTAK BİLGEM Software Technologies Research Institute İmzager allows Path Traversal. This issue affects İmzager: from 2.10.5 before 2.10.7. | ||||
| CVE-2026-118403 | 1 Wordpress-extensions | 1 Premium Packages | 2026-11-04 | N/A |
| The Premium Packages WordPress plugin before 7.3.1 does not verify that the requester owns a guest order before returning its details, allowing unauthenticated visitors who know a guest order's identifier to view its order status, payment status and total. | ||||
| CVE-2026-118407 | 1 Wordpress-extensions | 1 Premium Packages | 2026-11-04 | N/A |
| The Premium Packages WordPress plugin before 7.3.1 does not verify that a user claiming a guest order is the original buyer, allowing any authenticated user to take ownership of any unclaimed guest order, and thereby read the buyer's billing details and download their purchased files, by supplying only the order identifier. | ||||
| CVE-2026-85036 | 1 Zephyrproject | 1 Zephyr | 2026-11-04 | 5.7 Medium |
| The Bluetooth Classic AVDTP layer defers releasing a session's stream endpoints: bt_avdtp_l2cap_disconnected() in subsys/bluetooth/host/classic/avdtp.c ends with k_work_submit(&session->_release_work), placing the embedded struct k_work on the system work queue's pending list. When the same struct bt_avdtp object is immediately reused for a new signalling connection, the session memory is re-initialized — a2dp_get_connection() in subsys/bluetooth/host/classic/a2dp.c memset()s the whole struct bt_a2dp, and bt_avdtp_l2cap_accept() / bt_avdtp_connect() call k_work_init() on session->_release_work — while that work item is still linked into k_sys_work_q.pending. Zeroing a linked sys_snode_t truncates the list while its tail pointer keeps pointing past the truncation. The reuse window is deterministic rather than a race. All host RX processing runs on the Bluetooth RX work queue at a cooperative priority (CONFIG_BT_RX_PRIO), while _release_work is submitted to the lower-priority system work queue, so the release handler cannot run until the RX thread blocks. Because l2cap_br_recv() processes every signalling command contained in a single L2CAP signalling PDU back-to-back, a peer can send one PDU holding an L2CAP Disconnection Request for the AVDTP signalling channel followed by a Connection Request for PSM 0x0019; the second command reaches the session-reuse path with the release work provably still queued. The peer must already hold an encrypted AVDTP signalling channel, i.e. be a paired/bonded BR/EDR device. The result is corruption of the global system work queue's pending list: either the queue silently stops executing any work at all (subsequent submissions are appended to a chain the head can no longer reach, and the orphaned items keep their K_WORK_QUEUED flag forever) or, in the tail variant, the list acquires a self-referencing node that the queue thread spins on. The written values are pointers to other struct k_work objects and are not attacker-controlled, so the impact is a device-wide, reboot-required denial of service rather than a controllable write primitive. Only builds with CONFIG_BT_CLASSIC and CONFIG_BT_A2DP are affected. The fix is a two-commit unit, and neither commit closes the path on its own. ec822ceed83b adds a pending-release check to bt_avdtp_connect() and bt_avdtp_l2cap_accept(), but the A2DP upper layer's a2dp_get_connection() memset()s the session — including the queued work item's list node and flags — before those checks run, so k_work_busy_get() would observe an already-cleared state. 2bd5ea88c69b closes that by making a2dp_get_connection() itself skip the reuse and return NULL while the release work is still pending, which both callers already handle by rejecting the connection attempt. Apply both commits together; either one alone leaves the device vulnerable. | ||||
| CVE-2026-87038 | 1 Zephyrproject | 1 Zephyr | 2026-11-04 | 7 High |
| The user-mode verification handler for the i3c_transfer() system call, z_vrfy_i3c_transfer() in drivers/i3c/i3c_handlers.c, validated the caller-supplied struct i3c_device_desc in place instead of snapshotting it. It confirmed only that the descriptor was readable by the calling thread (K_SYSCALL_MEMORY_READ()), read target->bus once to check it with K_SYSCALL_OBJ(), and then passed the caller's live pointer down. The implementation z_impl_i3c_transfer() re-reads target->bus from that user memory and dispatches through it as DEVICE_API_GET(i3c, target->bus)->i3c_xfers(...), so the bus that was validated is not necessarily the bus that is used. DEVICE_API_GET() performs no runtime type check outside CONFIG_DEVICE_API_ASSERT builds. On a build with CONFIG_USERSPACE and an I3C controller driver, a user thread that has been granted an I3C device object can exploit this with a second thread in the same memory domain: one thread calls i3c_transfer() while the other rewrites the bus field of the descriptor. The window between the check and the use spans the num_msgs validation, the message-array access check, a stack VLA allocation and a memcpy() of up to 32 struct i3c_msg, so the race is repeatable and can simply be retried until it lands. When the substitution succeeds, the kernel dereferences an attacker-chosen pointer as a struct device, loads a function pointer from the attacker-controlled api table and calls it in supervisor mode with attacker-influenced arguments. This yields kernel-mode code execution from an unprivileged user thread — a complete escape of the userspace memory-protection sandbox; lesser outcomes are an arbitrary two-level kernel read or a kernel fault. Builds without CONFIG_USERSPACE, or without an I3C driver, are unaffected. The fix copies the descriptor into a kernel-stack local with k_usermode_from_copy(), validates the bus in that copy, and dispatches on the copy, so the validated value is provably the value used. | ||||
| CVE-2026-87039 | 1 Zephyrproject | 1 Zephyr | 2026-11-04 | 7.8 High |
| The user-mode syscall verifier z_vrfy_i2s_configure() in drivers/i2s/i2s_handlers.c copies the caller's struct i2s_config in from user memory and then, when cfg->frame_clk_freq is 0 (the API's "unconfigure the stream" request), jumps straight to z_impl_i2s_configure() without performing the K_SYSCALL_OBJ(config.mem_slab, K_OBJ_MEM_SLAB) ownership/type check or the block_size sanity check. The mem_slab field is a struct k_mem_slab *, so on that path a completely unvalidated, user-chosen pointer reaches driver code that is entitled to trust it as a real kernel object. Any thread running under CONFIG_USERSPACE that has access to an I2S device object can trigger this with a single i2s_configure() call. Most in-tree drivers special-case frame_clk_freq == 0 and never store the caller's structure, but drivers/i2s/i2s_litex.c does not: i2s_litex_configure() only logs a warning for a mismatched frame clock, then memcpy()s the caller's config into stream->cfg and marks the stream I2S_STATE_READY. A subsequent i2s_trigger() with I2S_TRIGGER_START enables the FIFO interrupt, and the interrupt handlers i2s_litex_isr_rx() / i2s_litex_isr_tx() then call k_mem_slab_alloc() and k_mem_slab_free() on the attacker-supplied pointer in supervisor context. The result is an arbitrary-pointer read/write primitive executed by the kernel on behalf of an unprivileged thread — k_mem_slab_alloc() takes a spinlock at slab->lock and reads and writes slab->free_list and the link word inside the returned "block" — which defeats the CONFIG_USERSPACE isolation boundary entirely. The same missing validation is a hazard for out-of-tree I2S drivers that retain the configuration on the unconfigure path. Builds without CONFIG_USERSPACE are unaffected, since the verifier is not used. The fix zeroes config.mem_slab and config.block_size on the unconfigure path so the driver can never receive an unvalidated pointer, while still allowing a stream to be unconfigured by a caller that does not own a memory slab, as the API documents. | ||||
| CVE-2026-87040 | 1 Zephyrproject | 1 Zephyr | 2026-11-04 | 8.3 High |
| The nRF link-layer receive paths of the open-source Bluetooth LE Controller did not validate the on-air LENGTH field of a received PDU against the maximum receive length that was used to program the radio. isr_rx_pdu() in subsys/bluetooth/controller/ll_sw/nordic/lll/lll_conn.c enqueued any non-empty data PDU after only the sequence-number and (for encrypted links) MIC checks, and the corresponding isr_rx() handlers in lll_central_iso.c, lll_peripheral_iso.c, lll_sync_iso.c and lll_scan_aux.c did the same for ISO and extended-advertising PDUs. The nRF radio stores the received header verbatim and truncates only the payload at PCNF1.MAXLEN, so a frame declaring more octets than were configured leaves a node buffer whose len field describes more data than the buffer holds. An attacker within radio range that can emit a hand-crafted link-layer PDU — for a connection, any peer that establishes an unencrypted LE connection to a connectable advertiser; for CONFIG_BT_CTLR_SYNC_ISO, any broadcaster the device is synchronised to — can set the length byte up to 255 while the controller has programmed a much smaller maximum (lll->dle.eff.max_rx_octets, which is 27 until a Data Length Update, or the negotiated cis_lll->rx.max_pdu). No pairing, authentication or user interaction is required. On encrypted links the CCM MIC check normally rejects such a frame first, so the exposure is on unencrypted traffic, which is why the added check is placed after decryption. The unchecked length reaches hci_acl_encode() in subsys/bluetooth/controller/hci/hci.c, which performs net_buf_add(buf, pdu_data->len) followed by a memcpy() of that many bytes out of the node_rx pool element. Because CONFIG_BT_CTLR_DATA_LENGTH_MAX and CONFIG_BT_BUF_ACL_RX_SIZE both default to 27, this is an out-of-bounds read of up to roughly 228 bytes past the received PDU and a corresponding out-of-bounds write past the HCI ACL buffer into neighbouring buffers of the same pool; the tailroom test in net_buf_simple_add() is only enforced when CONFIG_NET_BUF_HARDENING (or CONFIG_ASSERT) is enabled. On the ISO paths the same unchecked length makes isoal_rx_append_to_sdu() read past the ISO node buffer and emit adjacent controller RAM to the host as ISO data. The practical result is remote memory corruption and controller crashes, plus disclosure of controller memory into the host data path. The fix rejects any received PDU whose length exceeds the value that was used to configure the radio reception. Note that lll_sync.c (periodic advertising sync reception) was not changed and still enqueues received PDUs without an equivalent bound. | ||||