Export limit exceeded: 412532 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (412532 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2026-113620 | 1 Eclipse | 1 Eclipse Iofog | 2026-10-20 | 9.8 Critical |
| In Eclipse ioFog Controller versions 3.8.0 through 3.9.1, operator WebSocket upgrades on the exec and log routes do not verify the bearer JWT. The payload is decoded and its groups or roles are used as RBAC subjects. A self-minted token whose groups contain admin matches the built-in admin role, with no account and no RoleBinding. The attacker can open an exec or log session for a microservice or fog whose UUID they already know. HTTP routes are not affected: they verify the token before RBAC. Agent WebSockets verify the fog token and are not affected. | ||||
| CVE-2026-91041 | 1 Eclipse | 1 Threadx Filex | 2026-10-20 | 7.8 High |
| Mounting an attacker-controlled FAT image with fault tolerance enabled causes an out-of-bounds heap write during log replay. The write is attacker-positioned and attacker-valued, and on a common embedded memory layout it reaches the FX_MEDIA driver callback, giving control of the instruction pointer. | ||||
| CVE-2026-96582 | 1 Eclipse | 1 Threadx Usbx | 2026-10-20 | 4.9 Medium |
| A HID report descriptor is a sequence of items, each declaring in its header how many data bytes follow. The USBX host walks that sequence by advancing over each header and parsing the data behind it. The walk checked that an item fitted in the descriptor only **after** it had advanced past the header and parsed the payload, and the item analysis it relied on never measured the declared sizes against the bytes actually received. A HID peripheral returning a short report descriptor therefore drove a heap out-of-bounds read during ordinary enumeration. | ||||
| CVE-2026-96406 | 1 Eclipse | 1 Threadx Usbx | 2026-10-20 | 4.9 Medium |
| A VideoStreaming interface reports the size of its whole class-specific descriptor block in the `wTotalLength` field of its input header. The USBX host recorded that figure and used it as the budget for walking the format, frame and frame-interval descriptors, without holding it against the configuration descriptor actually received. A device that reports a `wTotalLength` larger than the descriptors it supplies therefore had its own claim believed. Once the real bytes ran out the walk kept going, dereferencing the cursor past the end of the configuration buffer, in the host's context, whenever the application queried format or frame data. | ||||
| CVE-2026-97400 | 1 Eclipse | 1 Eclipse Openj9 | 2026-10-20 | N/A |
| In Eclipse OpenJ9 versions up to 0.63, opening a supplied diagnostic dump bundle with the jdmpview tool, or equivalent DTFJ code, may cause the analyst's machine to read an arbitrary local file named inside the bundle and send its contents to an arbitrary remote host. | ||||
| CVE-2026-96402 | 1 Eclipse | 1 Threadx Usbx | 2026-10-20 | N/A |
| A malicious USB MTP/PTP device can cause the USBX host to read past a heap buffer during ordinary object enumeration, leaking adjacent heap contents to the application or faulting on an unmapped page. | ||||
| CVE-2026-95111 | 1 Eclipse | 1 Threadx | 2026-10-20 | N/A |
| 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. | ||||
| CVE-2026-112833 | 2 Castos, Wordpress-extensions | 2 Seriously Simple Podcasting, Seriously Simple Podcasting | 2026-10-20 | 6.5 Medium |
| Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting') vulnerability in Castos Seriously Simple Podcasting seriously-simple-podcasting allows Stored XSS.This issue affects Seriously Simple Podcasting: from n/a through 3.17.0. | ||||
| CVE-2026-112834 | 2 Castos, Wordpress-extensions | 2 Seriously Simple Podcasting, Seriously Simple Podcasting | 2026-10-20 | 5.3 Medium |
| Missing Authorization vulnerability in Castos Seriously Simple Podcasting seriously-simple-podcasting allows Exploiting Incorrectly Configured Access Control Security Levels.This issue affects Seriously Simple Podcasting: from n/a through 3.17.0. | ||||
| CVE-2026-109700 | 2 Elightup, Wordpress-extensions | 2 Meta Box – Wordpress Custom Fields Framework, Meta Box | 2026-10-20 | 6.5 Medium |
| Missing Authorization vulnerability in eLightUp Meta Box – WordPress Custom Fields Framework meta-box allows Exploiting Incorrectly Configured Access Control Security Levels.This issue affects Meta Box – WordPress Custom Fields Framework: from n/a through 5.15.2. | ||||
| CVE-2026-112840 | 2 Brainstormforce, Wordpress-extensions | 2 Surecart, Surecart | 2026-10-20 | 6.5 Medium |
| Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting') vulnerability in Brainstorm Force SureCart surecart allows Stored XSS.This issue affects SureCart: from n/a through 4.9.5. | ||||
| CVE-2026-111843 | 2 Cozythemes, Wordpress-extensions | 2 Rootblox, Rootblox | 2026-10-20 | 6.5 Medium |
| Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting') vulnerability in CozyThemes Rootblox rootblox allows Stored XSS.This issue affects Rootblox: from n/a through 1.0.7. | ||||
| CVE-2026-112824 | 2 Mage-people, Wordpress-extensions | 2 Bus Ticket Booking With Seat Reservation, Bus Ticket Booking With Seat Reservation | 2026-10-20 | 5.3 Medium |
| Missing Authorization vulnerability in Magepeople inc. Bus Ticket Booking with Seat Reservation bus-ticket-booking-with-seat-reservation allows Exploiting Incorrectly Configured Access Control Security Levels.This issue affects Bus Ticket Booking with Seat Reservation: from n/a through 5.9.7. | ||||
| CVE-2026-94192 | 1 Eclipse | 1 Threadx | 2026-10-20 | N/A |
| 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. | ||||
| CVE-2026-95109 | 1 Eclipse | 1 Threadx | 2026-10-20 | N/A |
| The Cortex-A7 MMU Modules port validates a caller-supplied buffer by translating **one address** — the first byte. The common Module Manager hands its range check the module instance, the start address and the complete byte size; the Cortex-A7 implementation discarded the instance and the size and asked the MMU a single question about the start. A memory-protected module therefore passed any range whose first byte was user-readable, however far the rest of it reached. Privileged dispatch code then read or wrote the whole range. Because every protected-module dispatcher that consumes a buffer or an extra-parameter array goes through this one macro, the defect is not in any individual service: it is in the primitive all of them rely on. | ||||
| CVE-2026-94023 | 1 Eclipse | 1 Threadx | 2026-10-20 | N/A |
| 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. | ||||
| CVE-2026-102182 | 1 Juniper Networks | 1 Junos Os | 2026-10-20 | 9.8 Critical |
| A Stack-based Buffer Overflow vulnerability in the kmd component of Juniper Networks Junos OS on MX Series allows an unauthenticated network attacker to execute code as root via specific IKE certificate-based packets. This issue requires IKE to be enabled with an RSA-signature IKE policy to be vulnerable. This issue affects Junos OS on MX Series: * All versions before 21.2R3-S11; * from 21.4 before 21.4R3-S12; * from 22.2 before 22.2R3-S8; * from 22.3 before 22.3R3-S5; * from 22.4 before 22.4R3-S9; | ||||
| CVE-2026-94024 | 1 Eclipse | 1 Threadx | 2026-10-20 | N/A |
| The Module Manager's object lookup validated one byte of a memory-protected module's search name and then walked as much of it as the module declared, in privileged mode, with the kernel's preemption count raised. Both lookup dispatchers are affected: the recommended `txm_module_object_pointer_get_extended` is handed a length and does not use it to bound the buffer, and the deprecated `txm_module_object_pointer_get` supplies the largest value a `UINT` can hold, so it removes the bound rather than lacking one. A module can make the walk unbounded without knowing anything about the memory it reaches, and where the walk reaches memory a privileged read cannot take, the resulting fault leaves the kernel unable to preempt for the rest of the system's life. Vulnerable functions: `_txm_module_manager_txm_module_object_pointer_get_dispatch`, `_txm_module_manager_txm_module_object_pointer_get_extended_dispatch` (both in `common_modules/module_manager/inc/txm_module_manager_dispatch.h`) and `_txm_module_manager_object_name_compare` (`common_modules/module_manager/src/txm_module_manager_util.c`). | ||||
| CVE-2026-95108 | 1 Eclipse | 1 Threadx | 2026-10-20 | N/A |
| 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`. | ||||
| CVE-2026-94202 | 1 Eclipse | 1 Threadx | 2026-10-20 | N/A |
| The Module Manager's block-pool create dispatcher proved that two `ALIGN_TYPE` words of the extra-parameter array a memory-protected module supplies lay inside the module's data, and then used indices 0 through 3 of that array. One of the two unproved words is read by the dispatcher's own buffer check, which takes index 1 as the pool start and index 2 as the length to range-check it over. So the out-of-bounds read is performed by the validation code itself, before the kernel service is reached, and the size the caller's pool start is then validated against is a word the manager has not proved the module owns. The other unproved word is read when the service's argument list is built. Vulnerable function: `_txm_module_manager_tx_block_pool_create_dispatch`, in `common_modules/module_manager/inc/txm_module_manager_dispatch.h`. | ||||