CVE Vulnerability Catalog

A TFTP server that answers with a short ERROR packet makes the client read up to 64 bytes past the received datagram. The loop copying the error message does not compare the pointer against the end of the packet, leading to a heap-buffer-overflow.

In the DHCP client (addons/dhcp/nxd_dhcp_client.c), the TLV option walk advances the offset counter 'i' by size+1 while the data pointer 'data' advances by size+2. After skipping enough options, the bound check 'i < length - 1' still passes even though the data pointer has moved past the end of the received message. As a result, the DHCP client reads roughly a kilobyte past the buffer (heap-buffer-overflow), which can be triggered by a malicious DHCP server or anyone on the LAN who answers a DISCOVER first.

A vulnerability related to a predictable DTLS HelloVerifyRequest cookie in NetX Secure. The predictability of the cookie may allow an attacker to bypass the source address spoofing protection mechanism.

The `_nx_snmp_utility_object_id_get` function 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 agent's 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 agent's internal state with heap data.

An unauthenticated client can drain the RTSP server's packet pool with a few dozen requests carrying a Session header that the parser cannot convert. The Session branch returns a raw NetX error code instead of an RTSP status code, causing a response packet leak. After 26 requests the pool is exhausted and the server stops serving anyone.

Heap-buffer-overflow vulnerability in the NX mDNS module. Any host on the LAN can send two mDNS records and cause the responder to write past the end of its transmit packet. The flaw stems from comparing the rounded slot size instead of the actual string length when looking up stored names.

The `_nx_icmpv6_validate_options()` function in the Eclipse ThreadX (NetX Duo) network stack scans the ICMPv6 option area with `while (length > 2)`, leaving a one- or two-byte tail unexamined and returning `NX_SUCCESS`. Consumers then re-walk the same area, reading a two-byte option header at the residue and subtracting `nx_icmpv6_option_length << 3` with no zero check and no remaining-length check. This yields three outcomes: an infinite loop (zero length byte), unsigned counter underflow and out-of-buffer reads (non-zero length byte on a short residue), and a one-byte over-read (one-byte residue).

The TFTP server does not enforce an upper bound on DATA datagram size, accepting packets larger than the protocol maximum. This leads to a heap-buffer-overflow when copying data into FileX, enabling memory disclosure, and also allows an attacker to wedge the server thread by exhausting the packet pool. Both issues are reachable without authentication since TFTP has none.

On the first DTLS ClientHello, the parser copies a device-claimed session_id length and validates the ciphersuite-list length against the total record length instead of the remaining bytes. An unauthenticated peer drives an OOB source read of up to 255 bytes, and those bytes are echoed verbatim into the outgoing ServerHello, disclosing adjacent process memory over the network. The crash variant fires on the first packet.

Two issues in the ThreadX loadable-module loader, reachable when a device loads an attacker-controlled module object via `_txm_module_manager_memory_load` / `_txm_module_manager_in_place_load`. These APIs take only a base pointer with no image length, so every size/offset field in `TXM_MODULE_PREAMBLE` is fully attacker-trusted: (1) a heap OOB read and (2) a control-flow-integrity gap.

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.

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.

Electron is a framework for writing cross-platform desktop applications. From 42.3.3 until 42.10.0, 43.5.0, and 44.0.0-beta.6, Electron's sandboxed preload code cache did not verify that a cached entry matched the preload it was served for. A compromised renderer could write attacker-controlled cache data and cause Electron to reuse it for a later load, executing the renderer's code in the more privileged preload context. The issue affects applications that load untrusted content. This issue is fixed in versions 42.10.0, 43.5.0, and 44.0.0-beta.6.

MobilityDB version 1.3.0 and earlier contains an out-of-bounds read vulnerability in the MEOS binary and library WKB deserialization logic. An unprivileged database user can supply a crafted WKB payload with a negative length field, causing the PostgreSQL backend process to crash.

In libsoup, when the permessage-deflate WebSocket extension compresses a very large outgoing message, truncated size calculations used for GByteArray growth could wrap, causing zlib to write past the allocated buffer and resulting in a heap buffer overflow.

In libsoup, when constructing a masked WebSocket client frame for a very large outgoing payload, size values passed to GByteArray allocation APIs could be truncated while the masking routine still used the full length, causing a heap buffer overflow.

In libsoup, when max-incoming-payload-size is unlimited (0), SoupWebsocketConnection could grow its incoming GByteArray based on an attacker-controlled frame length until the length wrapped, causing a heap buffer overflow while reading frame data.

In libsoup, the soup_uri_decode_data_uri() function incorrectly treated base64 data-URI payloads as NUL-terminated strings when calling g_base64_decode_inplace(). If the percent-decoded payload contained embedded NUL bytes, the decoded length could remain uninitialized and be used as the size of the returned GBytes. This can lead to an out-of-bounds read or application crash when processing a crafted data URI.

In Google MCP Toolbox for Databases versions 1.2.0 through 1.9.0, the allowedLocalRoots path validation checks directories lexically without resolving symbolic links. A remote authenticated attacker with tool execution permissions can bypass directory boundary restrictions and access or overwrite arbitrary local files outside the permitted root directories.

Joomla! Core versions 1.5.0-5.4.8 and 6.0.0-6.1.3 have an XSS filter bypass in InputFilter. The cleanAttribute method removes HTML data URIs, but injected whitespace characters can circumvent that cleanup, causing an XSS vector.