Information Disclosure

In the Linux kernel, the following vulnerability has been resolved: fbdev: serialize mode sysfs access with lock_fb_info() show_mode(), show_modes(), and store_mode() access fb_info->modelist and fb_info->mode without holding lock_fb_info(). store_modes() takes lock_fb_info() while replacing the modelist and freeing the old one. A concurrent reader or writer can load a pointer to an old modelist entry before store_modes() frees it, then dereference freed memory or store a stale freed pointer in fb_info->mode. Take lock_fb_info() in show_mode(), show_modes(), and store_mode() to serialize with store_modes(). In show_mode(), copy the mode to the stack and format after dropping the lock. In store_mode(), split activate() into a _locked variant to avoid double-locking, and hold the locks for the modelist walk, mode conversion, activation, and fb_info->mode assignment together.

In the Linux kernel, the following vulnerability has been resolved: mptcp: pm: fix memory leak from alloc-during-teardown race mptcp_pm_destroy() empties msk->pm.anno_list and msk->pm.userspace_pm_local_addr_list under msk->pm.lock during socket teardown, dropping the lock between the two. A concurrent userspace PM genl ANNOUNCE on the same msk holds a sock reference via mptcp_token_get_sock() and, in mptcp_pm_nl_announce_doit(), calls mptcp_userspace_pm_append_new_local_addr() and mptcp_pm_announced_alloc(). Both take msk->pm.lock briefly to add to their respective lists. Because the genl handler holds a sock reference, mptcp_pm_destroy() may run on the same msk via mptcp_disconnect(), which invokes mptcp_destroy_common() without dropping the sock refcount, before the handler completes. If the lock acquisitions interleave such that mptcp_pm_destroy() empties a list first, the later alloc adds its entry to a list head that nothing else iterates for this msk, and the entry leaks. kmemleak reports both mptcp_pm_add_addr objects (from mptcp_pm_announced_alloc()) and mptcp_pm_addr_entry objects (from mptcp_userspace_pm_append_new_local_addr()) under sustained concurrent ANNOUNCE + close load against the userspace PM. Add an MPTCP_PM_DESTROYING bit in msk->pm.status, set by mptcp_pm_destroy() under pm.lock before the lists are emptied and checked under pm.lock by the alloc paths. Either the alloc takes pm.lock first, in which case its entry is on the list when mptcp_pm_destroy() frees it; or mptcp_pm_destroy() takes pm.lock first, in which case the later alloc observes the bit and refuses. Found by an MPTCP protocol-flow harness extending BRF (arXiv:2305.08782).

In the Linux kernel, the following vulnerability has been resolved: HID: magicmouse: do not keep a stale msc->input if no input is claimed magicmouse_input_mapping() caches the first hid_input's input_dev in msc->input while the report descriptor is parsed, and the rest of the driver treats a non-NULL msc->input as proof that an input device was registered. That does not hold on the hid-input error path. If hidinput_connect() fails -- for instance because input_register_device() returns an error -- it unwinds through hidinput_disconnect(), which frees every input_dev it created, including the one cached in msc->input. The failure does not abort the probe. hid_connect() only skips the claim: if ((connect_mask & HID_CONNECT_HIDINPUT) && !hidinput_connect(hdev, connect_mask & HID_CONNECT_HIDINPUT_FORCE)) hdev->claimed |= HID_CLAIMED_INPUT; and the "device has no listeners" bailout below it does not fire for this driver, which sets ->raw_event; on the USB Magic Mouse 2 / Magic Trackpad 2 paths hidraw and hiddev are claimed as well. hid_hw_start() therefore returns 0 and magicmouse_probe() continues with msc->input pointing at freed memory. Being non-NULL, it passes the "input not registered" check in probe and the NULL checks in ->raw_event and ->event, so the next input report dereferences freed memory. Clear msc->input when the HID core did not claim an input device, so the existing NULL checks cover this case as well.

In the Linux kernel, the following vulnerability has been resolved: net/ionic: avoid OOB TX partner lookup for hwstamp RXQ The dedicated hardware timestamp RX queue is allocated with q->index equal to lif->ionic->nrxqs_per_lif. The normal txqcqs array only contains the regular queue pairs, so using that index to set rxq->partner can read one entry past txqcqs[] and then write through the derived pointer. Only link RX/TX partners for normal queue-pair indexes. Leave the hwstamp RX queue unpaired, and make the XDP_TX path abort cleanly if an RX queue has no TX partner.

In the Linux kernel, the following vulnerability has been resolved: futex/pi: Reject cross-mm private futex owners A private futex key borrows the waiter's mm without taking an mm_users reference. Nevertheless, attach_to_pi_owner() currently accepts an owner from a different address space and copies the private key into the owner's PI state. When that owner exits, exit_pi_state_list() uses the saved key to find the hash bucket and acquires a reference to the waiter's private hash. If the last user of the waiter's mm exits concurrently, futex_hash_free() frees the hash while the owner still uses its bucket and reference. Prevent this by validating in attach_to_pi_owner() that, for private futexes, the owner mm and waiter mm are the same. Perform the check with the owner's pi_lock held and after validating owner::futex::state to serialize against a concurrent PI-state exit cleanup. [ tglx: Amended comment ]

In the Linux kernel, the following vulnerability has been resolved: futex/pi: Plug private futex exec() race The check for private futexes whether the waiter's mm, which is stored in the futex_key and copied into the pi_state, is the same as the owner's mm is not sufficient for exec(). exec() has a gap where the mm check fails to give the correct answer: exec() ... exec_release_mm() futex_exec_release() tsk::futex::exit_state = EXITING; cleanup_robust_list(); 1) tsk::futex::exit_state = OK; ... old_mm = tsk::mm; 2) tsk::mm = ->mm; Between #1 and #2 the check for the mm is wrong as that mm is about to be swapped out and eventually freed. Plug this gap by: 1) Setting tsk::futex::exit_state to FUTEX_STATE_DEAD in futex_exec_release() 2) Setting tsk::futex::exit_state to FUTEX_STATE_OK after the mm has been switched. From a futex point of view the task is dead after it finished the robust list cleanup up to the point where it sets the state to OK again.

In the Linux kernel, the following vulnerability has been resolved: futex: Fix race in futex_pivot_pending() during private hash resize A task performing a custom private hash resize can remain blocked in uninterruptible sleep indefinitely. The hung-task detector reports: INFO: task futex-resizer:314 blocked for more than 10 seconds. task:futex-resizer state:D stack:14824 pid:314 tgid:312 ppid:311 Call Trace: __schedule+0x521/0xf30 schedule+0x22/0xa0 futex_hash_allocate+0x3db/0x490 __do_sys_prctl+0x6f5/0xbd0 do_syscall_64+0xf9/0x530 entry_SYSCALL_64_after_hwframe+0x77/0x7f Kernel panic - not syncing: hung_task: blocked tasks futex_pivot_pending() allows the resize request to continue when either no replacement hash is pending (hash_new == NULL) or the current hash reference count has reached zero. After the final-reference wake, another futex task can complete the pivot between the two observations: T1 T2 futex_hash_allocate() wait_var_event(mm, ...) futex_pivot_pending(mm) hash_new != NULL futex_hash() futex_ref_get(old) -> false futex_pivot_hash(mm) hash_new = NULL __futex_pivot_hash(mm, new) rcu_assign_pointer(hash, new) fph = rcu_dereference(hash) /* new */ futex_ref_is_dead(fph) -> false schedule() The pivot changes the state from hash_new != NULL with a dead current hash to hash_new == NULL with a live current hash. Because futex_pivot_pending() reads hash_new and hash without serialization, the resize task can observe hash_new in the pre-pivot state and hash in the post-pivot state, causing futex_pivot_pending() to return false even though the pivot has completed. The task then goes to sleep after the wakeup has already been consumed. Serialize state reads in futex_pivot_pending() using futex_mm_phash::lock. This guarantees that futex_pivot_pending() observes hash_new and hash atomically, eliminating the race condition.

