Vulnerabilities
All
My stack
Known exploited
Public exploit
Critical (9+)
Likely exploited (EPSS ≥ 50%)
Changed, 24 h
New, 24 h
Sort:
risk
modified
published
CVSS
EPSS
| CVE | CVSS | EPSS | Vendor, product | Description | Modified |
|---|---|---|---|---|---|
| CVE-2025-55089 | 9.2 critical | 1.0% | eclipse, threadx_filex | In FileX before 6.4.2, the file support module for Eclipse Foundation ThreadX, there was a possible buffer overflow in the FileX RAM disk driver. It could cause a remote execurtion after receiving a crafted sequence of packets | 8 Oct |
| CVE-2025-55085 | 8.8 high | 1.0% | eclipse, threadx_netx_duo | In NextX Duo before 6.4.4, in the HTTP client module, the network support code for Eclipse Foundation ThreadX, the parsing of HTTP header fields was missing bounds verification. A crafted server response could cause undefined behavior. | 9 Oct |
| CVE-2025-55100 | 2.4 low | 1.0% | eclipse, threadx_usbx | In USBX before 6.4.3, the USB support module for Eclipse Foundation ThreadX, there was a potential out of bound read issue in _ux_host_class_audio10_sam_parse_func() when parsing a list of sampling frequencies. | 9 Oct |
| CVE-2026-94192 | 8.5 high | 0.00% | no CPE yet | A ThreadX module allocates the control blocks of its kernel objects from the Module Manager's object pool, and can ask for that memory back by address with `txm_module_object_deallocate`. The manager released it whatever was in it, including a control block the kernel was still using. Deallocation is not deletion: the object stays on the created list for its type, a thread stays wherever it was on the ready or suspension lists and stays schedulable, and an active timer stays on the timer list. The byte pool is meanwhile free to hand those same bytes to the next allocation. | 20 Oct |
| CVE-2026-11576 | 7.5 high | 0.00% | eclipse, threadx_netx_duo | The security fix for CVE-2025-0728 in eclipse-threadx NetX Duo refactors error handling in the HTTP server PUT process to use a shared cleanup label, but this unified cleanup path unconditionally calls fx_file_close() even when the file was never successfully opened. Multiple error branches jump to the shared cleanup label before any file open operation has occurred, causing fx_file_close() to operate on an uninitialized file handle, leading to undefined behavior, double-close issues, or memory corruption. | Mon 26 Oct |
| CVE-2025-55080 | 7.2 high | 0.00% | eclipse, threadx | In Eclipse ThreadX before 6.4.3, when memory protection is enabled, syscall parameters verification wasn't enough, allowing an attacker to obtain an arbitrary memory read/write. | 8 Oct |
| CVE-2026-95107 | 7.0 high | 0.00% | no CPE yet | A ThreadX module chooses `object_size` when it calls `txm_module_object_allocate`. The Module Manager adds its own 16-byte private header to that size and asked the object pool for the result **without checking the addition**. A size near the top of a `ULONG` wrapped, the pool served a block far smaller than the header, and the manager then wrote the header past the end of it and into the neighbouring byte-pool block. | 20 Oct |
| CVE-2026-94023 | 6.9 medium | 0.00% | no CPE yet | A ThreadX module reaches a kernel object's delete service through the Module Manager's dispatch layer, which asked one question about the pointer: does the object lie outside the module's own code and data. That is the policy for *using* an object, and using an object a module does not own is supported and intended — `txm_module_object_pointer_get_extended` searches the system's created objects by name and hands back objects the application created and objects other modules created, so that a module can send to a shared queue, take a shared semaphore or get a shared mutex. Destroying one of those is not sharing it. A module could name any object it had a pointer to and have the privileged dispatcher delete it. | 20 Oct |
| CVE-2025-55092 | 6.9 medium | 0.00% | eclipse, threadx_netx_duo | In Eclipse Foundation NetX Duo before 6.4.4, the networking support module for Eclipse Foundation ThreadX, there was a potential out of bound read issue in _nx_ipv4_option_process() when processing an IPv4 packet with the timestamp option. | 9 Oct |
| CVE-2025-55093 | 6.9 medium | 0.00% | eclipse, threadx_netx_duo | In NetX Duo before 6.4.4, the networking support module for Eclipse Foundation ThreadX, there was a potential out of bound read issue in _nx_ipv4_packet_receive() when handling unicast DHCP messages that could cause corruption of 4 bytes of memory. | 9 Oct |
| CVE-2025-55094 | 6.9 medium | 0.00% | eclipse, threadx_netx_duo | In NetX Duo before 6.4.4, the networking support module for Eclipse Foundation ThreadX, there was a potential out of bound read issue in _nx_icmpv6_validate_options() when handling a packet with ICMP6 options. | 9 Oct |
| CVE-2025-55081 | 6.9 medium | 0.00% | eclipse, threadx_netx_duo | In Eclipse Foundation NextX Duo before 6.4.4, a module of ThreadX, the _nx_secure_tls_process_clienthello() function was missing length verification of certain SSL/TLS client hello message: the ciphersuite length and compression method length. In case of an attacker-crafted message with values outside of the expected range, it could cause an out-of-bound read. | 8 Oct |
| CVE-2025-55082 | 6.9 medium | 0.00% | eclipse, threadx_netx_duo | In NetX Duo version before 6.4.4, the component of Eclipse Foundation ThreadX, there was a potential out of bound read in _nx_secure_tls_process_clienthello() because of a missing validation of PSK length provided in the user message. | 8 Oct |
| CVE-2025-55083 | 6.9 medium | 0.00% | eclipse, threadx_netx_duo | In NetX Duo version before 6.4.4, the component of Eclipse Foundation ThreadX, there was an incorrect bound check resulting it out by two out of bound read. | 8 Oct |
| CVE-2025-55084 | 6.9 medium | 0.00% | eclipse, threadx_netx_duo | In NetX Duo version before 6.4.4, the component of Eclipse Foundation ThreadX, there was an incorrect bound check in_nx_secure_tls_proc_clienthello_supported_versions_extension() in the extension version field. | 8 Oct |
| CVE-2025-55090 | 6.9 medium | 0.00% | eclipse, threadx_netx_duo | In NetX Duo before 6.4.4, the networking support module for Eclipse Foundation ThreadX, there was a potential out of bound read issue in _nx_ipv4_packet_receive() function when received an Ethernet frame with less than 4 bytes of IP packet. | 8 Oct |
| CVE-2025-55091 | 6.9 medium | 0.00% | eclipse, threadx_netx_duo | In NetX Duo before 6.4.4, the networking support module for Eclipse Foundation ThreadX, there was a potential out of bound read issue in _nx_ip_packet_receive() function when received an Ethernet with type set as IP but no IP data. | 8 Oct |
| CVE-2026-95108 | 6.8 medium | 0.00% | no CPE yet | One logical thread of a user-mode ThreadX module costs the Module Manager's shared object pool two allocations, not one. The module asks for a `TX_THREAD` control block through `txm_module_object_allocate`; `_txm_module_manager_thread_create` then takes a second allocation of `TXM_MODULE_KERNEL_STACK_SIZE` bytes for the privileged kernel stack that thread's system calls run on, and records it in the control block. Both come from `_txm_module_manager_object_pool` and both are linked onto the module's allocation list. The Module Manager's thread-delete dispatcher released only the first. The kernel stack stayed allocated until the whole module was stopped, so a module that creates, terminates and deletes threads in a loop — every state transition valid, every service returning `TX_SUCCESS` — removed a fixed block from a finite pool shared by the manager and by every other loaded module, on every cycle, for as long as it stayed loaded. Once the pool is exhausted, no memory-protected module can create any kernel object and no user-mode module thread can be created anywhere in the system. Vulnerable function: `_txm_module_manager_tx_thread_delete_dispatch`, in `common_modules/module_manager/inc/txm_module_manager_dispatch.h`. | 20 Oct |
| CVE-2025-55087 | 6.3 medium | 0.00% | eclipse, threadx_netx_duo | In NextX Duo's snmp addon versions before 6.4.4, a part of the Eclipse Foundation ThreadX, an attacker could cause an out-of-bound read by a crafted SNMPv3 security parameters. | 9 Oct |
| CVE-2025-55086 | 6.3 medium | 0.00% | eclipse, threadx_netx_duo | In NetXDuo version before 6.4.4, a networking support module for Eclipse Foundation ThreadX, in the DHCPV6 client there was an unchecked index extracting the server DUID from the server reply. With a crafted packet, an attacker could cause an out of memory read. | 8 Oct |
| CVE-2025-55078 | 5.7 medium | 0.00% | eclipse, threadx | In Eclipse ThreadX before version 6.4.3, an attacker can cause a denial of service (crash) by providing a pointer to a reserved or unmapped memory region. Vulnerable system calls had a check of pointers, but that check wasn't verifying whether the pointer is outside the module memory region. | 8 Oct |
| CVE-2025-55079 | 5.7 medium | 0.00% | eclipse, threadx | In Eclipse ThreadX before version 6.4.3, the thread module has a setting of maximum priority. In some cases the check of that maximum priority wasn't performed, allowing, as a result, to obtain a thread with higher priority than expected and causing a possible denial of service. | 8 Oct |
| CVE-2026-95111 | 4.8 medium | 0.00% | no CPE yet | A memory-protected ThreadX module's queue request reaches the Module Manager's dispatch layer, which decides how much of the module's buffer the privileged queue copy may touch and hands that extent to the module port's range check. A queue's `tx_queue_message_size` is a count of `ULONG`s and the copy moves that many words, so the extent is `message_size * sizeof(ULONG)` bytes. The front-send dispatcher passed the word count itself. `tx_queue_send` and `tx_queue_receive`, either side of it in the same header, have always multiplied. A source buffer ending `message_size` bytes into memory the module may read was therefore accepted, and `_txe_queue_front_send` then read `message_size * sizeof(ULONG)` bytes from it in privileged mode — `3 * message_size` bytes past the end of what the module is allowed to read. The words are written into the queue's message area, so a module that can receive from that queue reads them back. | 20 Oct |
| CVE-2025-55097 | 2.4 low | 0.00% | eclipse, threadx_usbx | In USBX before 6.4.3, the USB support module for Eclipse Foundation ThreadX, there was a potential out of bound read issue in _ux_host_class_audio_streaming_sampling_get() when parsing a descriptor of an USB streaming device. | 9 Oct |
| CVE-2025-55099 | 2.4 low | 0.00% | eclipse, threadx_usbx | In USBX before 6.4.3, the USB support module for Eclipse Foundation ThreadX, there was a potential out of bound read issue in _ux_host_class_audio_alternate_setting_locate() when parsing a descriptor with attacker-controlled frequency fields. | 9 Oct |
| CVE-2025-55096 | 2.1 low | 0.00% | eclipse, threadx_usbx | In USBX before 6.4.3, the USB support module for Eclipse Foundation ThreadX, there was a potential out of bound read issue in _ux_host_class_hid_report_descriptor_get() when parsing a descriptor of an USB HID device. | 9 Oct |
| CVE-2025-55098 | 1.0 low | 0.00% | eclipse, threadx_usbx | In USBX before 6.4.3, the USB support module for Eclipse Foundation ThreadX, there was a potential out of bound read issue in _ux_host_class_audio_device_type_get() when parsing a descriptor of an USB audio device. | 9 Oct |
27 of 27
Download these 27 as CSV · subscribe to this list.
EPSS scores: 2026-10-28. NVD cursor: 2026-10-29 00:22. The News page shows only notable CVEs (KEV, your stack, new criticals, EPSS over 50%, or active exploitation per SSVC); this table has all of them.