Export limit exceeded: 399587 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (399587 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2026-84782 | 2 Openssl, Redhat | 2 Openssl, Hummingbird | 2026-09-29 | 8.2 High |
| Issue summary: The DTLS retransmission logic does not correctly handle a handshake message write that is suspended part-way through. The retransmitted message can be read past the message buffer and the retransmission overwrites the internal state the suspended write needs to resume correctly. Impact summary: The retransmitted message can disclose a heap memory to the peer as plaintext handshake data or cause a crash and a Denial of Service when the read reaches an unmapped memory region. CWE: CWE-125: Out-of-bounds Read Description: DTLS handshake messages can be written out in multiple fragments, and a write can suspend mid-message (returning WANT_WRITE) if the underlying transport temporarily cannot accept more data. While such a write is suspended, the DTLS retransmission timer may independently fire and ask the retransmission logic to resend an earlier, already-acknowledged-as-sent message from its retransmit queue. The retransmission logic reused the same internal buffer and position tracking as the message that was still being written, without resetting the position back to the start of the message being retransmitted. As a result the retransmission was read starting from wherever the suspended write had left off, producing a mislabelled message whose body was leftover bytes from the other, larger message still in flight - content that was never meant to be sent at that point, and which could run past the end of the allocated buffer. Separately, even when the retransmission is positioned correctly, allowing it to run to completion while another write is suspended overwrites the same shared bookkeeping that the suspended write depends on to resume. When the application later resumes the suspended write (via a subsequent SSL_read(), SSL_write(), SSL_accept(), or SSL_connect() call), it finds that bookkeeping in a state inconsistent with the message and aborts the process in a debugging build. The fix resets the retransmission's read position to the start of the message before resending, and skips retransmission entirely whenever a handshake write is still suspended, deferring to the next call that resumes it instead. FIPS impact: no The affected code is outside the FIPS module boundary. | ||||
| CVE-2026-95296 | 1 Google | 1 Chrome | 2026-09-29 | 4.3 Medium |
| Missing authorization in Core in Google Chrome on on Mac prior to 154.0.8037.57 allowed a remote attacker leveraging social engineering to obtain cross-origin data via a crafted HTML page. (Chromium security severity: Low) | ||||
| CVE-2026-95316 | 1 Google | 1 Chrome | 2026-09-29 | 2.9 Low |
| Unchecked return value in Performance in Google Chrome prior to 154.0.8037.57 allowed a local attacker to potentially read memory via a local program. (Chromium security severity: Low) | ||||
| CVE-2026-102709 | 1 Eclipse | 1 Threadx | 2026-09-29 | N/A |
| Improper validation of non-secure (NS) pointers in multiple TrustZone-M non-secure callable (NSC) entry functions allows an attacker executing in the non-secure world to supply pointers to secure memory. The secure firmware subsequently dereferences these attacker-controlled pointers without verifying that they reference non-secure memory, resulting in unintended disclosure of secure memory contents. This violates the isolation guarantees provided by Arm TrustZone-M and can be leveraged as a memory disclosure or corruption primitive that may enable recovery of sensitive cryptographic material. | ||||
| CVE-2026-102710 | 2026-09-29 | N/A | ||
| Attacker model / Preconditions: a loaded `TXM_MODULE_USER_MODE | TXM_MODULE_MEMORY_PROTECTION` module issuing kernel dispatch calls, on a build with `TX_ENABLE_EVENT_TRACE`. A user-mode, memory-protected module can register an arbitrary function pointer as the global trace-full callback. The kernel calls it directly — no validation, no trampoline — from privileged kernel code when the trace buffer wraps. An invalid pointer faults the kernel (DoS). A pointer into the module's own code was observed running with kernel privilege (`CONTROL.nPRIV = 0`), confirmed at runtime with a register capture inside that code. | ||||
| CVE-2026-102713 | 2026-09-29 | N/A | ||
| The TFTP server accepts a DATA datagram of any size. The dispatcher rejects datagrams shorter than four bytes (nxd_tftp_server.c:1037) and nothing anywhere checks an upper bound, in particular not against the protocol maximum of 4 + NX_TFTP_FILE_TRANSFER_MAX. Two things follow from that one missing check, both reachable before any authentication because TFTP has none. The handler passes `nx_packet_length - 4` straight to FileX: ```c /* addons/tftp/nxd_tftp_server.c:1863, 1889 */ status = nx_packet_copy(packet_ptr, &temp_ptr, server_ptr -> nx_tftp_server_packet_pool_ptr, NX_WAIT_FOREVER); ... fx_file_write(&(client_request_ptr -> nx_tftp_client_request_file), packet_ptr -> nx_packet_prepend_ptr + 4, packet_ptr -> nx_packet_length - 4); ``` `nx_packet_length` is the length of a chain, not of one contiguous buffer, so FileX copies past the end of the first packet: ``` ERROR: AddressSanitizer: heap-buffer-overflow READ of size 1280 at 0x621000001108 thread T5 #0 __interceptor_memcpy #1 _fx_utility_memory_copy filex/common/src/fx_utility_memory_copy.c:78 0x621000001108 is 0 bytes to the right of 4104-byte region ``` Those bytes are written into the file the attacker is uploading, and a TFTP read request hands them back, so this is a memory disclosure with a convenient retrieval channel. The same datagram also wedges the server. `nx_packet_copy` at :1863 needs ceil(nx_packet_length / pool_payload) packets and asks for them with NX_WAIT_FOREVER, so when the attacker sizes the datagram beyond what the pool holds, the server thread suspends and never returns. A liveness probe after one such datagram times out with the pool at 0 of 12 packets and the server thread suspended, and no later client is served. Reject `nx_packet_length > 4 + NX_TFTP_FILE_TRANSFER_MAX` in the DATA branch before either call, and use a bounded wait rather than NX_WAIT_FOREVER for the copy. | ||||
| CVE-2026-102718 | 2026-09-29 | N/A | ||
| hey, `_nx_snmp_utility_object_id_get` in the NetX Duo SNMP addon does not validate the claimed OID data length against the actual buffer size when the OID uses BER multibyte length encoding, so a remote attacker can send a crafted SNMP packet with a multibyte OID length larger than the available buffer, causing the parser to read past the packet buffer boundary into adjacent heap memory. the OOB bytes are decoded as OID component values and written into the agents internal OID string buffer, corrupting agent state. on systems with memory protection the OOB read poses the risk of crashing the SNMP agent thread, causing denial of service. on bare metal embedded systems without memory protection the read silently succeeds and corrupts the agents internal state with heap data. | ||||
| CVE-2026-102726 | 2026-09-29 | N/A | ||
| Unbounded PPP IPCP Option Parsing Causes a Worker Stall and Out-of-bounds Read | ||||
| CVE-2026-102728 | 2026-09-29 | N/A | ||
| Two client-side TLS/DTLS handshake parsers in NetX Secure read fields from a server-supplied message before validating that the message is long enough to contain them. Both are bounded out-of-bounds reads on a remotely reachable path, both are reached from a TLS or DTLS client connecting to a malicious or malformed server, and both have the same shape: the bounds check exists and returns the correct status, but it runs after the read it is meant to guard. | ||||
| CVE-2026-102727 | 2026-09-29 | N/A | ||
| FTP Passive Data Connection Not Bound to the Authenticated Control Peer | ||||
| CVE-2026-102824 | 1 Eugeny | 1 Russh | 2026-09-29 | 4.3 Medium |
| Russh is a Rust SSH client and server library. Prior to 0.63.0, the hybrid ML-KEM 768 and X25519 implementation in russh/src/kex/hybrid_mlkem.rs accepts an all-zero 32-byte peer X25519 public key in both server_dh and compute_shared_secret, forcing the X25519 contribution to the combined shared secret to zero. A malicious SSH peer can therefore make the combined secret depend only on ML-KEM, defeating the hybrid exchange's intended fallback protection if ML-KEM is later weakened. This issue is fixed in version 0.63.0. | ||||
| CVE-2026-102329 | 1 Google | 1 Chrome | 2026-09-29 | 8.8 High |
| Cross-site scripting in WebUI in Google Chrome prior to 154.0.8037.92 allowed a remote attacker to bypass web origin policy into a privileged page via a crafted HTML page. (Chromium security severity: High) | ||||
| CVE-2026-102320 | 1 Google | 1 Chrome | 2026-09-29 | 6.5 Medium |
| Missing authorization in CORS in Google Chrome prior to 154.0.8037.92 allowed a remote attacker who had compromised the renderer process to bypass web origin policy via a crafted HTML page. (Chromium security severity: Medium) | ||||
| CVE-2026-102310 | 1 Google | 1 Chrome | 2026-09-29 | 4.2 Medium |
| Missing authorization in Payments in Google Chrome prior to 154.0.8037.92 allowed a remote attacker who had compromised the renderer process to bypass web origin policy via a crafted HTML page. (Chromium security severity: Low) | ||||
| CVE-2026-102792 | 1 Ziroom | 1 Zhome A0101 | 2026-09-29 | 9.1 Critical |
| A vulnerability was detected in Ziroom ZHOME A0101 1.0.1.0. This affects the function set_syslog of the file /api/ZRnetwork/set_syslog. The manipulation of the argument conloglevel/log_size results in command injection. The attack may be performed from remote. The exploit is now public and may be used. The vendor was contacted early about this disclosure but did not respond in any way. | ||||
| CVE-2026-103046 | 2026-09-29 | N/A | ||
| Improper neutralization of input during web page generation ('cross-site scripting') vulnerability in Wikimedia Foundation MediaWiki - WikiLambda extension allows Stored XSS. This issue affects MediaWiki - WikiLambda extension: before 1.46.1. | ||||
| CVE-2026-84784 | 1 Openssl | 1 Openssl | 2026-09-29 | 7.5 High |
| Issue summary: A malicious remote peer may flood the local QUIC stack with NEW_CONNECTION_ID frames by avoiding a limit check on how many connection IDs the remote QUIC stack can use. Impact summary: The local QUIC stack sends a RETIRE_CONN_ID frame for every NEW_CONNECTION_ID frame it receives. The RETIRE_CONN_ID frame is dispatched via the Control Frame Queue (CFQ). If the remote peer also withholds ACKs, then it can force the local stack to allocate ~400MB (depending on ACK delay). CWE: CWE-770: Allocation of Resources Without Limits or Throttling Description: RFC 9000 sections 5.1.1 and 5.1.2 [1] describe the mechanism by which a remote peer can notify the local QUIC stack to change the destination connection ID (a.k.a. CID) the local stack uses to identify the connection at the remote peer. Each CID is associated with a sequence number. The sequence number is transmitted in NEW_CONNECTION_ID and RETIRE_CONNECTION_ID frames to identify the CID which is being either associated with a connection or retired. The remote peer sends a NEW_CONNECTION_ID frame to let the local stack know a new CID is being associated with an existing connection. The NEW_CONNECTION_ID frame carries the new CID, its sequence number, and the retire-prior-to number. The retire-prior-to identifies existing CIDs that are to be retired. The local QUIC stack must send a RETIRE_CONNECTION_ID for every destination CID whose sequence number is less than retire-prior-to. The CID becomes retired after the local stack receives an ACK for its RETIRE_CONNECTION_ID frame. Although the OpenSSL QUIC stack supports at most one destination CID for every connection, it can be tricked into processing more than one RETIRE_CONNECTION_ID frame per connection. The OpenSSL QUIC stack currently retires the destination CID as soon as it receives the NEW_CONNECTION_ID, while in fact the destination CID must be retired after an ACK for the RETIRE_CONNECTION_ID frame is received. Correcting the flawed logic also fixes the backlog growth. [1] https://datatracker.ietf.org/doc/html/rfc9000#name-issuing-connection-ids FIPS impact: no The FIPS module is not affected as the QUIC implementation is outside of the OpenSSL FIPS module boundary. | ||||
| CVE-2026-95283 | 1 Google | 1 Chrome | 2026-09-29 | 9.6 Critical |
| Buffer overflow in Tint in Google Chrome on on Android prior to 154.0.8037.57 allowed a remote attacker to potentially execute arbitrary code outside the sandbox via a crafted HTML page. (Chromium security severity: High) | ||||
| CVE-2026-95293 | 1 Google | 1 Chrome | 2026-09-29 | 4.7 Medium |
| Uninitialized resource in GPU in Google Chrome prior to 154.0.8037.57 allowed a remote attacker to read memory outside the sandbox via a crafted HTML page. (Chromium security severity: High) | ||||
| CVE-2026-95286 | 1 Google | 1 Chrome | 2026-09-29 | 8.8 High |
| Type confusion in Bindings in Google Chrome prior to 154.0.8037.57 allowed a remote attacker to execute arbitrary code inside the sandbox via a crafted HTML page. (Chromium security severity: High) | ||||