In the Linux kernel, the following vulnerability has been resolved: futex: Fix race on the initial mm->futex.phash.ref allocation futex_hash_allocate() allocates mm->futex.phash.ref without any locking. Commit d9b05321e21e ("futex: Move futex_hash_free() back to __mmput()") moved the allocation here and assumed that the process has just a single thread at this point. Commit ee9dce44362b ("futex: Drop CLONE_THREAD requirement for private default hash alloc") widened need_futex_hash_allocate_default() to cover any CLONE_VM clone, but left out vfork because the parent is suspended and cannot race. That no longer holds once vfork is nested. If a vfork child calls vfork again and is then killed with SIGKILL, the parent is released from its vfork wait and runs concurrently with the grandchild in the same mm. Neither of them went through futex_hash_allocate_default(). When both call prctl(PR_FUTEX_HASH, PR_FUTEX_HASH_SET_SLOTS) at the same time, each one sees mm->futex.phash.ref as NULL and stores its own percpu counter. Only the last store survives. The counter stored first is no longer reachable from the mm, so the references on it are not seen by __futex_ref_atomic_end(). A private hash that still has references is then considered dead and freed, and a task that still holds one of its buckets writes into freed memory in futex_q_lock(). Store the counter once with cmpxchg() and let the loser free_percpu() its own. The initial reference has to be taken before the store, otherwise another task can install a private hash while the counter is still 0.

In the Linux kernel, the following vulnerability has been resolved: HID: asus: fix missing hid_is_usb() check to_usb_interface() can only be used on a hid_device whose parent is really USB; uhid can create devices that identify as being on BUS_USB, but don't actually have a USB parent. Fix the use of to_usb_interface() without a hid_is_usb() check. I have verified that it is currently possible to trigger a kernel splat due to this bug in an ASAN build, and that this commit fixes the issue.

In the Linux kernel, the following vulnerability has been resolved: HID: huawei: fix missing hid_is_usb() check to_usb_interface() can only be used on a hid_device whose parent is really USB; uhid can create devices that identify as being on BUS_USB, but don't actually have a USB parent. Fix the use of to_usb_interface() without a hid_is_usb() check. I have verified that it is currently possible to trigger a kernel splat due to this bug in an ASAN build, and that this commit fixes the issue.

In the Linux kernel, the following vulnerability has been resolved: HID: nintendo: register input device after capabilities are set input_register_device() exposes the device to userspace immediately. In joycon_input_create() it was called before joycon_config_rumble() configures the FF_RUMBLE capability and the memless force-feedback device, so a concurrent EVIOCSFF could dereference a NULL dev->ff. Registering early also means the initial udev event lacks button and axis information, which can make input managers ignore the device. Move input_register_device() to the end of joycon_input_create(), after all capabilities, the IMU input device and the force-feedback callbacks have been configured.

In the Linux kernel, the following vulnerability has been resolved: HID: nintendo: stop device IO before hid_hw_stop on probe failure nintendo_hid_probe() calls hid_device_io_start() before joycon_init() and joycon_leds_create(). If either fails, the error path jumps to err_close which calls hid_hw_close()/hid_hw_stop() without first calling hid_device_io_stop(). hid_hw_stop() does not stop device IO, so hid_input_report() may still run and access driver data that is being torn down, resulting in a use-after-free. Add an err_io_stop label that calls hid_device_io_stop() before hid_hw_close(), and point the two post-io_start error paths at it.

In the Linux kernel, the following vulnerability has been resolved: HID: rapoo: fix missing hid_is_usb() check to_usb_interface() can only be used on a hid_device whose parent is really USB; uhid can create devices that identify as being on BUS_USB, but don't actually have a USB parent. Fix the use of to_usb_interface() without a hid_is_usb() check. Add a dependency on USB_HID for hid_is_usb(), as other HID drivers do; the alternative would be to provide a simple stub implementation on !USB_HID builds. I have verified that it is currently possible to trigger a kernel splat due to this bug in an ASAN build, and that this commit fixes the issue.

In the Linux kernel, the following vulnerability has been resolved: HID: ft260: fix stack-use-after-return write in I2C read race ft260_i2c_read() points dev->read_buf at a caller-supplied buffer (often an on-stack variable), arms a completion and waits up to five seconds for the device to return the data. The HID input callback ft260_raw_event() runs in the input/IRQ path, independent of the dev->lock mutex held by the read path, and copies the device-supplied payload into dev->read_buf after a plain NULL check. These two paths share read_buf, read_idx and read_len with no serialization. If the device delays its response until the read times out, ft260_i2c_read() resets the controller, clears read_buf and returns, unwinding the stack frame the buffer lived in. A response that arrives at that moment lets ft260_raw_event() pass the NULL check and then memcpy() the device-controlled payload into the now-freed stack location, a bounded but attacker-influenced stack-use-after-return write triggerable by malicious or malfunctioning hardware. Add a dedicated spinlock that serializes every access to read_buf, read_idx and read_len. ft260_raw_event() now holds it across the NULL check, the memcpy and the index update, while the read path takes it when arming and when clearing the buffer, so the teardown can no longer slip between the check and the copy.

In the Linux kernel, the following vulnerability has been resolved: HID: sensor: custom: Fix use-after-free in enable_sensor enable_sensor_store() can call set_power_report_state(), which dereferences sensor_inst->power_state and sensor_inst->report_state. These pointers refer to entries in sensor_inst->fields. Create the field attributes before exposing the enable_sensor sysfs attribute, so enable_sensor cannot be accessed before the state it depends on has been initialized. On remove, delete enable_sensor before freeing the field attributes, so a concurrent sysfs write cannot dereference freed memory through power_state or report_state.

In the Linux kernel, the following vulnerability has been resolved: HID: uclogic: fix use-after-free of inrange_timer on remove uclogic_remove() cancels the pen in-range timer and then stops the device: timer_delete_sync(&drvdata->inrange_timer); hid_hw_stop(hdev); timer_delete_sync() only guarantees the timer is idle at that instant. uclogic_raw_event_pen() keeps delivering pen reports until hid_hw_stop() stops the transport several lines later, and every report with pen->inrange == UCLOGIC_PARAMS_PEN_INRANGE_NONE re-arms the timer: mod_timer(&drvdata->inrange_timer, jiffies + msecs_to_jiffies(100)); A report landing between the timer_delete_sync() call and the transport teardown in hid_hw_stop() re-arms inrange_timer after it was cancelled. uclogic_remove() then returns and the devm drvdata is freed, while hid_hw_stop() has already freed the input device drvdata->pen_input points at, so when the timer fires ~100 ms later uclogic_inrange_timeout() dereferences freed memory -- a use-after-free in timer-softirq context. Swapping the two calls is not a fix: stopping the device first frees drvdata->pen_input via hidinput_disconnect() while the timer may still be pending, so a timer already armed before removal fires on the freed input device in the window before timer_delete_sync() runs. Use timer_shutdown_sync() before hid_hw_stop() instead. It cancels the timer, waits for a running callback while pen_input is still valid, and prevents any further re-arming -- a later mod_timer() from an in-flight report is silently ignored -- so the timer is provably dead before hid_hw_stop() frees the inputs. This is the ordering the timer core documents for this "timer re-armed from another path" teardown case.

