Export limit exceeded: 419085 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Export limit exceeded: 419085 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Export limit exceeded: 419085 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (419085 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2026-113187 | 1 Google | 1 Chrome | 2026-11-04 | 8.8 High |
| Missing authorization in DOM in Google Chrome prior to 156.0.8078.47 allowed a remote attacker to obtain cross-origin data via a crafted HTML page. (Chromium security severity: Medium) | ||||
| CVE-2026-113099 | 1 Google | 2 Android, Chrome | 2026-11-04 | 8.8 High |
| Confused deputy in Omnibox in Google Chrome on on Android prior to 156.0.8078.47 allowed a local attacker leveraging social engineering to obtain sensitive information via a co-installed app. (Chromium security severity: Medium) | ||||
| CVE-2026-113087 | 1 Google | 1 Chrome | 2026-11-04 | 8.8 High |
| Use after free in Actor in Google Chrome prior to 156.0.8078.47 allowed a remote attacker leveraging social engineering to execute arbitrary code inside the sandbox via a crafted HTML page. (Chromium security severity: Medium) | ||||
| CVE-2026-113267 | 1 Google | 1 Chrome | 2026-11-04 | 8.8 High |
| Uninitialized resource in Video in Google Chrome prior to 156.0.8078.47 allowed a remote attacker to read memory inside the sandbox via a crafted HTML page. (Chromium security severity: Medium) | ||||
| CVE-2026-113304 | 1 Google | 2 Android, Chrome | 2026-11-04 | 6.5 Medium |
| Uninitialized resource in GPU in Google Chrome on on Android prior to 156.0.8078.47 allowed a remote attacker to read memory outside the sandbox via a crafted HTML page. (Chromium security severity: Medium) | ||||
| CVE-2026-113030 | 1 Google | 1 Chrome | 2026-11-04 | 8.8 High |
| Use of uninitialized variable in V8 in Google Chrome prior to 156.0.8078.47 allowed a remote attacker to execute arbitrary code inside the sandbox via a crafted HTML page. (Chromium security severity: Medium) | ||||
| CVE-2026-113065 | 1 Google | 1 Chrome | 2026-11-04 | 8.8 High |
| Improper input validation in Media in Google Chrome prior to 156.0.8078.47 allowed a remote attacker to potentially execute arbitrary code outside the sandbox via a crafted media file. (Chromium security severity: Medium) | ||||
| CVE-2026-113002 | 1 Google | 1 Chrome | 2026-11-04 | 6.5 Medium |
| Incorrect authorization in Transactions Platform in Google Chrome prior to 156.0.8078.47 allowed a remote attacker leveraging social engineering to obtain sensitive information via a crafted HTML page. (Chromium security severity: Medium) | ||||
| CVE-2026-113170 | 1 Google | 2 Android, Chrome | 2026-11-04 | 8.8 High |
| UI misrepresentation in Autofill in Google Chrome on on Android prior to 156.0.8078.47 allowed a remote attacker to spoof address bar via a crafted HTML page. (Chromium security severity: Medium) | ||||
| CVE-2026-113096 | 1 Google | 2 Android, Chrome | 2026-11-04 | 8.8 High |
| UI misrepresentation in Text in Google Chrome on on Android prior to 156.0.8078.47 allowed a remote attacker who had compromised the renderer process to spoof address bar via a crafted HTML page. (Chromium security severity: Medium) | ||||
| CVE-2026-113184 | 1 Google | 1 Chrome | 2026-11-04 | 8.8 High |
| Missing authorization in Scheduling in Google Chrome prior to 156.0.8078.47 allowed a remote attacker to obtain sensitive information via a crafted HTML page. (Chromium security severity: Low) | ||||
| CVE-2026-113047 | 1 Google | 1 Chrome | 2026-11-04 | 6.5 Medium |
| Missing authorization in BrowserTag in Google Chrome prior to 156.0.8078.47 allowed a remote attacker who had compromised the renderer process to leak cross-origin data via a crafted HTML page. (Chromium security severity: Low) | ||||
| CVE-2026-113038 | 1 Google | 1 Chrome | 2026-11-04 | 6.5 Medium |
| Race condition in DevTools in Google Chrome prior to 156.0.8078.47 allowed a remote attacker leveraging social engineering to bypass system access restrictions via a crafted HTML page. (Chromium security severity: Low) | ||||
| CVE-2026-113132 | 1 Google | 1 Chrome | 2026-11-04 | 8.8 High |
| Incorrect authorization in DevTools in Google Chrome prior to 156.0.8078.47 allowed a remote attacker leveraging social engineering to bypass web origin policy via a crafted HTML page. (Chromium security severity: Low) | ||||
| CVE-2026-113063 | 1 Google | 1 Chrome | 2026-11-04 | 8.8 High |
| Clickjacking in Chromoting in Google Chrome prior to 156.0.8078.47 allowed a remote attacker leveraging social engineering to spoof UI elements via crafted network traffic. (Chromium security severity: Low) | ||||
| CVE-2026-113067 | 1 Google | 1 Chrome | 2026-11-04 | 8.8 High |
| UI misrepresentation in Chromoting in Google Chrome prior to 156.0.8078.47 allowed a remote attacker leveraging social engineering to spoof UI elements via crafted network traffic. (Chromium security severity: Low) | ||||
| CVE-2026-87044 | 2026-11-04 | 6.5 Medium | ||
| The Mbed TLS crypto shim driver in drivers/crypto/crypto_mbedtls_shim.c drives PSA multipart cipher and AEAD operations. In mbedtls_cbc() and mbedtls_aead(), every error path after a successful psa_cipher_encrypt_setup() / psa_aead_decrypt_setup() returned directly without calling psa_cipher_abort() / psa_aead_abort(). Because the abort is the only thing that reaches mbedtls_cipher_free(), each failed operation permanently leaked the heap-allocated mbedtls_aes_context (roughly 288 bytes) that setup had allocated from Mbed TLS's fixed static heap (_mbedtls_heap[CONFIG_MBEDTLS_HEAP_SIZE], default 512 bytes). With CONFIG_PSA_CRYPTO_PROVIDER_TFM the leaked object is instead a finite secure-partition multipart-operation slot. The failure is chosen by an unauthenticated attacker. With CONFIG_NET_L2_IEEE802154_SECURITY backed by this driver, ieee802154_decrypt_auth() in subsys/net/l2/ieee802154/ieee802154_security.c invokes cipher_ccm_op() on every received secured frame, with no authentication ahead of the MIC check. A device in radio range can transmit a stream of syntactically valid 802.15.4 frames carrying a bogus MIC; each one makes psa_aead_verify() fail and leaks a block. The CBC path is reachable the same way through the OSDP secure channel, where CONFIG_OSDP_SC_ENABLED selects this shim and osdp_encrypt() / osdp_decrypt() leave out_buf_max unset, so every operation fails inside psa_cipher_update(). Exhausting the Mbed TLS heap — which the default configuration reaches after a couple of failed operations, and any realistic configuration reaches in well under a second of frames — makes all subsequent mbedtls_calloc() calls fail. Every later cryptographic operation in the image then fails permanently, including link-layer security and any TLS/DTLS sharing the same heap, until the device is rebooted. There is no memory corruption or information disclosure: frames with an invalid MIC are still rejected, so the impact is limited to availability. The fix routes all post-setup failures in mbedtls_cbc() and mbedtls_aead() through a common error: label that calls the matching PSA abort before returning. Setup failures need no change, since the PSA core aborts the operation itself when setup fails. | ||||
| CVE-2026-87043 | 2026-11-04 | 4.8 Medium | ||
| The entropy-device random number generator in subsys/random/random_entropy_device.c returned early with -ENODEV from rand_get() as soon as device_is_ready() failed, before reaching the non-cryptographic system-timer fallback further down the same function. Because z_impl_sys_rand_get() returns void and discards that error — and the public sys_rand_get() syscall is itself declared void, so it cannot report failure — the caller's output buffer was left untouched and its previous contents were handed back as random data. The thin wrappers make this a plain uninitialized read: sys_rand32_get() declares uint32_t ret;, calls sys_rand_get(&ret, sizeof(ret)) and returns ret. The "not ready" state is a normal runtime condition rather than a fault. Entropy drivers initialise at PRE_KERNEL_1 with CONFIG_ENTROPY_INIT_PRIORITY (default 50), so any earlier initialiser — kernel objects run at priority 30 — observes an unready device; the sibling generator subsys/random/random_xoshiro128.c and z_early_rand_get() in kernel/init.c both already carried an explicit timer fallback for exactly this case. The state is also permanent for the boot when an entropy driver's init hook fails, which several in-tree drivers can do on real hardware (entropy_stm32 on an RNG clock configuration error, entropy_psa_crypto when psa_crypto_init() fails, entropy_nrf_cracen, entropy_esp32, entropy_virtio). When this occurs, every non-cryptographic random value in the system is either a constant or stale memory. coap_next_token() in subsys/net/lib/coap/coap.c fills a static buffer, so every CoAP token becomes the same .bss constant; tcp_init_isn() in subsys/net/ip/tcp.c returns an uninitialized stack word as the TCP initial sequence number; DHCPv4/DHCPv6 transaction IDs, WebSocket masking keys and RTP SSRCs are similarly degraded, and arch/arm64/core/pac.c derives per-thread Pointer Authentication keys from the same source. Where the bytes are transmitted directly — SSH packet padding, the netmidi2 session nonce, a DTLS connection ID on builds without CONFIG_CSPRNG_ENABLED — stale caller stack or heap contents are disclosed on the wire. The fix initialises ret to -ENODEV and only calls entropy_get_entropy() when the device is ready, so the not-ready case now falls through to the timer fallback and the buffer is always written. The cryptographically secure path is unchanged: sys_csrand_get() still propagates the error to the caller and never silently degrades. An attacker cannot induce the unready state, but can observe and exploit the resulting non-random values remotely on an affected device. | ||||
| CVE-2026-87041 | 2026-11-04 | 7.8 High | ||
| The RTIO submission-queue verifier rtio_vrfy_sqe() in subsys/rtio/rtio_syscalls.c (subsys/rtio/rtio_handlers.c before v4.3.0) accumulated the results of K_SYSCALL_MEMORY() into its valid_sqe flag with &=. That macro returns nonzero on failure (it is built on K_SYSCALL_VERIFY_MSG(), which yields !(expr)), so every buffer permission check contributed the opposite of its result. A submission whose tx.buf, rx.buf or txrx.tx_buf/txrx.rx_buf pointer was not accessible to the calling thread was accepted, while a legitimate, thread-owned buffer caused the calling thread to be killed with a kernel oops. The verifier runs on behalf of the rtio_sqe_copy_in_get_handles() system call (also reached through the inline rtio_sqe_copy_in() wrapper), so it is driven directly by untrusted user-mode input on any image built with CONFIG_USERSPACE. A user thread that has been granted an RTIO context and an rtio_iodev object — the intended usage of RTIO userspace support, established via rtio_access_grant() — can submit an SQE whose buffer pointer and length name arbitrary kernel memory; the object check on sqe->iodev is unaffected and still passes, and the crafted SQE is forwarded to the bus driver unchanged. Downstream consumers dereference the pointer with supervisor privilege. The generic I2C and I3C RTIO fallback handlers (drivers/i2c/i2c_rtio_default.c, drivers/i3c/i3c_rtio_default.c) copy sqe.rx.buf/sqe.tx.buf into struct i2c_msg and call i2c_transfer(), and the vendor SPI/I2C RTIO drivers behave equivalently. An RTIO_OP_RX submission therefore has peripheral data written into kernel memory of the attacker's choosing (arbitrary kernel write), an RTIO_OP_TX submission clocks kernel memory out over the bus (kernel memory disclosure), and a pointer to unmapped memory faults the kernel. This is a full escape from the user-mode isolation boundary that CONFIG_USERSPACE exists to enforce. The defect was masked for years because the in-tree user-mode RTIO tests only exercise RTIO_OP_NOP and mempool-backed reads, neither of which reaches the affected checks. The fix negates each K_SYSCALL_MEMORY() result and additionally validates the TXRX transmit buffer read-only, matching the SPI, I2C and I3C handlers. | ||||
| CVE-2026-87040 | 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. | ||||