CVE-2026-113388
Description détaillée
A security flaw has been discovered in opensource-socialnetwork up to 9.11/10.1. This affects the function input of the file actions/administrator/cache/dynamic.php of the component Cache Settings. Performing a manipulation of the argument host/port/username/password/type/status results in code injection. The attack can be initiated remotely. The exploit has been released to the public and may be used for attacks. The patch is named 40945057cb451f0f35153110bc7e889c094400e1. Applying a patch is the recommended action to fix this issue. The vendor explains: "While we have implemented this patch as a defense-in-depth measure, we emphasize that in Open Source Social Network (OSSN), site administrators are fully trusted users who are intentionally granted broad system authority by design including the native ability to upload custom components/themes containing arbitrary PHP code."
Vecteur d'attaque (CVSS)
Références et Patchs
Dernières Vulnérabilités
CVE-2026-95109
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-95108
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-95107
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.