In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_event: fix LE list UAF on reset hci_cc_reset() clears the LE accept and resolving lists without taking hdev->lock. Other command-complete handlers serialize updates to these lists with that lock, and the debugfs readers hold it while walking them. This permits the reset completion and a debugfs read to interleave as follows: hci_rx_work debugfs reader ----------- -------------- lock hdev->lock fetch current entry list_del(entry) kfree(entry) read entry fields The reader then dereferences a freed list entry and may follow its stale next pointer. KASAN reported: BUG: KASAN: slab-use-after-free in white_list_show+0x15f/0x180 Read of size 1 at addr ffff8881015dab16 by task poc/95 Call Trace: white_list_show+0x15f/0x180 seq_read_iter+0x3ff/0x1190 seq_read+0x267/0x3d0 vfs_read+0x177/0xa20 ksys_read+0xf7/0x1c0 Allocated by task 91: hci_bdaddr_list_add+0x1a6/0x3a0 hci_cc_le_add_to_accept_list+0xab/0x140 hci_cmd_complete_evt+0x26c/0x9a0 hci_event_packet+0x454/0xb20 hci_rx_work+0x293/0x730 Freed by task 90: kfree+0x131/0x3c0 hci_bdaddr_list_clear+0xd8/0x160 hci_cc_reset+0x28a/0x370 hci_cmd_complete_evt+0x26c/0x9a0 hci_event_packet+0x454/0xb20 hci_rx_work+0x293/0x730 Take hdev->lock around both list clears. This matches the existing mutation and traversal locking convention.

In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_event: validate LE Set CIG Parameters response The Command Complete dispatch validates only the fixed part of the LE Set CIG Parameters response. After that part is pulled from the skb, hci_cc_le_set_cig_params() trusts num_handles and reads each entry in the trailing handle array. Matching num_handles against the command's num_cis does not guarantee that the response contains the advertised handles. A truncated response from a malfunctioning controller can therefore make the handler read beyond the skb data. Validate that the remaining skb data contains all advertised handles. Include this in the existing response validation so malformed responses also follow the established CIG failure handling.

In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_sync: Fix accept list UAF during suspend hci_update_event_filter_sync() walks hdev->accept_list while sending a synchronous HCI command for each remote-wakeup device. The suspend path holds hdev->req_lock, but accept-list updates are serialized by hdev->lock. Consequently, remove_device() can free the current list entry during the controller wait. The following interleaving causes the use-after-free: hci_update_event_filter_sync() remove_device() fetch accept-list entry hci_set_event_filter_sync() wait for controller response hci_dev_lock() list_del() kfree() hci_dev_unlock() read the freed list.next KASAN reported: BUG: KASAN: slab-use-after-free in hci_suspend_sync+0x835/0x910 Read of size 8 at addr ffff88810bec8440 by task kworker/0:1/10 Workqueue: events vhci_suspend_work Call Trace: hci_suspend_sync+0x835/0x910 hci_suspend_dev+0x182/0x450 process_one_work+0x661/0x1090 worker_thread+0x45b/0xd10 Allocated by task 86: hci_bdaddr_list_add_with_flags+0x1a8/0x400 add_device+0x381/0x820 hci_sock_sendmsg+0x1033/0x1ea0 Freed by task 91: kfree+0x131/0x3c0 remove_device+0x429/0xb70 hci_sock_sendmsg+0x1033/0x1ea0 Snapshot the remote-wakeup addresses under hdev->lock. Release the lock before sending HCI commands. Clear the controller event filter before building the snapshot, and skip allocation and the second list traversal when there are no matching entries. This preserves the original filter and scan-state updates without retaining an accept-list node across a controller wait.

In the Linux kernel, the following vulnerability has been resolved: Bluetooth: ISO: zero the sockaddr before returning it in getname iso_sock_getname() fills a struct sockaddr_iso in place and returns its size without clearing it first, so bytes it does not write are copied to user space from the kernel stack. The getsockname(2) and getpeername(2) paths both run through do_getsockname(), which hands getname() an uninitialized sockaddr_storage on the stack and copies back up to the number of bytes getname() returns, so the driver has to initialize every byte it accounts for. Two ranges are left uninitialized: - struct sockaddr_iso is 10 bytes but only 9 are written (family, iso_bdaddr, iso_bdaddr_type), leaking the trailing pad byte on every call. - for a broadcast peer (BIS_LINK or PA_LINK) the returned length grows by sizeof(struct sockaddr_iso_bc), but only bc_sid, bc_num_bis and bc_bis are filled; bc_bdaddr and bc_bdaddr_type, the first 7 bytes of that structure, are never written. An unprivileged process can open a BTPROTO_ISO socket and reach the pad leak with getsockname(); the broadcast leak needs an established BIS/PA connection. l2cap and rfcomm already memset their sockaddr in getname for the same reason; do the same here.

In the Linux kernel, the following vulnerability has been resolved: Bluetooth: MGMT: reject HCI_CMD_SYNC params_len above 255 mgmt_hci_cmd_sync() checks that the message length agrees with params_len but puts no upper bound on it. params_len is __le16 while the parameter length in the HCI command header is a u8: struct hci_command_hdr { __le16 opcode; __u8 plen; } __packed; hci_cmd_sync_alloc() assigns one to the other: hdr->plen = plen; if (plen) skb_put_data(skb, param, plen); so a params_len of 256 leaves plen at 0 while all 256 bytes are still appended. The frame handed to the driver then declares no parameters and carries 256 of them. On a length framed transport such as H:4 the controller takes the trailing bytes as the start of the next packet. The mgmt socket MTU is HCI_MAX_FRAME_SIZE, so params_len can reach about 1KB this way. Commit 03f1700b9b4d ("Bluetooth: MGMT: reject malformed HCI_CMD_SYNC commands") only made params_len agree with the message length, a value that fits the message but not the header field is still accepted. Reject params_len that does not fit the header field.

In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_aml: validate firmware segment lengths aml_download_firmware() reads two lengths from the firmware header and uses them to build pointers before checking that the header and segment data are present. A truncated or inconsistent firmware image can make the driver read past firmware->data while constructing TCI commands. Reject images shorter than the header and ensure that the ICCM and DCCM ranges fit within the loaded firmware before downloading either segment.

In the Linux kernel, the following vulnerability has been resolved: futex: Avoid private hash use-after-free on final put futex_private_hash_put() drops the reference to fph before evaluating fph->mm for wake_up_var(). futex_ref_put() enables preemption again before returning. If that put drops the final reference and the task is preempted, another task can pivot to the replacement hash and free the old hash after an RCU grace period. The first task then reads fph->mm from the freed allocation when it resumes. KASAN reports a slab-use-after-free in futex_private_hash_put(), with the read at offset 24 in a freed kmalloc-512 allocation. The allocation and free stacks point to futex_hash_allocate() and the RCU free path, respectively. Load the mm pointer while the fph reference is still held and pass the saved value to wake_up_var(). wake_up_var() uses the pointer as a waitqueue key and does not dereference the mm through it.

Information disclosure in IBM UrbanCode Deploy and IBM DevOps Deploy exposes sensitive deployment secrets in plaintext to authenticated users who should only see redacted values. The root cause is a character-parsing failure in the redaction engine: when a secure property value begins with certain non-ASCII characters, the masking logic fails to suppress subsequent ASCII secure values embedded within non-secure properties, rendering them visible through the UI and REST API. No active exploitation or public POC has been identified; the CVSS score of 6.5 reflects high confidentiality impact (C:H) gated behind low-privilege authentication (PR:L).

