Search
CVE Explorer
Search the full tracked CVE corpus across every vendor — by keyword, vendor, severity, CVSS band and publication date. Server-rendered; each filtered view has its own URL.
01
Filters
Submit to refine — state is held in the URL.
02
Results
167,871 matching · page 15/3358Each CVE id links to its NVD record.
| CVE | Severity | CVSS | Summary | Published |
|---|---|---|---|---|
| CVE-2026-99258(opens NVD record) | Unscored | — | In the Linux kernel, the following vulnerability has been resolved: x86/hyperv: Avoid using per-cpu output page in hv_apicid_to_vp_index() hv_apicid_to_vp_index() currently uses the per-cpu hypercall input and output pages. This function is called when running in VTL2 and when running in an SEV-SNP CoCo VM with no paravisor. In the former case, the output page is allocated, but in the latter case it is not, so the hypervisor stores the output VP index in memory that has not been allocated by the guest. Fix this by using the input page for both input and output. The hypercall has very small input and output, so sharing the same page for both is straightforward. An alternative fix is to allocate the per-cpu output page when running in an SEV-SNP CoCo guest, but this uses significantly more memory, particularly with larger vCPUs counts. | Nov 3, 2026 |
| CVE-2026-99257(opens NVD record) | Unscored | — | In the Linux kernel, the following vulnerability has been resolved: gpio: shared: gracefully handle no-device lookup of shared GPIOs We use platform lookup tables for shared GPIOs. This mechanism needs a struct device to work so fwnode-based lookup with no device associated currently causes a NULL-pointer deference. Adding this functionality will require a larger rework and it has never worked anyway so add a check that allows the kernel to gracefully handle this situation with an error ahead of implementing that functionality as a new feature. | Nov 3, 2026 |
| CVE-2026-99256(opens NVD record) | Unscored | — | In the Linux kernel, the following vulnerability has been resolved: dm cache: fix issue with background work locking dm cache used a rw_semaphore for background_work_lock. Write locks on rw_semaphores have strict owner semantics, but there was no guarantee that the process that locked background_work_lock was the same process that unlocked it. This can be easily seen using a kernel compiled with CONFIG_DEBUG_RWSEMS. Given a dm cache device <cache>, run: 'dmsetup suspend <cache> && dmsetup resume <cache>'. This will trigger a kernel warning: DEBUG_RWSEMS_WARN_ON((rwsem_owner(sem) != current) && !rwsem_test_oflags(sem, RWSEM_NONSPINNABLE)) triggered by cache_resume(). To fix this, switch from a rw_semaphore to a spinlock and a wait queue. dm cache already has a wait queue and associated counter, migration_wait and nr_allocated_migrations, that was getting woken up when background work was getting completed, but wasn't actually used by anything. This is replaced by the background_work queue and counter. | Nov 3, 2026 |
| CVE-2026-99255(opens NVD record) | Unscored | — | In the Linux kernel, the following vulnerability has been resolved: io_uring/io-wq: don't hide a link from cancellations A task that exits cancels its tracked requests and waits until they are gone. io_uring_cancel_generic() looks everywhere a request can be, and goes to sleep if it found nothing to cancel. It is woken up each time one of the requests of the task is completed by task work or freed. When io-wq is done with a request that has a link, there is a time in which the next request of the link can't be found: io_worker_handle_work() io_assign_current_work(worker, NULL) io_wq_free_work(work) io_req_find_next() // takes the link off the request io_free_req() // task work for the task io_assign_current_work(worker, linked) io_run_task_work() cond_resched() worker->cur_work = linked It is not pending, it is not the current work of a worker, and it is not yet on the list that it is about to be parked on. If the pass that the exiting task makes because of io_free_req() falls into that time, it finds nothing and the task goes to sleep. The worker then runs the link, which IO_WQ_BIT_EXIT doesn't prevent for bounded work. If that parks the request nothing is completed or freed, and nobody wakes up the task. If it is the process that exits it can't be killed any more either. NOP, IOSQE_ASYNC | IOSQE_IO_LINK FUTEX_WAIT, FUTEX2_PRIVATE exit of the thread, or of the process, up to 63us later With four of these per round 5 to 8 of 10,000 rounds hang (4 CPUs, KVM): io_uring_cancel_generic do_exit Commit f8b632e89a10 ("io_uring: tighten task exit cancellations") is about the same gap, and makes the task look again for whatever happens before io_free_req(). Free the request once the link is the current work of the worker, or pending. Whoever is woken up by that can find the link, until it is parked where cancellations look as well. To do so split io_wq_free_work() in two. | Nov 3, 2026 |
| CVE-2026-99254(opens NVD record) | Unscored | — | In the Linux kernel, the following vulnerability has been resolved: io_uring: don't flood a cancelling task with task_work io_ring_exit_work() asks each task which has used the ring to remove its tctx node, by task_work, and repeats that until the list is empty. io_tctx_exit_cb() doesn't touch the node while the task is in io_uring_cancel_generic(), which removes all the nodes at its end. So the work item queues the callback again as soon as it has completed, for nothing. That is more than a waste of time. task_work_run() only returns when it finds the list empty. If the rings are released from inside the cancellation, because requests of other rings held the last references to their files, up to 64 work items keep sending callbacks to the one task which is running them. It never finds the list empty, never gets back to the cancellation, the nodes stay, and so it goes on: a task with 60 pairs of rings which poll each other ran 280000 callbacks in 5 seconds, 20 seconds after exit_group(). It ends when all the senders happen to be late at the same time. Until then the task keeps a CPU and the work items busy. An exiting task can't be killed meanwhile. execve() cancels the requests in the same way, so a live task can get stuck there as well, for minutes. If it takes more than five, the work items run into the WARN_ON_ONCE(time_after(jiffies, timeout)) of io_ring_exit_work(). No privilege is needed for any of this. If the callback has met a task in cancellation, wait a little before it is sent again. Nobody has to wake the work item up for that: either the node is gone by then, or it is the turn of the next round. | Nov 3, 2026 |
| CVE-2026-99253(opens NVD record) | Unscored | — | In the Linux kernel, the following vulnerability has been resolved: io_uring/cancel: rearm local work wake up before sleep io_uring_try_cancel_requests() sets ->cq_wait_nr to 1 so that the next io_req_local_work_add() wakes the cancelling task. The add that takes the count to zero is the only one that wakes, later ones see a count <= 0 and return. io_uring_cancel_generic() however only becomes TASK_INTERRUPTIBLE much later, so the one wake up can be spent on a running task. That is fine as long as the entry of that add is still queued, as the io_local_work_pending() check then skips the sleep. It is not if the add was delayed after queueing its entry: CPU0 (submitter in exec or exit) CPU1 (io_req_local_work_add) mpscq_push(req A) io_uring_try_cancel_requests() io_run_local_work() // runs req A io_uring_try_cancel_requests() atomic_set(&ctx->cq_wait_nr, 1) atomic_read(&ctx->cq_wait_nr) == 1 count taken, wake_up_state() // task is running, no-op prepare_to_wait(TASK_INTERRUPTIBLE) io_local_work_pending() == false schedule() mpscq_push(req B) cq_wait_nr <= 0, return Only the sleeping task can run req B, so it is stuck in execve() until a signal happens to wake it. An exiting task doesn't even get that. Arm the count again once the task state is set and before the work list is checked, for the rings whose local work this task is the one to run. | Nov 3, 2026 |
| CVE-2026-99252(opens NVD record) | Unscored | — | In the Linux kernel, the following vulnerability has been resolved: io_uring/mpscq: disable preemption while pushing A push makes the node the new tail, and then links it to its predecessor. In between the queue isn't empty, but mpscq_pop() can't get at the node. The consumers deal with that by trying again, with a cond_resched() in the loop to give a preempted producer the chance to finish. cond_resched() doesn't do that if the consumer has a higher priority than the producer and both have to use the same CPU: producer (SCHED_OTHER) consumer (SCHED_FIFO), same CPU io_req_local_work_add() mpscq_push() prev = xchg(&q->tail, node) <preempted> io_cqring_wait() __io_run_local_work() again: cond_resched() // nothing to do mpscq_pop() // NULL // work pending, no events yet goto again The producer can be any task that is able to queue task_work for the ring: an io-wq worker, or somebody who sends a message with IORING_OP_MSG_RING. The consumer spins, holding ->uring_lock, until the scheduler takes pity on the fair class, which takes about a second with the default settings of the fair server, and forever without it. The loops in tctx_task_work_run() and io_cancel_local_task_work() have the same problem. Don't allow preemption between the two steps. That bounds the time the window is open on the CPU of the producer by what interrupts take, and a consumer that waits for that is on another CPU. The cost is a preempt_disable()/preempt_enable() pair per push. | Nov 3, 2026 |
| CVE-2026-99251(opens NVD record) | Unscored | — | In the Linux kernel, the following vulnerability has been resolved: Drivers: hv: Avoid infinite retry loop in init_vp_index() There is a retry loop in init_vp_index() where the CPUs from a certain node are stripped out if they have already been in the allocated cpumask or not in HK_TYPE_MANAGED_IRQ housekeeping cpumask. If there is no CPU left, the allocated cpumask is ignored and the process is retried again. However, if the HK_TYPE_MANAGED_IRQ housekeeping cpumask turns out not to contain any CPU in that particular node, that will become an infinite retry loop. This particular problem was reported by sashiko [1]. This should rarely happen, but we still need to guard against this. Fix this infinite loop problem by also skipping NUMA node that has no housekeeping CPU in the inner while loop of init_vp_index(). Also update the early abort check to check for the absence of online housekeeping CPUs instead of just the emptiness of the cpumask. As the outer for loop will only be reached if the housekeeping cpumask has at least one online CPU, a NUMA node with housekeeping CPUs will eventually be found. | Nov 3, 2026 |
| CVE-2026-99250(opens NVD record) | Unscored | — | In the Linux kernel, the following vulnerability has been resolved: printk: Postpone kthread startup There have been various bug reports related to SMP systems hanging on boot. The reports vary but seem to have some overlap with regard to missed IPI's during SMP setup. The reports also show that reverting NBCON console usage allows the bugs to disappear. The NBCON kthreads for console printing are started very early during boot using early_initcall(). Since these kthreads are asynchronously enabling/disabling interrupts during early boot, they may be interfering with early SMP setup on some hardware platforms. Starting the console printing kthreads later has shown to avoid the hanging on systems that could previously reproduce the issue. Postpone kthread starting until after all arch initcalls have completed. | Nov 3, 2026 |
| CVE-2026-99249(opens NVD record) | Unscored | — | In the Linux kernel, the following vulnerability has been resolved: pid_namespace: make zap_pid_ns_processes() freezable When the init of a pid namespace exits, zap_pid_ns_processes() waits until all other pids in the namespace are freed. A tracer outside the namespace that does not reap its traced zombies keeps those pids allocated, so this wait has no upper bound, and while it lasts every suspend attempt fails: Freezing user space processes failed after 20.006 seconds (2 tasks refusing to freeze, wq_busy=0): Neither wait is freezable. The first loop sleeps in do_wait(), which returns -ERESTARTSYS on the freezer's fake signal; the loop then clears TIF_SIGPENDING and waits again without ever freezing. The final loop sleeps in TASK_INTERRUPTIBLE, and since nothing clears TIF_SIGPENDING there, schedule() returns immediately after the first freeze attempt and the task spins until the wait ends. Sleep in TASK_INTERRUPTIBLE | TASK_FREEZABLE in do_wait(), so that the freezer can freeze tasks waiting there directly, and in TASK_IDLE | TASK_FREEZABLE in the final loop, like coredump_task_exit() does. This was hit with Chromium-based browsers: crashpad ptrace-attaches the threads of a crashed renderer, which is a pid namespace init, and does not reap those killed during the dump. | Nov 3, 2026 |
| CVE-2026-99248(opens NVD record) | Unscored | — | In the Linux kernel, the following vulnerability has been resolved: i2c: xiic: restore non-managed runtime PM to fix clk WARN flood The devres conversion replaced manual pm_runtime_enable()/disable() with devm_pm_runtime_set_active_enabled() and dropped the remove-time runtime PM teardown. The managed release tears runtime PM down in the wrong order: it calls pm_runtime_dont_use_autosuspend() before pm_runtime_disable(), i.e. while runtime PM is still enabled, and devres is LIFO so the devm_clk_get_enabled() release runs afterwards. At remove(), pm_runtime_put_sync() leaves the device active with the autosuspend timer armed. Clearing use_autosuspend then makes rpm_idle() suspend immediately, and xiic_i2c_runtime_suspend() clk_disable()s the clock. The later devm_clk_get_enabled() release clk_disable_unprepare()s the already-disabled clock, so clk_core_disable() WARNs ("clkN already disabled") on every teardown. Drop the managed helper and restore the non-managed runtime PM setup and teardown, so runtime PM is enabled once in probe and disabled once in remove and the clock enable count stays balanced. Order the remove teardown so runtime PM is disabled before the usage count is dropped: pm_runtime_disable() followed by pm_runtime_put_noidle() instead of pm_runtime_put_sync(). Dropping the count first with autosuspend still enabled arms the autosuspend timer, and a preemption before pm_runtime_disable() lets it expire, suspend the device and clk_disable() the clock, which the devm release then disables again - the same WARN. Restore the non-managed IRQ request as well. The probe error paths now unwind runtime PM by hand via goto, and a devm-registered handler is only freed later during devres unwind, so it would stay live across the manual teardown (and across any future failing step added after it). Request the IRQ with request_threaded_irq() and free it explicitly in the probe error path and in remove. The probe error path also clears use_autosuspend, to match the teardown in remove(). | Nov 3, 2026 |
| CVE-2026-99247(opens NVD record) | Unscored | — | In the Linux kernel, the following vulnerability has been resolved: tracing: Do not initialize tracefs work if tracing is disabled If trace buffer allocation fails during early boot (e.g. in early_trace_init() -> allocate_trace_buffers()), tracing_disabled is left set to 1 and the global trace array events list remains uninitialized. Later during boot, tracer_init_tracefs() (invoked via fs_initcall) queues tracerfs_init_work asynchronously without checking if tracing was disabled. When tracer_init_tracefs_work_func() runs, it calls event_trace_init() and init_tracer_tracefs(&global_trace, NULL) unconditionally. This leads to __find_event_file() dereferencing an uninitialized tr->events list, causing an early boot NULL pointer dereference Oops: BUG: Kernel NULL pointer dereference on read at 0x00000010 Faulting instruction address: 0xc000000000485be0 Oops: Kernel access of bad area, sig: 7 [#1] ... NIP [c000000000485be0] __find_event_file+0x70/0x3c0 LR [c000000000448874] init_tracer_tracefs+0x274/0xc80 Call Trace: init_tracer_tracefs+0x274/0xc80 tracer_init_tracefs_work_func+0x50/0x320 process_one_work+0x1e8/0x5c0 worker_thread+0x1dc/0x3d0 kthread+0x194/0x1b0 start_kernel_thread+0x14/0x18 Check tracing_disabled at the beginning of tracer_init_tracefs_work_func() and return immediately if tracing is disabled or failed to initialize, preventing the crash. | Nov 3, 2026 |
| CVE-2026-99246(opens NVD record) | High | 8.1 | In the Linux kernel, the following vulnerability has been resolved: tipc: protect node reset trace dump with node lock The tipc_node_reset_links trace event asks tipc_node_dump() to walk the node's link entries. Unlike the other node events that request link data, this event runs without the node lock. This permits bearer teardown to free a link while the trace callback is dumping it: CPU 0 CPU 1 trace_tipc_node_reset_links() tipc_node_dump() l = n->links[0].link tipc_node_write_lock() kfree(l) n->links[0].link = NULL tipc_node_write_unlock() tipc_link_dump(l) tipc_link_dump() then dereferences the stale pointer. KASAN reported: BUG: KASAN: slab-use-after-free in tipc_link_dump Read of size 4 by task poc/115 Call Trace: tipc_link_dump+0x10cb/0x16b0 tipc_node_dump+0x4bb/0x740 trace_event_raw_event_tipc_node_class+0x258/0x360 tipc_node_reset_links+0x14d/0x1a0 tipc_rcv+0x13f5/0x3030 tipc_udp_recv+0x4e3/0x670 Allocated by task 0: tipc_link_create+0x1e1/0x1020 tipc_node_check_dest+0x7d2/0x11a0 tipc_disc_rcv+0xdbf/0x1430 Freed by task 89: kfree+0x131/0x3c0 tipc_node_link_down+0x267/0x4b0 tipc_node_delete_links+0xec/0x160 bearer_disable+0x107/0x260 Take the node write lock around the trace event. This serializes the dump against tipc_node_link_down(delete=true), which frees the link under the same write lock. | Nov 3, 2026 |
| CVE-2026-99245(opens NVD record) | Unscored | — | In the Linux kernel, the following vulnerability has been resolved: KEYS: Fix key_reject_and_link() race with keyring restriction The restrict_link check in key_reject_and_link() is done before taking the keyring semaphore, racing with a concurrent keyring_restrict() that installs the restriction while holding the semaphore in write mode. Move the check to after __key_link_lock(), so it is done under the semaphore, matching the pattern used in __key_create_or_update(). | Nov 3, 2026 |
| CVE-2026-99244(opens NVD record) | Unscored | — | In the Linux kernel, the following vulnerability has been resolved: pid_namespace: prevent TIF_NOTIFY_SIGNAL from interrupting the reaper Since commit 7fea700e04bd ("zap_pid_ns_processes: clear TIF_NOTIFY_SIGNAL along with TIF_SIGPENDING") zap_pid_ns_processes() clears TIF_NOTIFY_SIGNAL before every kernel_wait4() call. Otherwise kernel_wait4() doesn't sleep and returns -ERESTARTSYS if signal_pending() is true and the reaper busy-waits. But clearing TIF_NOTIFY_SIGNAL doesn't fix it. It can get raised again. For example, klp_send_signals() sets it raw against any task that hasn't transitioned yet. And it keeps sending it until the livepatch finishes. The sleep loop waiting for pid_allocated to drop has the same problem and it doesn't even clear anything. So a schedule() in TASK_INTERRUPTIBLE returns immediately. Use a no_notify_signal guard. signal_pending() will ignore TIF_NOTIFY_SIGNAL and the pid namespace reaper sleeps until a child exits or free_pid() wakes it. | Nov 3, 2026 |
| CVE-2026-99243(opens NVD record) | Unscored | — | In the Linux kernel, the following vulnerability has been resolved: io-wq: order the exit bit against worker creation task work io_wq_exit_workers() cancels task work for queued worker creation with task_work_cancel_match(). That has a plain load of task->task_works. io_queue_worker_create() adds the new entry and tests IO_WQ_BIT_EXIT to cancel it if the workqueue is already on its way out. That must be ordered. task_work_add() has a full barrier via cmpxchg(). But io_wq_exit_start() sets the bit with set_bit() which doesn't have any memory ordering. So afaict, on weakly ordered architectures the exiting task may load task_works before the store of the bit is visible. The other side tests the bit before the store is visible as well. So the entry remains queued with worker_refs and the exiting task waits on worker_done indefinitely. If the task still has rings then io_uring_del_tctx_node() provides the barrier via test_and_set_bit() in io_wq_set_exit_on_idle(). When it has closed all rings though that barrier is gone. Add the barrier after the set_bit(). | Nov 3, 2026 |
| CVE-2026-114442(opens NVD record) | Unscored | — | Apache HertzBeat versions 1.7.1, 1.7.2, 1.7.3, 1.8.0, and 1.9.0 have incomplete XPath expression validation in the HTTP collector XML parsing path. An authenticated user with permission to create monitor templates can supply XPath expressions through metrics.aliasFields that are evaluated without the validation applied to parseScript. When processing a crafted XML response, repeated evaluation may consume excessive CPU resources and impair collector availability. This is a follow-up to the incomplete fix for CVE-2026-24343. The fix is included in Apache HertzBeat 1.9.1. Users should upgrade to 1.9.1 or a later version. | Nov 3, 2026 |
| CVE-2026-89293(opens NVD record) | Unscored | — | 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. | Nov 3, 2026 |
| CVE-2026-89292(opens NVD record) | Unscored | — | In Eclipse Mnestix Browser versions 1.6.0 up until but excluding 2.3.0 it was possible for an unauthenticated attacker to exfiltrate the MNESTIX_BACKEND_API_KEY for all configured Infrastructures. | Nov 3, 2026 |
| CVE-2026-89229(opens NVD record) | Unscored | — | Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal') in the ShareActivity component of BlueLM Copilot (com.vivo.ai.copilot) allows a malicious application installed on the same device to write arbitrary files via a crafted ACTION_SEND intent with a ContentProvider-supplied file name containing '..' sequences. | Nov 3, 2026 |
| CVE-2026-77778(opens NVD record) | High | 7.1 | ZohoCorp ManageEngine Key Manager Plus versions up to 7150 allow authenticated users to export certificates belonging to other users to their own registered key vaults. | Nov 3, 2026 |
| CVE-2026-77777(opens NVD record) | High | 7.1 | ManageEngine Key Manager Plus versions before 7151 are vulnerable to an improper access control issue that allow authenticated users to modify another user's ACME certificate deployment credentials. | Nov 3, 2026 |
| CVE-2026-77691(opens NVD record) | High | 8.1 | ZohoCorp ManageEngine Key Manager Plus versions before 7151 allow authenticated users to enter malicious input when configuring a Microsoft CA | Nov 3, 2026 |
| CVE-2026-120333(opens NVD record) | Unscored | — | The actions linked in the emails of the extension (e.g. to confirm a registration or the deletion of an account) do not reject requests with a missing or invalid hash. Instead, the frontend user given in the request is used. Unauthenticated attackers can therefore perform these actions for arbitrary active frontend users. This allows them to retrieve the email address or username of all frontend users and to delete arbitrary frontend user accounts. | Nov 3, 2026 |
| CVE-2026-120332(opens NVD record) | Unscored | — | The HTML content of mails and tracked URLs are rendered unescaped in the backend module. Backend users with access to the mail module can inject arbitrary HTML and JavaScript, which is executed in the context of other backend users viewing the mail preview or report. | Nov 3, 2026 |
| CVE-2026-120331(opens NVD record) | Unscored | — | Content of external URL mails, their stylesheets and images to embed is fetched by the server without validating the target host. Backend users with access to the mail module can make the server send requests to hosts in the internal network. | Nov 3, 2026 |
| CVE-2026-120330(opens NVD record) | Unscored | — | Backend actions and ajax routes of the mail module do not check whether the backend user has access to the page of the requested mail or recipient group. Backend users with access to the mail module can view, change, send and export mails and recipient groups outside their web mounts, including the personal data of recipients. | Nov 3, 2026 |
| CVE-2026-120329(opens NVD record) | Unscored | — | Saving the configuration of the mail backend module writes submitted settings to the page TSconfig without restricting them to the configuration options of the module. Backend users with access to the mail module can write arbitrary page TSconfig. | Nov 3, 2026 |
| CVE-2026-120328(opens NVD record) | Unscored | — | The click tracking middleware does not validate the authentication code of a recipient if the code is omitted. Unauthenticated attackers can retrieve personal data of newsletter recipients, which is inserted into links of sent mails. | Nov 3, 2026 |
| CVE-2026-120327(opens NVD record) | Unscored | — | The click tracking middleware accepts an arbitrary target URL and redirects to it. Attackers can misuse links to the website to redirect users to external sites. | Nov 3, 2026 |
| CVE-2026-119843(opens NVD record) | Medium | 6.5 | A flaw was found in GStreamer's gst-plugins-good package. The FLV media demuxer does not properly validate buffer sizes and data availability when processing enhanced audio and video tags in malformed or truncated FLV streams. A remote attacker could exploit this vulnerability by providing a specially crafted FLV media file that, when opened or streamed by a GStreamer-based application, triggers an assertion failure or a process crash, leading to denial of service. | Nov 3, 2026 |
| CVE-2026-119724(opens NVD record) | Unscored | — | ** UNSUPPORTED WHEN ASSIGNED ** Improper restriction of recursive entity references in DTDs ('XML entity expansion') vulnerability in Apache JClouds. This issue affects Apache JClouds: all versions. As this project is retired, we do not plan to release a version that fixes this issue. Users are recommended to find an alternative or restrict access to the instance to trusted users. NOTE: This vulnerability only affects products that are no longer supported by the maintainer. | Nov 3, 2026 |
| CVE-2026-119641(opens NVD record) | Unscored | — | ** UNSUPPORTED WHEN ASSIGNED ** Improper input validation vulnerability in Apache Oozie. An authenticated Oozie user can reconfigure another tenant's workflow job and change its ownership. This issue affects Apache Oozie: all versions. As this project is retired, we do not plan to release a version that fixes this issue. Users are recommended to find an alternative or restrict access to the instance to trusted users. NOTE: This vulnerability only affects products that are no longer supported by the maintainer. | Nov 3, 2026 |
| CVE-2026-92610(opens NVD record) | Unscored | — | In esmf-sdk-py-aspect-model-loader versions 2.1.2 to 2.2.1, the Aspect Model loader resolves cross-file model references by extracting the third and fourth colon-separated components of any urn:samm:… namespace declared in a parsed Turtle file to build a directory to scan. A model file containing @prefix x: <urn:samm:../../../foo:bar#> or @prefix x: <urn:samm:/abs/path:bar#> causes the loader to glob and parse *.ttl files from arbitrary directories outside the intended models root, merging their contents into the returned graph. | Nov 3, 2026 |
| CVE-2026-91075(opens NVD record) | Medium | 5.3 | The Eupago Gateway For Woocommerce WordPress plugin from 4.5.0 through 4.7.5 does not verify the authenticity of incoming payment-confirmation webhook requests in some configurations, allowing unauthenticated attackers to forge a payment confirmation and mark a pending order as paid without paying for it. | Nov 3, 2026 |
| CVE-2026-121024(opens NVD record) | Medium | 5.4 | Incorrect Authorization (CWE-863) in the Health Monitoring service in AxxonSoft AxxonNet before 3.28.0 on Linux allows a remote attacker in possession of a shared report token, which is intended for read-only access, to create, modify or delete monitoring alerts via the monitoring API. | Nov 3, 2026 |
| CVE-2026-121023(opens NVD record) | Medium | 5.5 | Insertion of Sensitive Information into Log File (CWE-532) in the ARP Agent component in AxxonSoft AxxonNet before 3.25.0 on Windows and Linux allows a local attacker with read access to ARP Agent log files or support packages to obtain the plaintext password of the LDAP directory service account via WARNING-level log entries that contain serialized user synchronization data. | Nov 3, 2026 |
| CVE-2026-121022(opens NVD record) | High | 8.1 | Use of Default Password (CWE-1393) in the web client in AxxonSoft Axxon One before 3.0.0 on Windows and Linux allows a remote unauthenticated attacker to log in as the built-in administrator with the default credentials on a newly installed system, because the web client did not enforce the mandatory change of the default password on first login. | Nov 3, 2026 |
| CVE-2026-121021(opens NVD record) | Medium | 5.5 | Plaintext Storage of a Password (CWE-256) in the SecurityManager shared configuration in AxxonSoft Axxon One before 3.1.0 on Windows and Linux allows a local attacker with read access to the configuration directory or to configuration backups to obtain the password of the LDAP directory service account via the main.conf configuration file. | Nov 3, 2026 |
| CVE-2026-121020(opens NVD record) | Medium | 4.3 | Exposure of Sensitive Information to an Unauthorized Actor (CWE-200) in the security configuration API in AxxonSoft Axxon One before 3.2.0 on Windows and Linux allows a remote authenticated user with limited privileges to enumerate all user accounts and roles configured in the system via the user configuration request, which returned the complete lists of users and roles regardless of the caller's permissions. | Nov 3, 2026 |
| CVE-2026-118448(opens NVD record) | Unscored | — | A use of uninitialized memory vulnerability in the pybddisasm Python bindings affects nd_to_text. If the underlying text conversion fails, including failures caused by invalid parameters, the output buffer may remain uninitialized while still being converted into a Python return value. This may disclose residual process memory or cause the Python process to crash. Exploitation requires an application to invoke nd_to_text in a way that causes conversion to fail and to return or otherwise use the resulting output. The pybddisasm package is no longer maintained. | Nov 3, 2026 |
| CVE-2026-118447(opens NVD record) | Unscored | — | A use of uninitialized memory vulnerability in the pybddisasm Python bindings may disclose process memory when instruction decoding fails. The nd_decode, nd_decode_ex, nd_decode_ex2, and nd_decode_with_context functions may return an INSTRUX object whose contents have not been initialized after an unsuccessful decoding operation, including failures caused by invalid parameters. Accessing members of the returned object may expose residual process memory. Exploitation requires an application to access and expose the returned object contents after a decoding failure. The pybddisasm package is no longer maintained. | Nov 3, 2026 |
| CVE-2026-118446(opens NVD record) | Unscored | — | A use-after-free vulnerability in the pybddisasm Python bindings affects array-valued members of INSTRUX objects, including ND_OPERAND arrays. These arrays are exposed as Python lists whose elements reference memory owned by the parent INSTRUX object. Retaining a list or an element does not keep the parent allocation alive. Accessing an element after the parent INSTRUX object has been freed therefore accesses freed memory. Depending on how the element is used and whether the freed allocation has been reused, this may expose process memory or cause the Python process to crash. Exploitation requires an application to retain and subsequently access an array element after the parent object has been freed. The pybddisasm package is no longer maintained. | Nov 3, 2026 |
| CVE-2026-118445(opens NVD record) | Unscored | — | A use-after-free vulnerability in the pybddisasm Python bindings affects structure-valued members of INSTRUX objects. These members are exposed through Python objects that reference memory owned by the parent INSTRUX object. A retained reference to a member does not keep the parent allocation alive. Accessing the member after the parent INSTRUX object has been freed therefore accesses freed memory. Depending on how the member is used and whether the freed allocation has been reused, this may expose process memory or cause the Python process to crash. Exploitation requires an application to retain and subsequently access a member reference after the parent object has been freed. The pybddisasm package is no longer maintained. | Nov 3, 2026 |
| CVE-2026-118444(opens NVD record) | Unscored | — | Out-of-bounds read vulnerabilities in the pybddisasm Python bindings may disclose adjacent process memory during instruction decoding. The nd_decode function may read up to 15 bytes without checking the actual length of the supplied Python buffer. The nd_decode_ex, nd_decode_ex2, and nd_decode_with_context functions pass the caller-supplied buffer size to the decoder without validating it against the actual length of the Python buffer. Data read beyond the buffer may be exposed through nd_get_instrux_bytes, which returns a fixed-length list of 16 bytes. Exploitation requires an application to invoke the affected APIs with a short buffer or an oversized length and to expose the resulting bytes to an attacker. The pybddisasm package is no longer maintained. | Nov 3, 2026 |
| CVE-2026-115231(opens NVD record) | Unscored | — | 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. | Nov 3, 2026 |
| CVE-2026-113421(opens NVD record) | Unscored | — | 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. | Nov 3, 2026 |
| CVE-2026-109161(opens NVD record) | Medium | 4.9 | Insufficient bounds checking in the Digital I/O function may allow a remote attacker with high privileges to cause a denial of service. | Nov 3, 2026 |
| CVE-2026-105982(opens NVD record) | High | 7.2 | Improper input validation in the IPsec VPN function may allow a remote attacker with high privileges to inject system commands and execute them with root privileges. | Nov 3, 2026 |
| CVE-2026-105981(opens NVD record) | High | 7.2 | Improper input validation in the Digital I/O function may allow a remote attacker with high privileges to inject operating system commands and execute them with root privileges. | Nov 3, 2026 |