| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| In Eclipse ThreadX NetX Duo versions 6.0 through 6.5.2.202603a, the FTP server accepts the first connection to a passive data port without checking that it comes from the client that requested passive mode. An unauthenticated network attacker who connects to the predictable port first receives the file an authenticated user downloads, or supplies the content of the file the user uploads. |
| In Eclipse ThreadX NetX Duo versions 6.0 through 6.5.2.202603a, the PPP IPCP code parses a peer's Configure-Nak without validating each option's length. A malicious PPP peer can stall the PPP thread indefinitely with a zero-length option, taking the link down, and can read back up to four bytes of packet-buffer memory per exchange with a short address option. |
| In Eclipse ThreadX NetX Duo versions 6.4.0 through 6.5.2.202603a, built with VLAN and SRP support, the MSRP parser uses the attribute list length from the received frame without comparing it with the packet length. An unauthenticated station on the same Layer 2 segment can send a short MSRP frame declaring a long list and make the MRP worker read far past the received packet, faulting it on targets with memory protection. |
| In Eclipse ThreadX NetX Duo versions 6.4.0 through 6.5.2.202603a, built with VLAN and SRP support, evicting the last attribute in an MRP participant's list writes through a null successor pointer. An unauthenticated station on the same Layer 2 segment can fault the MRP worker thread by declaring one MSRP attribute and withdrawing it, and ordinary withdrawals by legitimate stations reach the same path. |
| In Eclipse ThreadX NetX Duo versions 6.4.0 through 6.5.2.202603a, built with VLAN and SRP support, the MSRP attribute lookup writes through the null pointer returned by its allocator when the ten-entry attribute table is full. An unauthenticated station on the same Layer 2 segment can fault the MRP worker thread by declaring enough new attributes, and Talker Failed declarations hold table entries that are never released. |
| In Eclipse ThreadX NetX Duo versions 6.0 through 6.5.2.202603a, the NetX Secure DTLS server fills HelloVerifyRequest cookies from NX_RAND(), by default the C library rand(), with no key and no binding to the client. An attacker who can predict the generator's output can pass the cookie exchange from a spoofed address and make the server send its handshake flight to a victim, using it as a traffic reflector. |
| In Eclipse ThreadX NetX Duo versions 6.0 through 6.5.2.202603a, the FTP client in IPv4 passive mode opens its data connection to whatever address the server names in its 227 reply instead of the server it is talking to. A malicious FTP server can make the client connect to any host and port the device can reach, using it to scan the internal network and to deliver uploads to internal services. |
| In Eclipse ThreadX NetX Duo versions 6.0 through 6.5.2.202603a, the TFTP client copies the message of a received ERROR packet without bounding the copy by the end of the datagram, and the TFTP server reads one byte past a minimal ERROR packet. A malicious TFTP server can make the client copy up to 64 bytes of adjacent packet-pool memory into the error string the application retrieves, or fault on targets with memory protection. |
| In Eclipse ThreadX NetX Duo versions 6.0 through 6.5.2.202603a, the DHCP client's option walk advances its offset one byte less than its read pointer for every option it skips. A DHCP server, or any host on the link that answers first, can make the client read up to about a kilobyte past the received message, and the same walk copies out-of-bounds bytes into the application's buffer when it retrieves a user option. |
| In Eclipse ThreadX versions 6.0.1 through 6.5.2.202603, the Module Manager loaders take a module image without its length and trust the sizes and offsets in its preamble. A crafted module image can declare a code size larger than the image to read, or gain access to, the memory that follows it, and can place its entry points outside its code. |
| In Eclipse Mnestix Browser versions 1.2.0 up until but excluding 2.3.0 it was possible for an unauthenticated attacker to perform actions that are only allowed to be executed by an authorized Mnestix user, like changing the Infrastructure settings or calling the connected and authenticated Mnestix AAS Generator backend. |
| In Eclipse ThreadX versions 6.0.1 through 6.5.2.202603, the Module Manager lets a user-mode, memory-protected module post a forged callback request to another module's callback request queue. The receiving module's callback thread calls the function pointer in the request without checking that the Module Manager sent it, so the attacker's code runs with the receiving module's privilege; when that module runs in privileged mode, a user-mode module gains privileged execution. |
| In Eclipse ThreadX versions 6.0.1 through 6.5.2.202603, ThreadX Modules does not revoke a module's trace-buffer-full callback when the module is stopped and unloaded. With event tracing enabled and a kernel-owned trace buffer still active, a later buffer wrap invokes the callback from privileged thread context after the module's code has been released, so a user-mode module can have its code run with kernel privileges after unload, or, once the memory is reused, redirect control flow or cause a fault. |
| In Eclipse Vert.x versions [4.0.0, 4.5.35] or [5.0.0, 5.2.2], when a malicious server keeps sending bytes on an EOL-terminated line (not length-prefixed, for example a simple string [1]), we'll keep growing the buffer without bounds, eventually leading to an OOM. We need to have a configurable limit for EOL-terminated lines.
If a malicious server sends a specially crafted RESP response (for example a bulk string [2] with missing CRLF trailer), the parser enters an infinite loop where it keeps parsing the same buffer and pushing the same response to the caller, which may lead e.g. to an OOM if the consumer just buffers the responses. We must fix the parser to avoid this infinite looping. |
| In Eclipse Vert.x versions [4.0.0,4.5.35] or [5.0.0,5.2.2], when one `CachingWebClient` is shared across users — the documented pattern of a per-user `WebClientSession` over a shared caching client — a response that is specific to one user but is cacheable and not marked `private`/`no-store` is stored in the client-level shared cache tier and served to other users requesting the same URL. A later user's session, or an anonymous caller through the same client, can receive an earlier user's response. Depending on the response this discloses authenticated content or a session cookie, the latter enabling session fixation or hijacking. |
| In Eclipse ThreadX versions 6.0.1 through 6.5.2.202603, the four non-secure-callable secure stack functions of the TrustZone-M ports dereference a thread pointer supplied by the non-secure world without checking that it points to non-secure memory. Non-secure code can make the secure firmware reveal which secure bytes are zero, write chosen secure words, and fault the secure world, breaking TrustZone-M isolation and enabling recovery of secure-world secrets such as cryptographic keys. |
| In Eclipse ThreadX versions 6.0.1 through 6.5.2.202603, built with TX_ENABLE_EVENT_TRACE, the Module Manager lets a user-mode, memory-protected module register any function pointer as the kernel's trace-buffer-full callback, which the kernel calls from privileged code when the trace buffer wraps. A malicious module can thereby run its own code with kernel privilege, defeating module isolation, or fault the kernel with an invalid pointer. |
| In Eclipse Vert.x versions [4.0.0, 4.5.35] or [5.0.0, 5.2.2], the `FrameParser` in vertx-stomp creates a `RecordParser` without setting `maxRecordSize`, so any peer that streams bytes continuously without a newline character causes the parser to accumulate data indefinitely. Both the STOMP server and the STOMP client are affected: a malicious server can exploit this against a connecting client, and a malicious client can exploit this against a server before or after authentication. Sustained byte streaming exhausts JVM heap memory, crashing the affected process and causing a complete denial of service. |
| In Eclipse ThreadX versions 6.0.1 through 6.5.2.202603, the Module Manager loaders return an overflow error without releasing the Module Manager mutex when a module preamble declares a data or stack size that overflows the allocation arithmetic. Loading such an image blocks every later module load, start, stop and unload from other threads until the system is reset. |
| In Eclipse ThreadX versions 6.0.1 through 6.5.2.202603, the Module Manager's thread-control services do not check that a thread passed by a user-mode, memory-protected module belongs to that module. Any loaded module can suspend, resume, terminate, reset or re-prioritise application threads and other modules' threads and abort their waits, denying service or changing how the system schedules them. |