Sensitive information disclosure in IBM Enterprise Records (a component of IBM Cloud Pak for Business Automation) allows a local attacker to recover protected data due to the use of a broken or risky cryptographic algorithm (CWE-327). Affected versions span CP4BA releases 24.0.0 through 26.0.0 up to specific interim fix levels. No public exploit code has been identified at time of analysis, and IBM has released interim fixes addressing the cryptographic weakness.

Sensitive database exposure in code-projects Vehicle Management System 1.0 allows unauthenticated remote attackers to download the raw SQL database backup file at /vehicle_management.sql directly over HTTP, leaking the full application database contents. The backup file is stored in or under the web root with no access controls, making it trivially accessible to any internet-connected attacker. A public proof-of-concept is available, and no vendor patch has been identified at time of analysis.

phpMyFAQ versions before 4.1.8 expose TOTP shared secrets in plaintext within user data export ZIP archives, enabling two-factor authentication bypass. Any authenticated user who generates their own data export - or any party who obtains such an archive through secondary means (e.g., misconfigured storage, insider access, or a separate file-disclosure vulnerability) - can extract the raw TOTP seed and compute valid one-time codes indefinitely. No public exploit has been identified at time of analysis, and the vulnerability is not listed in the CISA KEV catalog.

Authenticated readers in SiYuan v3.8.1 can call the POST /api/transactions/undoState endpoint with a known document root ID to retrieve internal root IDs of other documents - including private or unpublished ones - that participated in the same cross-document transaction. The flaw is CWE-639 (IDOR via user-controlled key): the endpoint reads from the global undo-log stack and returns peekMutatedRootIDs without applying publish-access visibility filtering to the returned identifiers. Document body contents are not exposed; however, internal identifiers and cross-document transaction relationships leak across trust boundaries. Vendor-released patch v3.8.2 resolves the issue; no public exploit or CISA KEV listing is known at time of analysis.

Credential redirect vulnerability in Snowflake JDBC Driver 4.2.0-4.3.3 allows a lower-trust principal who can control the account identifier to cause the driver to transmit login credentials to an attacker-chosen HTTPS endpoint rather than Snowflake's legitimate servers. The attack is exclusively exercisable through the jdbc:snowflake:auto connection scheme when the connections.toml configuration omits an explicit host value; applications using ordinary JDBC URLs are entirely unaffected. Captured credentials are reusable and can be replayed against Snowflake infrastructure to gain the full privileges of the victimized account. Vendor-released patch 4.3.4 is available and requires manual upgrade; no public exploit or CISA KEV listing has been identified at time of analysis.

mTLS certificate reuse in Checkmk before 2.5.0p10 enables a relay or push agent to authenticate against agent receiver endpoints using a peer component's certificate, provided both share the same UUID. The agent receiver endpoints fail to verify that a presented client certificate was issued by their own root CA, breaking the intended role-based trust boundary between relay and push agent components. No public exploit has been identified, and exploitation requires an attacker to already control one of the affected agent components (PR:L), limiting realistic risk despite the network-reachable vector.

Pik Online Portal through version 3.5.1 stores hashes without cryptographic salts (CWE-759), exposing stored credentials to offline cryptanalysis via rainbow table or precomputed dictionary attacks. The CVSS vector (PR:L/UI:R) indicates that a low-privileged attacker who can access hash data - and where some user interaction occurs to trigger or expose the hash - can recover plaintext passwords with high confidentiality impact. No public exploit code or active exploitation has been identified at time of analysis; this was reported by TR-CERT (Turkish national cybersecurity authority).

Unauthenticated information disclosure in the Xpro Addons - 140+ Widgets for Elementor WordPress plugin (versions before 1.7.8) exposes non-public WooCommerce product data - including titles, prices, SKUs, descriptions, and stock levels - to any visitor without authentication. The plugin renders product summaries via a widget endpoint without performing any post-status or capability check, meaning products in draft, pending, private, or scheduled states are fully retrievable by arbitrary external requesters. A publicly available exploit has been documented by WPScan, though no active exploitation has been confirmed by CISA KEV.

Unauthenticated log file exposure in WPFunnels WordPress plugin (versions 2.6.0 through <3.13.0) enables any remote visitor to retrieve customer order details and opt-in form submission data by directly requesting a predictable log file URL within the public uploads directory. The flaw affects e-commerce funnel operators who may store customer PII - names, emails, purchase data - in these logs, with potential GDPR/privacy regulatory consequences beyond the C:L CVSS rating suggests. A publicly available proof-of-concept exists; no public exploit or CISA KEV listing indicates active mass exploitation at time of analysis.

Arbitrary file read in the Pods WordPress plugin before 3.3.9.2 allows users holding the Author role or higher to exfiltrate any file accessible to the web server process, including sensitive files outside the web root such as wp-config.php or system credentials. The flaw stems from the plugin's display callback resolver accepting unrestricted PHP callable targets without allowlisting. A publicly available proof-of-concept exists per WPScan, and a vendor patch is available. The attack surface is limited to installations operating in restricted display-callback mode, which is the automatic default for WordPress sites whose initial Pods installation predated version 3.1.

Unauthenticated information disclosure in the Content Views WordPress plugin before 4.5.1.2 allows any remote visitor to read the title and full body of non-public posts - including drafts, pending, private, and scheduled posts - when a site administrator has configured a view to include them. The root cause is a missing authorization check: the plugin never verifies whether the requesting user holds the WordPress capability required to read posts in restricted statuses before serving them in view responses. A publicly available proof-of-concept exists via WPScan; the vendor has released a patched version (4.5.1.2).

Out-of-bounds GPU memory access in Imagination Technologies Graphics DDK allows kernel-level code executing inside a Guest VM to read from, and potentially write to, GPU memory regions outside its allocated virtualized address space via a TOCTOU race condition in GPU firmware validation. Affected versions span multiple DDK release trains including 1.18 RTM2, 23.2 RTM2, 24.2 RTM2, 25.1-25.3 RTM, and 26.1 RTM1 as enumerated in EUVD-2026-70858. No public exploit code has been identified at time of analysis, and the 0.11% EPSS score places this in the first percentile for exploitation probability, indicating no observed active exploitation.

Apache SkyWalking's PagerDuty alarm hook in versions 9.6.0 through 10.x transmits the PagerDuty integration routing key inside an unencrypted HTTP POST body before any redirect response from PagerDuty's HTTPS-only endpoint is received. Because the initial TCP socket write occurs in plaintext prior to the 301/302 redirect, a passive eavesdropper or MITM attacker positioned between the SkyWalking host and PagerDuty's API can capture the routing key verbatim from network traffic. No public exploit code has been identified and no active exploitation is confirmed; the practical impact is unauthorized PagerDuty event submission using the stolen credential, enabling false incident creation or alert fatigue rather than system compromise.

Out-of-bounds read in libheif 1.23.1 persists because the upstream patch for GHSA-73p7-m7gg-w2jv was incomplete, leaving the library still vulnerable in its latest release at time of disclosure. Any application or pipeline that uses libheif to parse HEIF/HEIC image files - including desktop viewers, photo management tools, and server-side media processors - is exposed when handling untrusted image input. The practical impact is at minimum information disclosure (heap memory leak) and potential application crash; no public exploit has been identified at time of analysis.

CVE-2026-84471 was reported by Ubuntu but carries no description, CVSS data, CWE classification, or reference links at time of analysis. The affected component, vulnerability class, and impact are entirely unknown. No meaningful synthesis is possible; this record requires enrichment from the Ubuntu Security Notices (USN) or NVD before any risk assessment can be made.

Cleartext credential exposure in MBS-Solutions X-Serie Gateway firmware V6_00_05 allows any authenticated user - including those with only the low-privileged Standard role - to retrieve OPC-UA server authentication credentials by querying the `opcua-configuration` method of the gateway's JSON API at `/cgi-bin/wwwugw.cgi`. The vulnerability stems from insufficient access control on a sensitive API response, meaning credential data is returned regardless of the requesting user's permission tier. A public researcher repository on GitHub (SilviaMun/vulnerability-research) documents the finding, lowering the exploitation threshold, though no active exploitation has been confirmed by CISA KEV.

Unauthenticated-equivalent version disclosure in MBS-Solutions X-Serie Gateway firmware V6_00_05 allows any authenticated user - including the low-privileged Standard role - to retrieve detailed system fingerprinting data via the ugw-deviceinfo method of /cgi-bin/wwwugw.cgi. The endpoint returns operatingsystem and gatewayversion fields without enforcing role-based access controls, exposing exact firmware and OS version strings that enable targeted follow-on attacks against known vulnerabilities. A proof-of-concept is publicly available on GitHub (SilviaMun/vulnerability-research); no CISA KEV listing is present.

Improper authorization in MBS-Solutions X-Serie Gateway firmware V6_00_05 permits authenticated Standard-role users to directly invoke undocumented CGI methods (ugw-ping, ugw-traceroute) via /cgi-bin/wwwugw.cgi that are intentionally hidden from the web UI. Exploitation leaks sensitive network topology data - hop paths, internal IP ranges, and reachability information - from a device positioned as a gateway, making the disclosure operationally significant. No public exploit code has been confirmed in a KEV context, though a public vulnerability research repository exists on GitHub.

Arbitrary file read in MBS-Solutions X-Serie Gateway firmware V6_00_05 allows any authenticated user holding only the low-privileged Standard role to retrieve arbitrary files from the device filesystem by manipulating the `file` query string parameter of `/cgi-bin/ugwdownload.cgi`. A public proof-of-concept exploit is available in SilviaMun's vulnerability-research repository on GitHub, significantly lowering the skill threshold for exploitation. No integrity or availability impact is established - this is a confidentiality-only vulnerability with high impact on device-resident sensitive data such as configuration files and credentials.

Out-of-bounds read in Samsung's rlottie animation library (not Escargot as the CVE metadata incorrectly states) exposes consumers of the library - including Samsung TV appliances - to information disclosure and potential parser crashes when processing specially crafted JPEG images. The root cause is the absence of fractional-ratio validation in stb_image.h's JPEG frame header processor: when h_max is not evenly divisible by a color component's sampling factor, the resampler accesses memory beyond the intended buffer boundary. No public exploit code has been identified at time of analysis, and the vulnerability is not listed in CISA KEV.

Hard-coded RSA private key exposure in the TP-Link Archer AX55 v4 web module allows a LAN-adjacent attacker who captures HTTP login traffic to decrypt the administrator password, since the shared private key is identical across all units of this model and the AES session key is additionally weakened. All Archer AX55 v4 firmware versions appear affected per the CPE wildcard, with a vendor patch now available via TP-Link's firmware portal. No public exploit code has been identified at time of analysis, though the cryptographic flaw is deterministic - once the static key is extracted from firmware, any captured login session can be decrypted offline.

Improper TLS certificate validation in IBM Netezza Software 11.3.0.3 through Interim Fix 002 (CWE-297) exposes encrypted database communications to interception via man-in-the-middle attacks. A network-adjacent or on-path attacker who can position themselves between Netezza clients and the server can intercept or manipulate traffic because the software fails to properly validate TLS certificates - likely failing to check hostname binding. No public exploit has been identified at time of analysis, and a vendor patch is available. EPSS data was not provided, but the network-accessible attack surface warrants prompt patching in any environment transmitting sensitive data.

Improper TLS certificate validation in IBM Netezza Software 11.3.0.3 through Interim Fix 002 leaves encrypted connections susceptible to man-in-the-middle interception, allowing an unauthenticated network adversary to obtain sensitive information in transit. The flaw is classified under CWE-295, meaning the software either skips certificate chain verification, hostname matching, or revocation checks - permitting a fraudulent certificate to be silently accepted. IBM has released a patch via its support portal; no public exploit code has been identified and this CVE does not appear in the CISA KEV catalog.

IBM Netezza Software 11.3.0.3 through Interim Fix 002 omits the AWS S3 `ExpectedBucketOwner` validation parameter on S3 API calls, leaving the application blind to bucket ownership. An unauthenticated remote attacker who registers an S3 bucket with a name matching or colliding with the target environment's configured bucket can intercept outbound data writes or inject crafted data into Netezza's S3-backed workflows. Both confidentiality and integrity are at risk; no patch version has been independently confirmed beyond the vendor advisory, and no public exploit or active exploitation has been observed.

Out-of-bounds memory read in Google Chrome's CrashReporting component (all versions prior to 152.0.7977.82) allows an attacker who has already compromised the renderer process to read memory beyond sandbox boundaries via a crafted HTML page, leaking limited cross-process memory contents. The exploitation chain is constrained by a hard prerequisite - renderer compromise must precede this step - placing the flaw in a post-exploitation context rather than as a standalone initial access vector. The vendor patch is available in stable channel 152.0.7977.82, and SSVC assessment confirms no known active exploitation at time of analysis.

Incorrect authorization in Kibana (CWE-863) allows a low-privileged authenticated user to access data or resources beyond their intended authorization level, resulting in high-impact confidentiality breach. Affected versions are addressed in Kibana 9.4.6 and 9.5.3 per Elastic advisory ESA-2026-175. No public exploit code or CISA KEV listing has been identified at time of analysis.

Cross-space agent data exposure in the Kibana Fleet feature allows authenticated low-privileged users to read agent metadata and diagnostic content outside their authorized Kibana space. An attacker holding read-level Fleet agent privileges in any one Kibana space can enumerate agents enrolled in other spaces - bypassing the space-based access boundary that Elastic uses for multi-tenancy isolation. No public exploit or active exploitation has been identified; CVSS 4.3 with PR:L aligns with the real-world impact: meaningful tenant boundary breach, but limited to read-only metadata disclosure.

Buffer overread in OpenVPN's Windows service component (`openvpnserv`) through version 2.7.6 exposes adjacent service process memory or crashes the service when NRPT domain entries containing Internationalized Domain Names (IDN) with UTF-8 encoding trigger an incorrect buffer size calculation (CWE-131). The flaw is Windows-specific and confined to split-DNS configurations that include non-ASCII domain names; Linux and macOS deployments are unaffected. The issue was discovered by BreachX Zero Day Labs and fixed in OpenVPN v2.7.7, co-released with four other security patches. No public exploit code or CISA KEV listing has been identified at time of analysis.

Out-of-bounds read in the BSON decoding component of the MongoDB PHP Driver (all versions per CPE cpe:2.3:a:mongodb:php_driver) allows an unauthenticated remote party to cause a small quantity of adjacent process memory to be copied into an error message that is returned to application code. The disclosure is limited in scope - only a few bytes of process memory are exposed, and they surface in application-level error messages rather than being sent directly in a network response - but may inadvertently reveal stack variables, pointers, or partial secrets depending on memory layout. No public exploit code has been identified at time of analysis.

Sensitive data exposure in the KP Agent Ready WordPress plugin (all versions before 1.2.08) causes the plugin to embed sensitive information - likely API keys or credentials for an external agent/chat service - in HTTP responses or frontend JavaScript assets delivered to site visitors. The CVSS 5.3 vector AV:N/AC:L/PR:N/UI:N confirms unauthenticated, low-complexity exploitation accessible to any visitor. No public exploit or active exploitation is identified at time of analysis; vendor-released patch version 1.2.08 is available.

Numeric truncation in the MongoDB C++ Driver's BSON library JSON parsing interface allows an attacker who controls text fed to that interface to read process memory beyond the input buffer, cause silent acceptance of a truncated document fragment as complete, or terminate the host process. Affected systems are any C++ applications embedding the driver that parse externally-controlled JSON; MongoDB server connectivity, credentials, and non-default configuration are explicitly not required. No public exploit has been identified at time of analysis, and the CVSS 4.0 score of 5.9 reflects both the constraint of requiring very large input documents and the local library-consumer trust boundary.

Heap out-of-bounds read in gfs2-utils enables memory disclosure and potential crashes when parsing crafted GFS2 filesystem images. The `ea_num_ptrs` field embedded in on-disk extended attribute metadata is consumed without validating it against the available buffer boundary, allowing an attacker who controls a filesystem image to trigger a heap over-read. Affected across Red Hat Enterprise Linux 7, 8, and 9; no public exploit is identified at time of analysis, and the local, user-interaction-dependent attack vector substantially limits practical exploitation.

Broken access control in WWBN AVideo's unauthenticated feed/index.php RSS endpoint allows any remote attacker to bypass per-video visibility enforcement by supplying a program_id parameter, exposing unlisted and group-restricted video metadata and content URLs. The flaw is particularly severe in that empty playlist IDs trigger return of the platform's entire hidden video catalogue, making targeted enumeration trivial. No public exploit code or KEV listing confirmed at time of analysis; the CVSS 4.0 score of 6.9 reflects the unauthenticated, low-complexity network vector tempered by a limited confidentiality impact.

Broken access control on the WWBN AVideo public channel page allows unauthenticated remote visitors to retrieve full URLs of unlisted videos and thumbnails of member-only content, bypassing the operator-configured hidePrivateVideos setting. The flaw originates from hardcoded visibility flags and an undefined property check in the channel endpoint's authorization logic, rendering the platform's content-restriction model ineffective. No public exploit code has been identified at time of analysis, and the vulnerability is not listed in the CISA KEV catalog.

OptimiDoc Server (On-Premise) exposes cleartext credentials for integrated external services - SMTP, FTP, Active Directory, and SharePoint - directly in the HTML page source of the web administration panel. Any authenticated administrator who views the configuration pages can read these stored passwords without any additional steps. Fixed in version 26.08 per CERT-PL advisory; no public exploit or KEV listing at time of analysis.

In the Linux kernel, the following vulnerability has been resolved: selinux: do not cancel a policy conversion that never started sel_write_load() calls selinux_policy_cancel() when sel_make_policy_nodes() fails, and that helper dereferences the outgoing policy to cancel its sidtab conversion. On the first policy load there is no outgoing policy: security_load_policy() returns early for that case, before it converts anything, and state->policy is still NULL. A first load that fails while building the selinuxfs tree therefore takes a NULL dereference in selinux_policy_cancel(), reached from a write(2) to /sys/fs/selinux/load. Skip the cancel when there is no old policy, mirroring the check security_load_policy() already makes before it converts.

In the Linux kernel, the following vulnerability has been resolved: clk: qcom: dispcc-eliza: Fix disp_cc_mdss_mdp_clk_src RCG stall on Eliza EVK Eliza EVK (eliza-cqs-evk.dts) does not have display enabled, however its Display Clock Controller is enabled and references parent clocks from DSI PHYs, which causes clock reparenting issues during probe (init) and warning on Eliza EVK: disp_cc_mdss_mdp_clk_src: rcg didn't update its configuration. WARNING: drivers/clk/qcom/clk-rcg2.c:136 at update_config+0xd4/0xe4, CPU#1: udevd/273 ... update_config (drivers/clk/qcom/clk-rcg2.c:136 (discriminator 2)) (P) clk_rcg2_shared_disable (drivers/clk/qcom/clk-rcg2.c:1471) clk_rcg2_shared_init (drivers/clk/qcom/clk-rcg2.c:1540) __clk_register (drivers/clk/clk.c:3959 drivers/clk/clk.c:4368) devm_clk_hw_register (drivers/clk/clk.c:4448 (discriminator 1) drivers/clk/clk.c:4672 (discriminator 1)) devm_clk_register_regmap (drivers/clk/qcom/clk-regmap.c:104) qcom_cc_really_probe (drivers/clk/qcom/common.c:418) qcom_cc_probe (drivers/clk/qcom/common.c:445) disp_cc_eliza_probe (dispcc-eliza.c:?) dispcc_eliza platform_probe (drivers/base/platform.c:1432)

In the Linux kernel, the following vulnerability has been resolved: af_packet: Don't send zero-byte data in tpacket_snd(). syzbot reported a WARNING in __dev_queue_xmit() triggered via tpacket_snd(): skb_assert_len WARNING: at include/linux/skbuff.h:2753 skb_assert_len WARNING: at __dev_queue_xmit+0x21bc/0x4970 net/core/dev.c:4781 Call Trace: <TASK> dev_queue_xmit include/linux/netdevice.h:3448 [inline] packet_xmit+0x243/0x310 net/packet/af_packet.c:276 tpacket_snd net/packet/af_packet.c:2907 [inline] packet_sendmsg+0x28d6/0x4eb0 net/packet/af_packet.c:3134 When sending 0-byte packets via TPACKET ring buffer on devices with no hard header (e.g. dev->hard_header_len == 0), tpacket_fill_skb() populates an skb with skb->len == 0 and returns 0. tpacket_snd() then forwards this empty skb to packet_xmit(), causing __dev_queue_xmit() to hit skb_assert_len(skb). Similar checks exist in packet_snd() via commit dc633700f00f ("net/af_packet: check len when min_header_len equals to 0") and in packet_sendmsg_spkt() via commit 6a341729fb31 ("af_packet: Don't send zero-byte data in packet_sendmsg_spkt()."). Return -EINVAL in tpacket_fill_skb() when skb->len is zero to reject zero-length packets in tpacket_snd().

In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: TC, Check if flow is PEER before acquiring devcom lock In case __mlx5e_add_fdb_flow() fails in lower levels, the flow is deleted via mlx5e_tc_del_flow(), and mlx5e_tc_del_flow() is acquiring ESW devcom lock without condition. In addition, in case of peer_flow, __mlx5e_add_fdb_flow() is called while holding ESW devcom comp lock. This results in an AA deadlock. To fix this, introduce a new PEER flag that is set on flows created as peer flows (the duplicate flows on peer devices), and check it in mlx5e_tc_del_flow() before acquiring ESW devcom lock. Lockdep splat: ============================================ WARNING: possible recursive locking detected ============================================ Possible unsafe locking scenario: CPU0 ---- lock(&comp->lock_key#2); lock(&comp->lock_key#2); *** DEADLOCK *** Call Trace: <TASK> dump_stack_lvl+0x69/0xa0 print_deadlock_bug.cold+0xbd/0xca __lock_acquire+0x1671/0x2ec0 lock_acquire+0x10e/0x2e0 down_read+0x95/0x430 mlx5_devcom_for_each_peer_begin+0x4e/0xe0 [mlx5_core] mlx5e_tc_del_flow+0x11d/0xa70 [mlx5_core] mlx5e_flow_put+0x99/0x100 [mlx5_core] __mlx5e_add_fdb_flow+0x409/0xf00 [mlx5_core] mlx5e_configure_flower+0x2a86/0x4100 [mlx5_core] mlx5e_rep_setup_tc_cls_flower+0x12f/0x1b0 [mlx5_core] mlx5e_rep_setup_tc_cb+0x153/0x750 [mlx5_core] tc_setup_cb_add+0x1dc/0x470 fl_change+0x2f4d/0x626d [cls_flower] tc_new_tfilter+0x79b/0x2310 rtnetlink_rcv_msg+0x778/0xad0 do_syscall_64+0x70/0x960 entry_SYSCALL_64_after_hwframe+0x4b/0x53 </TASK>

In the Linux kernel, the following vulnerability has been resolved: net: remove WARN_ON_ONCE() from sk_mc_loop() sk_mc_loop() can be called for sockets that are neither AF_INET nor AF_INET6 (e.g. AF_PACKET sockets when sending packets via raw/packet socket over virtual devices such as VRF or ipvlan). In such cases, sk_family is not AF_INET/AF_INET6 and sk_mc_loop() falls through the switch statement and triggers WARN_ON_ONCE(1). Non-INET sockets do not support IP_MULTICAST_LOOP or IPV6_MULTICAST_LOOP options, so loopback should default to true without generating a warning.

In the Linux kernel, the following vulnerability has been resolved: mm/huge_memory: initialise workingset state before folio split xas_try_split() adds __GFP_ACCOUNT for page-cache xa_nodes, but __folio_split() leaves the xa_state's xa_lru unset. That lets a live, memcg-charged xa_node exist without being linked into the mapping's shadow_nodes list_lru; when reclaim later walks the list_lru it trips VM_WARN_ON(!css_is_dying()). Use mapping_set_update() to install both the workingset update callback and the shadow_nodes list_lru on the xa_state.

In the Linux kernel, the following vulnerability has been resolved: Revert "drm/amdgpu: fix aperture mapping leak" devres teardown is LIFO. The aperture devres node was registered after the DRM device node, so devres_release_all() unmaps the aperture before the DRM device release callback fires amdgpu_device_fini_sw(). IP sw_fini callbacks (e.g. vcn_v4_0_sw_fini) write to fw_shared through a pointer derived from aper_base_kaddr, causing a kernel page fault on probe failure / rollback: BUG: unable to handle page fault ... PMD 0 RIP: vcn_v4_0_sw_fini+0x7b/0x170 [amdgpu] Call Trace: amdgpu_device_fini_sw amdgpu_driver_release_kms devm_drm_dev_init_release devres_release_all This reverts commit d871e99879cb5fd1fa798b006b4888887e63a17a. (cherry picked from commit 336e0cd576817ac64a4b394ca2b3680029f3e37f)

In the Linux kernel, the following vulnerability has been resolved: x86/mce: Set up the polling timer before CMCI discovery I hit the following on one of my machines: mce: CPU0 BANK15 CMCI inherited storm ------------[ cut here ]------------ ODEBUG: assert_init not available (active state 0) object: (____ptrval____) object type: timer_list hint: 0x0 WARNING: lib/debugobjects.c:632 at debug_object_assert_init+0x178/0x230, CPU#0: swapper/0/0 CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 7.2.0-rc5 #3 PREEMPTLAZY RIP: 0010:debug_object_assert_init+0x18f/0x230 Call Trace: <TASK> __mod_timer mce_timer_kick cmci_discover intel_init_cmci mce_intel_feature_init mcheck_cpu_init identify_cpu identify_boot_cpu arch_cpu_finalize_init start_kernel A second splat follows right after, from timer_setup() finding that same timer already queued: ODEBUG: init active (active state 0) object: (____ptrval____) object type: timer_list hint: stub_timer+0x0/0x10 This is happening because CMCI storm detection is trying to modify the timer before latter was properly set up. Set up the timer first. __mcheck_cpu_setup_timer() only calls timer_setup(), and depends on neither the generic nor the vendor init. [ bp: Massage commit message. ]

PowerProtect Data Manager versions 20.2.0.0 and earlier contain a CWE-188 (Reliance on Data/Memory Layout) flaw that enables unauthenticated remote attackers to launch phishing attacks against users of the platform. The CVSS vector (AV:N/AC:H/PR:N/UI:R) indicates the attack is network-reachable without credentials but requires high complexity and user interaction, consistent with an open-redirect or token/URL-manipulation mechanism that makes the product's trusted domain a vehicle for directing victims to attacker-controlled infrastructure. Dell has addressed this in advisory DSA-2026-368; no public exploit code or CISA KEV listing has been identified at time of analysis.

Server-Side Request Forgery in Dell PowerProtect Data Manager's REST API (versions 20.2.0.0 and below) allows high-privileged remote attackers to induce the server to issue unauthorized outbound HTTP requests to internal or adjacent network resources. The CVSS scope-change metric (S:C) signals that successful exploitation can reach infrastructure beyond the PowerProtect instance itself, enabling partial internal-network reconnaissance even from a single compromised admin session. No public exploit code exists and no active exploitation has been confirmed; Dell has issued multi-vulnerability advisory DSA-2026-368 addressing this flaw.

Heap out-of-bounds read in FreeRDP before 3.31.0 allows a malicious RDP server to trigger adjacent heap memory disclosure and potential client instability by sending a crafted RFX_AVC444_BITMAP_STREAM during AVC444 chroma reconstruction. The root cause is a missing row-index bounds check in `general_ChromaV1ToYUV444` (and its ARM NEON and x86 SSE4.1 counterparts), causing `memcpy` to read past the end of the allocated luma plane when the server specifies specific frame geometry. No public exploit or CISA KEV listing exists at time of analysis; a confirmed fix is available in the 3.31.0 release.

Path traversal during OCI container cleanup in Slurm's slurmstepd daemon allows files outside the designated container spool directory to be deleted on the host compute node. Affected clusters are those using Slurm's OCI container support; the bug manifests during job-step teardown, meaning any cluster user who can submit OCI-containerized jobs can trigger deletion of arbitrary files on the compute node. A secondary issue causes spool directories to be orphaned when ContainerPath includes a task ID pattern, resulting in disk resource leakage. No vendor CVSS score is published; exploitation conditions require a valid cluster account and OCI container feature enablement. No public exploit code has been identified at time of analysis.

CVE-2026-65165 describes unspecified issues in job step handling and node count tracking, reported via the Ubuntu vendor channel. The description '[Fix various issues around job steps and node count discrepancies]' reads as a commit message rather than a structured vulnerability disclosure, providing almost no actionable security detail. Without CVSS metrics, CWE classification, or references, the security impact - whether denial of service, privilege escalation, or incorrect resource allocation - cannot be determined from available data.

Multiple unsafe database operations and query-construction flaws in slurmdbd, the SLURM Workload Manager's accounting database daemon, allow authenticated cluster users or malicious slurmctld nodes to send crafted requests that result in unvalidated or improperly sanitized queries against the underlying database. The precise impact - whether SQL injection, privilege escalation within Slurm accounting, or data corruption - is not fully disclosed in available sources. No CVSS score, CWE classification, or KEV listing is present at time of analysis; the vulnerability is known only through an Ubuntu vendor disclosure.

Cleartext vault data in UpSignOn for Windows before 7.19.0 persists in process memory after the application locks, exposing all stored secrets to any local attacker with standard user privileges. Using the Windows PROCESS_VM_READ permission, an attacker can call ReadProcessMemory() against UpSignOn.exe and extract entry names, URLs, usernames, passwords, TOTP secrets, and notes in plaintext - defeating the lock screen's security guarantee. No public exploit code is identified at time of analysis and no CISA KEV listing exists, but the technique is well within the reach of any attacker with local access to the workstation.

Insecure credential storage in UpSignOn for Windows (before 7.19.0) exposes the biometric unlock key from the Windows PasswordVault API to any standard process running in the same user session, requiring no authentication prompt. An attacker with low-privilege local code execution can retrieve this key, decrypt the protected vault files on disk, and export the entire password manager contents in cleartext. No public exploit has been identified at time of analysis, and the vendor-released patch is available in version 7.19.0.

Sensitive key retention in UpSignOn for Windows before 7.19.0 allows a local attacker with low privileges to recover the master password and decrypt the entire password vault. The backup key used to protect an encrypted master password backup is retained in the memory of UpSignOn.exe even after the vault is re-locked, enabling an attacker who can read process memory to extract it, decrypt the master password backup stored in v6-vault1.DATA.txt, and subsequently export all stored credentials in cleartext. No public exploit has been identified at time of analysis, but the attack chain is mechanically straightforward once local access is established.

Sensitive token logging in Boruta Server before 0.10.0 allows any party with read access to business event logs - including log aggregation systems and the built-in administration log viewer - to recover live OAuth 2.0 and OpenID Connect credentials. Exposed values include access tokens, refresh tokens, authorization codes, agent tokens, direct-post codes, ID tokens, and VP tokens logged during normal authorization and token issuance flows. An attacker who recovers these credentials can impersonate users or clients on any resource server that trusts the stolen tokens until expiration or explicit revocation. No public exploit or active exploitation has been identified.

The webhook shared secret stored in Nexus Repository 3's capability configuration is returned unmasked via the capability read API, exposing a sensitive HMAC credential to any account holding the nexus:capabilities:read privilege. Affected versions span 3.2.0 through 3.95.x - a broad exposure window stretching back to an early release - with a confirmed fix in version 3.96.0 published by Sonatype. No public exploit or active exploitation has been identified, but a leaked webhook secret enables downstream abuse including forging authenticated webhook payloads or validating intercepted outbound events targeting CI/CD or pipeline endpoints.

Plaintext recovery from S/MIME-encrypted email is possible in Cisco Secure Email due to insufficient message integrity validation during decryption. An unauthenticated remote attacker positioned as a machine-in-the-middle between email gateways can intercept and manipulate ciphertext, exploiting the CWE-345 flaw to extract plaintext content from messages that senders believed were encrypted end-to-end. No public exploit code or CISA KEV listing has been identified at time of analysis, and the AC:H vector reflects the non-trivial MITM positioning requirement.

Plaintext recovery from S/MIME-encrypted email is possible in Cisco Secure Email due to insufficient validation of message integrity during decryption. An unauthenticated remote attacker who achieves a machine-in-the-middle position between email gateways can intercept and manipulate encrypted messages in transit, causing the decryption process to yield recoverable plaintext. No public exploit code or active exploitation has been identified at time of analysis, but confidentiality impact is rated High given complete plaintext disclosure.

Plaintext token storage in Jenkins Parameterized Remote Trigger Plugin 3.2.2 and earlier exposes authentication tokens to any Jenkins user holding Item/Extended Read permission or to anyone with direct access to the Jenkins controller filesystem. Tokens written to job config.xml files are readable without decryption, potentially allowing lower-privileged users to impersonate legitimate remote-trigger callers and invoke builds on downstream Jenkins instances. No public exploit has been identified; SSVC assessment confirms no active exploitation and a non-automatable attack path.

Configuration integrity compromise in Jenkins GitLab Plugin 1.9.16 and earlier enables authenticated low-privileged users to overwrite the global GitLab connection URL via Stapler data binding, redirecting GitLab API calls to attacker-controlled infrastructure. This causes Jenkins to transmit administrator-configured GitLab API tokens to the attacker's endpoint whenever a pipeline, webhook, or scheduled job triggers a GitLab API interaction. No KEV listing or public exploit has been identified at time of analysis, but the low privilege bar means any Jenkins account holder can abuse this on unpatched installations.

Improper use of the @DataBoundConstructor annotation in Jenkins Script Security Plugin versions ≤1412.v7737b_3405f86 enables low-privileged authenticated users to read the plugin's script approval configuration by submitting certain Jenkins forms. The flaw allows enumeration of which Groovy scripts, methods, and signatures have been approved for execution - information that could assist an attacker in mapping permitted scripted operations within the Jenkins environment. No active exploitation has been confirmed (not in CISA KEV) and no public exploit code has been identified at the time of analysis.

Observable response discrepancy in Kibana's Osquery feature enables cross-space scheduled query ID enumeration by authenticated low-privileged users. An attacker holding Osquery live-query privileges can determine whether a scheduled query identifier exists in a Kibana space they are not authorized to access by observing distinguishably different API responses. Vendor-released patch is version 9.4.4 per ESA-2026-161; no public exploit or CISA KEV listing is identified at time of analysis.

Incorrect Authorization (CWE-863) in Kibana's machine learning feature allows an authenticated low-privileged user to escalate their effective access beyond their assigned Kibana Space. A user holding ML job management privileges within a single Space can manipulate a job's saved object so it becomes accessible across all Spaces in the Kibana instance, bypassing the tenant-isolation boundary without holding rights to those additional Spaces. Vendor-released patches are available in versions 8.19.19, 9.3.8, and 9.4.4; no public exploit code or CISA KEV listing has been identified at time of analysis.

Path traversal in Elastic Maps Server exposes arbitrary files readable by the server process to unauthenticated network attackers. Insufficient path restriction in the content-directory serving logic allows crafted requests to escape the intended directory using traversal sequences, returning sensitive file contents. No KEV listing or public exploit code exists at time of analysis; Elastic has released fixed versions 8.19.19, 9.4.4, and 9.5.1 per advisory ESA-2026-148.

Missing authorization on a Kibana Entity Store configuration operation allows an authenticated user with elevated Kibana privileges to indirectly coerce a background task into reading Elasticsearch indices the user is not permitted to access directly. The vulnerability - tracked as ESA-2026-147, fixed in Kibana 9.4.5 - is a privilege abuse (CAPEC-122) rather than an authentication bypass: the attacker already holds high Kibana privileges but exploits the missing authz check to escalate their effective read access into restricted Elasticsearch index data. Derived entity records from those unauthorized indices are then surfaced through the Entity Store's output API, completing the information disclosure.

Improper input validation (CWE-20) in the Drupal Link Content Parser contributed module exposes sites to both confidentiality and integrity compromise under high-complexity, high-privilege conditions. All published versions of the module are affected per CPE cpe:2.3:a:drupal:link_content_parser:*:*:*:*:*:*:*:*, with Drupal's security team confirming the issue via advisory SA-contrib-2026-101. No public exploit has been identified at time of analysis, and the CVSS score of 5.9 reflects strong mitigating factors - specifically the requirement for administrator-level authentication and high attack complexity.

Drupal's Commerce CyberSource payment integration module (all versions prior to 1.10.0) contains a timing side-channel vulnerability (CWE-208) that enables brute-force attacks against authentication or token-validation operations. Remote unauthenticated attackers can exploit measurable differences in response timing to iteratively confirm the validity of credentials or secrets, achieving limited integrity impact. Vendor-released patch version 1.10.0 is available via the Drupal security advisory sa-contrib-2026-106; no public exploit code or CISA KEV listing has been identified at time of analysis.

Unauthenticated information disclosure in DXPR Builder, a Drupal page-building and AI editing module, exposes sensitive data through forceful browsing against insufficiently protected endpoints. All releases from 0.0.0 through 2.8.0 are affected; version 2.8.1 is the patched release per Drupal security advisory SA-CONTRIB-2026-112. No public exploit code has been identified at time of analysis, and the vulnerability is not listed in the CISA Known Exploited Vulnerabilities catalog.