Vulnerabilities

The WNC T-Mobile 5G Box IDU router contains an unauthenticated OS command injection flaw (CWE-78) in its /cgi-bin/portal.cgi web portal endpoint. The cli_cookie POST parameter is concatenated directly into a shell find command without sanitization, so a crafted POST request allows an attacker to append and execute arbitrary shell commands. Successful exploitation yields command execution as root on the underlying operating system, giving full control of the gateway and the traffic it handles. Per the CVSS 4.0 vector (AV:A), exploitation requires an attacker positioned on the network adjacent to the router, such as a device on its Wi-Fi or LAN, with no credentials or user interaction needed. All firmware prior to 1.1.0.651412 is affected; no public proof-of-concept, KEV listing, or confirmed in-the-wild exploitation is currently known.

Do: Upgrade the router to firmware version 1.1.0.651412 or later. Until updated, do not expose the management portal (/cgi-bin/portal.cgi) to the WAN and restrict LAN/Wi-Fi access to trusted devices. Check device logs for unexpected POST requests to /cgi-bin/portal.cgi containing a cli_cookie parameter, which may indicate exploitation attempts.

The WNC-manufactured T-Mobile 5G Box IDU router contains a command injection flaw (CWE-78) in the ping functionality of its /cgi-bin/portal.cgi web endpoint. The ping_ip, ping_size, and ping_times POST parameters are incorporated into a system command without verification or sanitization, allowing an attacker to append arbitrary shell commands. Because the CVSS vector requires adjacent-network access and high privileges, an attacker needs valid credentials on the router's portal interface, but once authenticated they can execute arbitrary commands and gain root access, fully compromising the gateway. All units running firmware before 1.1.0.651412 are affected, and a fixed firmware is available. No public proof-of-concept is known, the issue is not in CISA's KEV, and no in-the-wild exploitation has been confirmed.

Do: Upgrade the router to firmware 1.1.0.651412 or later via the admin portal or carrier-pushed updates, and verify the running version in the web interface. Because exploitation requires portal credentials, set a strong admin password, keep remote/WAN management of the portal disabled, and limit admin access to trusted LAN clients.

The Linux kernel's skb_zerocopy() helper destructively calls skb_tx_error() on the source socket buffer when skb_orphan_frags() fails, completing the source skb's zerocopy uarg and clearing the SKBFL_SHARED_FRAG page-ownership flag on a buffer the helper does not own. On the Open vSwitch OVS_ACTION_ATTR_USERSPACE path the skb is not freed after this error - do_execute_actions() ignores output_userspace()'s return value and keeps forwarding the same skb - so zerocopy buffers can be signaled as free while still in flight, and because SKBFL_SHARED_FRAG is cleared, esp_input() can decrypt in place over page fragments the skb does not privately own. A local attacker able to push traffic through an affected Open vSwitch datapath or an nfnetlink_queue (NFQUEUE) flow and trigger a frag-orphaning failure can cause use-after-free conditions and kernel memory/data corruption, with kernel-level confidentiality, integrity and availability impact (CVSS 9.3, local vector, scope changed). Any Linux system with the pre-fix kernel code is affected, with realistic trigger exposure on hosts running the Open vSwitch kernel datapath or NFQUEUE userspace queuing; the source data provides no specific vulnerable or fixed version numbers. No exploitation is known, no public proof-of-concept exists, and the issue is not listed in CISA KEV.

Do: Apply the stable fix ('net: skbuff: don't skb_tx_error() the source skb in skb_zerocopy()') as soon as your distribution or vendor ships an updated kernel, prioritizing hypervisors, SDN gateways and other hosts running the Open vSwitch kernel module or NFQUEUE/nfnetlink_queue rules (check with 'lsmod | grep openvswitch' and nftables/iptables NFQUEUE targets). Until patched, limit untrusted local code execution on OVS/NFQUEUE hosts and treat IPsec/ESP termination on those hosts as higher risk. No public PoC or in-the-wild exploitation is known, so monitor vendor advisories for fixed version numbers.

CVE-2026-90048 is a slab-out-of-bounds (heap) write in ni_create_attr_list() in the Linux kernel's NTFS3 filesystem driver: the attribute-list buffer is allocated at the fixed MFT record size, but a record packed with many minimal-size resident attributes generates an attribute list larger than that buffer, and the code advances its write cursor without any bounds check (the total size is only computed after the loop). It is triggered from a crafted, loop-mounted NTFS image - opening a file and adding an attribute (e.g., via setxattr) drives ntfs_set_ea() -> ni_insert_resident() -> ni_insert_attr() -> ni_ins_attr_ext() -> ni_create_attr_list(), with KASAN reporting a 4-byte write landing just past the end of a 1024-byte kmalloc-1k object. An attacker who can get a crafted image mounted gains kernel heap memory corruption, which typically enables local privilege escalation or a kernel crash (denial of service); despite the network-vector CVSS of 9.8, the practical trigger requires locally mounting untrusted NTFS media. Any Linux system with the NTFS3 driver enabled is affected, most notably desktops and multi-user servers where unprivileged users can mount removable drives or disk images. No public proof-of-concept, no CISA KEV listing, and no confirmed in-the-wild exploitation are known at this time.

Do: Update affected systems to a kernel that includes the upstream fs/ntfs3 fix that sizes the attribute-list buffer from the actual attributes (fixed-release version numbers were not available in the data - track your distro's kernel security updates). Until patched, avoid mounting untrusted NTFS images or removable media, restrict unprivileged loop mounting and use of setxattr on NTFS volumes, and blacklist/unload the ntfs3 module if NTFS support is not needed. Check your kernel config for CONFIG_NTFS3_FS/ntfs3 to determine exposure.

The Ceph filesystem client in the Linux kernel allocates message buffers with kvmalloc(), which can fall back to vmalloc() memory when fragmentation prevents a large contiguous allocation, but ceph_fname_to_usr() passed these raw MDS reply buffers to the fscrypt scatterlist crypto API, which only accepts linear-mapping addresses. When a readdir/metadata reply from the Ceph metadata server lands in a vmalloc() buffer on a CephFS mount with filename encryption enabled, the kernel hits an invalid address and oopses; the reporter's testing hit this on roughly 1 in 8,000 readdir messages, with crashes most likely on non-x86 architectures. An attacker who controls or can spoof the Ceph metadata server, or can intercept client-cluster traffic, can therefore trigger kernel crashes — a denial of service; despite the CNA's 9.8 network-vector score, the advisory describes oopses rather than demonstrated code execution or data theft. Only Linux systems using the kernel CephFS client with fs-encryption (encrypted filenames) are affected. No in-the-wild exploitation or public PoC is known, although the fix commit references a reproducer, and the fix routes vmalloc() addresses through a linear bounce buffer.

Do: Update Linux systems that mount CephFS with encryption to a kernel containing the 'ceph: properly decrypt filenames in vmalloc() buffers' commit (latest mainline/stable, or your vendor's backport once released). As an interim mitigation, disable filename encryption on CephFS mounts and restrict which hosts can reach or impersonate the Ceph monitors/MDS, since a malicious or on-path metadata server is required to trigger the flaw. Audit your fleet for CephFS mounts using fscrypt to confirm whether you are in the affected population.

CVE-2026-90038 is a use-after-free in the Linux kernel's NFS server (NFSD): nfsd4_revoke_export_states() drops the shared client_lock across revoke_one_stid() and a subsequent read of clp->cl_minorversion, and the stateid reference it holds does not pin the client, so a concurrent client teardown can free the client while it is still being dereferenced. The flaw is reached when an administrator removes an NFS export — exportfs -u drives the path via the NFSD_CMD_UNLOCK_EXPORT netlink command — and that revocation races with a client expiry. Successful triggering yields a kernel use-after-free that can crash the server (denial of service) and, as is typical for kernel UAF bugs, may be exploitable for privilege escalation; the assigned CVSS 3.1 score is 9.8 critical (AV:N/AC:L/PR:N), although practical triggering requires the export-revocation path to race client expiry. Any Linux system acting as an NFS server with the export-state revocation code is affected. No public proof-of-concept is known, the issue is not in CISA KEV, and no in-the-wild exploitation has been reported.

Do: Apply the upstream patch 'NFSD: Prevent client use-after-free during export state revocation' and update to a kernel that includes the fix. As an interim mitigation, avoid removing exports (exportfs -u / NFSD_CMD_UNLOCK_EXPORT) while NFSv4 clients are active or expiring, and schedule export changes during maintenance windows. Check whether your running kernel contains the nfsd4_revoke_export_states()/UNLOCK_EXPORT code to determine if the issue is relevant to your systems.

A use-after-free flaw in the Linux kernel's NFS server daemon (NFSD) occurs when an open owner left on the close_lru list after its final CLOSE keeps its last closed stateid holding only a raw, unpinned pointer to its nfs4_client. When the NFSD laundromat thread reaps a timed-out entry it drops the client lock and calls nfs4_put_stid(), which dereferences the client through cl_lock; a concurrent force_expire_client() can free the client in that window, so the server reads freed kernel memory, and __destroy_client() hits the same race by walking cl_openowners without holding cl_lock. An attacker acting as an NFS client that opens/closes files and triggers or coincides with client expiry could corrupt server kernel memory, most plausibly crashing the server (denial of service) and potentially more, per the critical CVSS score. Any Linux system running the in-kernel NFSv4 server (NFSD) — enterprise file servers, virtualization storage hosts, and Linux-based NAS appliances — is potentially affected. No public proof-of-concept or in-the-wild exploitation is currently known.

Do: Upgrade to a kernel that includes the NFSD fix (pinning the client via cl_rpc_users before dropping client_lock) — since no fixed version is given in the advisory, follow your distribution's kernel security tracker for the backported update. Until patched, restrict NFS access (TCP/UDP 2049 and related ports) to trusted client networks with firewall rules and tight export ACLs, and avoid unnecessary forced client-expiry operations on production servers. Monitor servers for NFSD crashes, hung NFS clients, or kernel use-after-free/oops messages involving nfs4_put_stid or the laundromat thread.

CVE-2026-90036 is a use-after-free in the Linux kernel's NFS server (NFSD) state management: a 'bare' lock owner whose only remaining reference is a blocked lock on the blocked_locks LRU holds a raw pointer to its nfs4_client without keeping the client alive. When the per-net laundromat reaps such a blocked lock, freeing the lock owner can make nfs4_put_stateowner() dereference the client's cl_lock, and because the laundromat detaches the lock first, a concurrent force_expire_client() can free the client before that call, touching freed memory. Triggering it requires NFS clients performing blocked-lock (NLM) operations while client expiry runs concurrently, which an attacker able to mount exports could attempt remotely. A successful exploit corrupts kernel memory in the NFS state machinery, with potential for denial of service and, per the CVSS 9.8 score, high confidentiality/integrity/availability impact. Any Linux system acting as an NFS server is potentially affected; no public proof-of-concept or in-the-wild exploitation is currently known.

Do: Apply the upstream NFSD fix via your distribution's kernel update as soon as vendors ship it. In the meantime, restrict NFS access (TCP/UDP 2049) to trusted clients with firewall rules, avoid unauthenticated or broad exports, and check whether the NFS server service is enabled and whether any clients rely on blocked (NLM) locks. Not currently listed in CISA KEV and no public exploit is known.

CVE-2026-90012 is an error-handling flaw in the Linux kernel's SPI (Serial Peripheral Interface) subsystem: when RX DMA mapping fails after TX mapping has succeeded, or TX mapping fails on a later transfer, __spi_map_msg() leaves stale mapping flags and stale/NULL cur_tx_dma_dev/cur_rx_dma_dev pointers, because those device pointers are only published after all transfers are mapped. The follow-up spi_unmap_msg() can then unmap the same TX mapping twice or call dma_unmap_sg_attrs() with a NULL or stale device — and since that function dereferences the device before checking the SG entry count, a NULL device triggers a kernel oops (crash). An attacker who can cause DMA mapping failures on an SPI controller with DMA gains at minimum denial of service, and the incorrect release of DMA mappings carries potential memory-safety implications consistent with the reported critical CVSS (9.8), although the network vector depends on driver-specific conditions. Affected are any systems running Linux kernels with SPI controllers that use DMA, a configuration typical of embedded and ARM-based devices. No public proof-of-concept exists, the flaw is not in CISA KEV, and no exploitation is currently known.

Do: Patch by pulling the upstream commit 'spi: Fix DMA mapping ownership on partial map failure' into your kernel or take the corresponding update from your kernel/board vendor's stable or LTS stream once published (no specific fixed version numbers are available in the source data), prioritizing ARM/embedded products whose kernels enable SPI controllers with DMA. No workaround is documented; if you cannot patch immediately, avoid workloads that stress SPI DMA under memory pressure and investigate any kernel oopses surfacing in dma_unmap_sg_attrs() during SPI transfers. Since no exploitation is known, systems not using SPI can patch at normal cadence.

The Linux kernel's iSCSI target implementation (LIO, drivers/target/iscsi) allocates the login request buffer at exactly MAX_KEY_VALUE_PAIRS (8192) bytes, and its length check uses '>' instead of '>=', so a login PDU payload of 8189-8192 bytes (plus padding) fills the entire buffer with no byte left for a NUL terminator. The buffer is subsequently parsed as a C string by functions such as strstr(), kstrdup() and strlen_semi() in the CHAP authentication path, and convert_null_to_semi() rewrites embedded NULs to semicolons, so parsing walks past the end of the object into adjacent slab memory (out-of-bounds read). An unauthenticated initiator can trigger it by sending a crafted login request to a portal configured for CHAP authentication; portals that do not require authentication rewrite AuthMethod to None and never enter the CHAP path. Per the CVSS score of 9.1, an attacker gains information disclosure (C:H) and denial of service (A:H), with no integrity impact. No public proof-of-concept or in-the-wild exploitation is known; the fix allocates one extra zeroed byte so the buffer is always terminated.

Do: Apply a kernel update containing this SCSI target (iscsi_target) fix as soon as it reaches your vendor/distro kernel; no fixed version number is given in the source data, so check your vendor's advisory for the backport. Until patched, restrict TCP port 3260 on iSCSI portals to trusted initiator networks with firewall/ACL rules, and note that portals without mandatory CHAP (AuthMethod None) are not reachable through the vulnerable code path. Check whether any Linux hosts run targetcli/LIO with CHAP configured and whether those portals are exposed beyond the storage network.

CVE-2026-89990 is a use-after-free in the Linux kernel's Ceph filesystem (CephFS) client: ceph_mds_check_access() walks the mdsc->s_cap_auths array without holding mdsc->mutex, while MDS session OPEN handling can replace that array and free the old array and its strings under the same mutex. The flaw is triggered when an MDS session is reopened concurrently with a process opening files on a CephFS mount; the fix commit's crash trace shows a php-cgi process faulting in ceph_atomic_open via path_openat after the array was freed beneath it. The demonstrated impact is a kernel oops (denial of service), and as a kernel-space use-after-free it may be exploitable further, consistent with the critical 9.8 CVSS score. Any Linux host mounting CephFS with a kernel containing the vulnerable access-check code is affected. No public proof-of-concept or confirmed malicious exploitation is known and the flaw is not in CISA KEV; it is fixed by a mainline kernel commit pending vendor backports.

Do: Patch kernels on hosts that mount CephFS (verify with 'mount -t ceph') as soon as a fixed mainline kernel or vendor backport is available, prioritizing multi-user systems such as web servers running php-cgi where local processes can race session reopens. Until patched, restrict untrusted local access to CephFS-mounted hosts or unmount CephFS, and be aware that MDS failover/session-reopen events can trigger the race.

The Linux kernel NVMe driver frees the namespace structure in the nvme_alloc_ns() error path (out_unlink_ns) after removing it from the head's siblings list with list_del_rcu(), but without first waiting for SRCU readers to finish. Because the NVMe multipath code iterates head->list under srcu_read_lock() in nvme_find_path() and nvme_mpath_revalidate_paths(), a concurrent path lookup can still hold a pointer to the namespace when kfree(ns) runs, producing a use-after-free. The flaw is triggered when a namespace allocation or unlink error occurs while multipath readers are concurrently scanning paths, i.e., on systems using NVMe multipath such as dual-path local NVMe or NVMe-over-Fabrics. A successful race could yield kernel memory corruption leading to denial of service, and potentially privilege escalation in a best-case exploit. No public proof-of-concept, KEV listing, or in-the-wild exploitation is known, and triggering depends on local error conditions, so practical remote exploitation is unlikely despite the network-attack-vector CVSS score.

Do: Update affected systems to a kernel that includes the upstream fix commit 'nvme: add missing SRCU grace period in error path' as soon as your distribution ships it, prioritizing hosts that use NVMe multipath (dual-controller NVMe SSDs, NVMe-oF with multiple paths). Check dmesg/journal for recurring NVMe namespace scan or unlink errors, which indicate the vulnerable error path can be reached. Given exploitation requires a local race with a namespace allocation failure, treat this as a stability and hardening fix rather than an urgent remote-threat patch.

The Linux kernel's NVMe over Fabrics target authentication code (nvmet-auth) contains a use-after-free race: nvmet_auth_sq_free() cancels the authentication expiration delayed work with cancel_delayed_work(), which does not wait if the callback has already started executing. If an attacker triggers authentication expiration timing that overlaps with queue teardown, the transport layer can free or reuse the queue containing struct nvmet_sq while nvmet_auth_expired_work() is still accessing it, corrupting target-side kernel memory. A remote NVMe host that can reach the target and negotiate in-band authentication (e.g., by disconnecting at the right moment during the auth timeout window) could potentially crash the target or, per the assigned CVSS 9.8 rating, achieve high confidentiality, integrity, and availability impact through memory corruption. Only systems running the Linux kernel as an NVMe-oF target (nvmet subsystem) with in-band authentication support and authentication configured are affected. No public proof-of-concept, CISA KEV listing, or confirmed in-the-wild exploitation is known.

Do: Update the kernel to a release containing the nvmet-auth synchronous teardown fix (check your distribution's security advisory for the backport of CVE-2026-89970). Until patched, disable in-band authentication (DH-HMAC-CHAP) on nvmet targets or restrict NVMe/TCP traffic (port 4420) to trusted storage networks with host and network ACLs. Verify whether your hosts run the in-kernel nvmet target with authentication enabled, and monitor for unexpected host disconnects coinciding with authentication timeouts.

The Linux kernel's NVMe/TCP target transport (nvmet-tcp) reads incoming PDU headers into a fixed 128-byte buffer without validating the declared PDU length, allowing a 4-byte out-of-bounds write. A remote, unauthenticated host that connects to an NVMe/TCP target and negotiates header digests can send a duplicate ICReq PDU, causing 124 attacker-controlled bytes to be written at offset 8 of the 128-byte union and spilling 4 bytes over its end into adjacent kernel memory (queue->hdr_digest and queue->data_digest); the duplicate ICReq is only rejected after the overflow has occurred. This corrupts kernel memory adjacent to the receive buffer, matching the critical CVSS 9.8 rating (network vector, no privileges, high C/I/A impact), though no public proof-of-concept is known and the flaw is not listed in CISA KEV. Only systems running a Linux kernel with the nvmet-tcp target enabled and reachable over the network are affected. The upstream fix rejects any PDU whose declared length would read past the end of the receive buffer before performing the second read.

Do: Update the kernel to a release or distro package containing the upstream nvmet-tcp fix (the commit that rejects PDUs whose declared length exceeds sizeof(queue->pdu)) and rebuild/reboot affected storage nodes. Until patched, firewall TCP port 4420 so only trusted NVMe initiators can reach the target, since the attack requires no authentication and only needs the ability to open a connection and send a crafted duplicate ICReq. Check whether your kernels enable the NVMe target TCP transport (CONFIG_NVME_TARGET_TCP, e.g. via nvmetcli or /sys/kernel/config/nvmet) to determine if you are exposed at all.

CVE-2026-89930 is a missing TLB flush in the Linux kernel's KVM hypervisor, specifically in the nVMX code that implements Intel nested virtualization. When a guest hypervisor (L1) attempts to launch a nested guest (L2) and the VM-Entry fails (e.g., due to failed VMCS checks or an MSR load list that architecturally requires a TLB flush), KVM skips servicing queued local TLB flushes while still updating its record of the last VPID used by L2, so a subsequent successful VM-Entry misses the required flush. A malicious guest can trigger this by changing L2's VPID, forcing a failed VM-Entry followed by a successful one, causing stale TLB translations to be reused, which can break guest isolation with high confidentiality, integrity, and availability impact (CVSS 9.3, scope changed). Only hosts running Linux with KVM and nested virtualization enabled, where tenants can run their own VMs inside a guest, are practically affected. No public proof-of-concept or in-the-wild exploitation is known, and the flaw is not in CISA's KEV catalog.

Do: Upgrade to a Linux kernel that includes the upstream nVMX fix ('KVM: nVMX: Service local TLB flushes on failed nested VM-Enter') as delivered in stable-series kernel updates. Until patched, disable nested virtualization for KVM (e.g., set nested=0 for the kvm_intel module) or restrict which tenants may run nested VMs; check current state at /sys/module/kvm_intel/parameters/nested. With no public exploit or KEV listing, prioritize patching multi-tenant virtualization hosts where guests are semi-trusted.

The KVM hypervisor code in the Linux kernel for ARM64 computes TLB invalidation ranges by comparing an address against (base + size), and this arithmetic wraps around to zero when the range covers the very last page or block of the TTBR1 virtual address space, so the comparison fails and the TLB entry is never invalidated. A local attacker, typically code running inside a KVM guest, can trigger unmapping and invalidation at the top of the address space so that stale TLB entries survive, leaving memory that was unmapped (and may be reused by the host or another VM) reachable, which is a confidentiality, integrity and availability issue across security boundaries and earns the 9.3 critical CVSS score with scope change. Only ARM64 Linux kernels running KVM virtualization are affected; x86 KVM and ARM64 systems without KVM are not. There is no public proof-of-concept, the issue is not listed in CISA's KEV catalog, and no in-the-wild exploitation is currently known.

Do: Patch ARM64 KVM hosts with kernel updates that include the 'Correctly handle end of VA space TLBI invalidation' fix as soon as vendor or stable-tree releases ship it, and because no fixed version number is given in the data, match by patch commit or kernel changelog rather than version. Until patched, limit untrusted or multi-tenant guest workloads on ARM64 KVM hosts and monitor vendor advisories for backported fixes.

A race condition in the Linux kernel's KVM hypervisor for arm64 lets one virtual CPU install a TLB entry for a page that has just been invalidated by another vCPU, because VNCR (nested-virtualization) invalidation did not participate in the MMU invalidation retry/sequencing mechanism. It is triggered when one vCPU walks the stage-1 page tables to translate a VNCR access while a second vCPU concurrently replaces that mapping with an invalid entry and issues a TLBI S1E2, allowing the first vCPU to cache a now-stale mapping. An attacker able to run or influence nested virtualization workloads on an affected arm64 host could retain and use stale mappings to freed or reassigned memory, with critical confidentiality, integrity, and availability impact across VMs (CVSS scope changed). Affected users are operators of arm64 Linux hosts running kernels with KVM and nested-virtualization (NV/VNCR) support, such as Ampere Altra, AWS Graviton, or similar ARM server/cloud deployments running nested guests. No public proof-of-concept or in-the-wild exploitation is known; the flaw has been fixed by an upstream kernel commit.

Do: Update arm64 KVM hosts to a kernel that includes the upstream KVM/arm64 fix as it propagates to the stable branches; until patched, avoid running nested (NV/VNCR) guests or restrict /dev/kvm access to trusted users only. Check whether your kernel enables KVM arm64 nested virtualization, as the flaw is only reachable through the VNCR/nested-guest code path.

CVE-2026-89915 is a correctness flaw in the Linux kernel's KVM implementation for arm64 nested virtualization: a VM-wide counter tracking whether a guest (L1) hypervisor's VNCR page is mapped in the host (L0) is unreliable, causing the host to skip required TLB invalidations and leave stale translations in place. It is triggered by ordinary nested-virtualization activity, most commonly an L1 vCPU invalidating its own TLBs at a point where the VNCR page is not actually mapped in L0, so the counter-based check misses needed invalidations of the VNCR 'pseudo-TLB'. A malicious local guest could potentially exploit stale mappings to read or corrupt memory beyond its intended scope or to destabilize VMs, consistent with the CVSS scoring of high confidentiality, integrity and availability impact with a changed security scope. Only arm64 Linux hosts running KVM with nested virtualization (VNCR/NV2) on supporting hardware are affected; hosts that never run nested guests are not exposed to this code path. No public proof-of-concept or in-the-wild exploitation is known, and the fix, which removes the flawed counter entirely, has been merged in the mainline kernel.

Do: Update affected arm64 hosts to a kernel that includes the upstream fix (removal of the VM-wide VNCR mapping counter) or to your vendor's patched kernel when it becomes available. Until then, avoid enabling nested virtualization for guests on arm64 KVM hosts and audit whether any L1 guests run their own VMs. Restrict untrusted tenants on multi-tenant arm64 virtualization hosts as a precaution.

A missing sign-extension of the virtual address in the arm64 KVM range-based TLB invalidation helper (decode_range_tlbi()) causes the Linux kernel hypervisor to compute incorrect invalidation ranges for Stage-1 TLBI operations on 64-bit ARM hosts. The flaw is triggered when a guest issues range-based TLB invalidation instructions that are decoded by the host kernel, leaving stale TLB entries that should have been flushed; the fix also notes PA-bit overflow must be avoided for Stage-2 invalidation. An attacker can potentially read or modify memory that should have been unmapped, breaking isolation between the host and guests, consistent with the scope-changed critical CVSS rating (high confidentiality, integrity and availability impact). Affected users are operators of Linux kernels with the arm64 KVM range-TLBI code, chiefly ARM server, cloud and virtualization hosts running untrusted local workloads. No public proof-of-concept is known, the issue is not in CISA KEV, and there are no reports of exploitation in the wild.

Do: Update affected arm64 hosts to a kernel that includes the KVM arm64 sign-extension fix for range-based TLBI (track stable-kernel and your distribution's security updates, as no fixed version number is given in this advisory). Until patched, avoid running untrusted local workloads or guests on arm64 KVM hosts and verify with your vendor whether your running kernel contains the fix. Because no PoC or in-the-wild exploitation is known, a routine patching cadence is sufficient for most deployments.

The Linux kernel's qla2xxx driver (for Marvell/QLogic Fibre Channel HBAs) has a locking race: the NVMe LS reject helper submits commands to the hardware request ring without holding the qpair/hardware lock that its underlying allocation and doorbell routines assume is held. Two call paths — the NVMe-FC .xmt_ls_rsp transport callback error path and the purex/PURLS unsolicited-LS packet handler — invoke it unlocked and use the base qpair, so they can run concurrently with normal I/O submission and corrupt the ring producer state. The result is duplicated or dropped commands, which an attacker who can inject NVMe-FC traffic toward the host could leverage for data integrity issues, I/O failures, or host instability/crash (denial of service). Affected systems are Linux hosts using qla2xxx-driven QLogic FC adapters with NVMe-FC features in play; the published CVSS 3.1 base score is 9.8 (critical). No exploitation in the wild, CISA KEV listing, or public proof-of-concept is currently known.

Do: Update affected systems to kernels that include the upstream fix commit 'scsi: qla2xxx: Hold qpair lock when sending NVMe LS reject' (or vendor kernel updates incorporating it). Identify hosts running the qla2xxx driver with NVMe-FC configured, and restrict SAN fabric access via zoning/ACLs to limit who can send unsolicited NVMe LS traffic to them. Watch for symptoms such as dropped or duplicated FC/NVMe commands or ring producer corruption while awaiting the update.

The qla2xxx SCSI driver in the Linux kernel (used for QLogic/Marvell Fibre Channel host bus adapters) contains a double-completion bug that leads to a use-after-free. When an async IOCB times out, qla2x00_async_iocb_timeout() tries to abort it; if the abort fails, both the SRB_LOGIN_CMD and SRB_CTRL_VP/default paths call sp->done() unconditionally without first confirming the command was actually found and removed from outstanding_cmds[]. If the response ISR completes the same handle concurrently, the submitter (e.g., qla24xx_control_vp()) wakes, clears sp->comp and reclaims its on-stack completion, so the timeout handler's second sp->done() call can invoke complete() on a freed stack frame. An attacker who can trigger IOCB timeouts on a system with an affected HBA gains kernel memory corruption, with denial of service and potentially privilege escalation; the flaw is scored 9.8 (critical) by the kernel.org CNA, though practical triggering requires these timeout race conditions on hosts using the qla2xxx driver. No public PoC or known exploitation exists.

Do: Patch by updating to a kernel that includes the qla2xxx fix (track the commit through kernel.org stable trees and your distro's security updates; no fixed version number is published in the available data). Inventory hosts for qla2xxx (e.g., loaded module or QLogic FC adapters via lspci) and note whether NPIV/virtual ports are in use, as those configurations exercise the affected path. No practical mitigation exists beyond patching; the flaw is not remotely reachable over IP networks despite the AV:N CVSS vector.

An unsigned-integer underflow in the qla2xxx SCSI driver (the in-kernel driver for Marvell/QLogic Fibre Channel HBAs) enables an out-of-bounds read in qla2x00_status_entry(). A hostile or buggy Fibre Channel target reports an rsp_info_len larger than the 28-byte (24xx) or 60-byte (29xx) IOCB sense-data area; the par_sense_len subtraction underflows to a huge value, defeats the length cap in qla2x00_handle_sense(), and a memcpy copies up to SCSI_SENSE_BUFFERSIZE bytes from beyond the response ring/heap into the command's sense buffer. An attacker who controls a storage target (LUN) on the same FC fabric gains disclosure of adjacent kernel memory returned as sense data, with availability impact also flagged in the CVSS vector; practical exploitation requires a malicious or compromised target on the fabric rather than generic network access. Any Linux server using qla2xxx-based QLogic/Marvell FC HBAs is affected. No public PoC, CISA KEV listing, or confirmed in-the-wild exploitation is known.

Do: Update to a kernel containing the upstream qla2x00_status_entry() rsp_info_len bounds fix as soon as your distribution backports it (no fixed version number is available in this data). Until patched, restrict Fibre Channel fabric membership to trusted arrays, remove unauthorized or unknown targets, and segment fabrics so untrusted devices cannot present LUNs to qla2xxx hosts. Note the practical attack path is a hostile FC target on the fabric, not remote exploitation over IP.

Arista EOS contains a flaw (CWE-94) that lets an unauthenticated P4Runtime client achieve arbitrary code execution on switches configured with P4Runtime under certain conditions. It is triggered by sending a specially crafted packet during the initiation of a P4Runtime session, with no credentials or user interaction required. A successful attacker obtains complete administrative control over the compromised switch. Only deployments where P4Runtime is enabled are exposed; the feature is disabled by default in Arista EOS. The issue was found internally by Arista, and no public proof-of-concept or malicious exploitation in customer networks is known.

Do: Upgrade to the fixed EOS release when Arista publishes it in the official advisory (fixed versions are not stated in the available data). If P4Runtime is not required, keep it disabled or disable it until patched; where it is required, restrict access to the P4Runtime service using control-plane and management-interface ACLs to trusted controllers only. Review switch configs for 'p4runtime' enablement and monitor Arista's advisory for updates.

CVE-2026-89788 is a use-after-free vulnerability in the Linux kernel's ksmbd in-kernel SMB2/SMB3 server, in the smb2_tree_connect() handler. A newly created tree connection is published into the session's connection table with a single reference before it is fully initialized, so a concurrent session logoff can erase the entry and free the object while the connect handler is still using it; a remote client can trigger the race by sending a TREE_CONNECT request and a session LOGOFF close together. Successful triggering causes kernel memory corruption that can crash the server (denial of service) and may lead to arbitrary code execution with kernel privileges, consistent with the 9.8 CVSS score covering confidentiality, integrity and availability. Only Linux systems running the ksmbd module (CONFIG_SMB_SERVER) and exposing that service to untrusted clients are affected; Samba and Windows SMB servers are not. No public proof-of-concept, CISA KEV listing, or known in-the-wild exploitation is reported.

Do: Apply a kernel update from your distribution containing the ksmbd tree-connection reference-count fix as soon as it is available; the source data does not name a fixed kernel version, so track your vendor's kernel security advisories for this CVE. Until patched, avoid using ksmbd (unload the ksmbd module or disable shares served by it) and restrict TCP port 445 to trusted networks with firewall rules if the server must remain in use.

CVE-2026-89786 is a slab out-of-bounds read in the Linux kernel's ext4 filesystem, in ext4_read_inline_dir(), which handles directories whose contents are stored inline in the inode (the inline_data feature). The iteration code accepts a directory position whose minimum dirent header would extend past the end of the exactly-sized inline buffer, and dereferences de->rec_len (via the rescan probe and __ext4_check_dir_entry) before the entry is rejected, because the length check is passed the larger extra_size instead of the physical inline_size. Triggering it requires listing such a directory via getdents64(); the flaw yields kernel memory disclosure and potential kernel crash/denial of service (CVSS rates confidentiality high, availability high, integrity none), and although it is scored AV:N, the described trigger is the directory-read path, so an attacker needs the ability to read a crafted or corrupted inline directory (e.g. local access or a supplied filesystem image). Any Linux system running a kernel with ext4 inline-data directory support is potentially affected, with practical exposure concentrated on systems where the ext4 inline_data feature is actually in use. No exploitation in the wild, public proof-of-concept, or CISA KEV listing is known.

Do: Deploy kernels containing this upstream ext4 fix as soon as your distribution ships it (no fixed release version is given in the source data). Audit ext4 volumes for the inline_data feature (dumpe2fs -h <device> | grep inline_data) and, where it is not required, plan to clear it (tune2fs -O ^inline_data after confirming no inline data is in use). Until patched, avoid mounting untrusted ext4 images and restrict untrusted local users on systems using inline_data, since triggering requires listing a crafted inline directory.

CVE-2026-89783 is an off-by-one bounds-check flaw in the Linux kernel's IPv6 IPsec input path: xfrm6_input_addr() tests '1 + sp->len == XFRM_MAX_DEPTH' instead of 'sp->len >= XFRM_MAX_DEPTH', so a secpath already holding the maximum of 6 transform states passes the check and 'sp->xvec[sp->len++]' writes one pointer past the 6-element xvec[] array. It is reached when a packet traverses a full 6-level XFRM chain and, in transport mode, is re-injected into IPv6 input via xfrm_trans_reinject(); if the inner packet carries a Home Address Option (destination options) or a type-2 routing header, xfrm6_input_addr() runs again with sp->len == 6 and writes one slot out of bounds. The stray write stays within the same sec_path allocation, so KASAN does not see it, but UBSAN_BOUNDS flags it ('index 6 is out of range for type xfrm_state *[6]' at net/ipv6/xfrm6_input.c:309) and the kernel panics under panic_on_warn; the assigned CVSS 3.1 score is 9.8 (critical) with high confidentiality, integrity and availability impact. Affected are Linux systems running IPv6 with kernel XFRM/IPsec in transport mode, typically VPN gateways and IPsec peers with nested transform chains; hosts without IPv6 IPsec transport mode are not reachable. No public proof-of-concept, CISA KEV listing, or known in-the-wild exploitation exists at this time.

Do: Update kernels when the fix (replacing the depth check with 'sp->len >= XFRM_MAX_DEPTH', matching xfrm_input()) reaches your distribution or LTS branch. Interim mitigations: keep IPv6 transport-mode XFRM chains below the 6-state maximum where possible and filter inbound IPv6 destination-options Home Address Option and type-2 Routing headers at the perimeter. Audit hosts with 'ip xfrm state'/'ip xfrm policy' to confirm whether IPv6 transport-mode IPsec is in use, and prioritize internet-facing VPN gateways.

The Linux kernel's ntfs3 filesystem driver fails to verify that an NTFS extended-attribute (EA) record's ef->size field is large enough to hold the record's own name and value, so a crafted image can pass validation in ntfs_read_ea() with a declared size of, e.g., 24 bytes while embedding a length (elength) of 0xffff. When getxattr() is later called on a file on that mounted image, ntfs_get_ea() trusts the bogus elength and copies up to 64 KB out of the undersized kmalloc'd buffer, producing a slab out-of-bounds read (confirmed by the KASAN report) that leaks adjacent kernel heap memory to userspace. An attacker who can get a malicious NTFS image or device mounted, for example via a USB drive auto-mounted on a desktop or a service that processes untrusted disk images, can disclose kernel heap contents, and the CVSS 9.1 rating (C:H/A:H) also reflects potential denial of service. Any Linux system running a kernel with the ntfs3 driver (CONFIG_NTFS3) enabled that mounts untrusted NTFS filesystems is affected. No public proof-of-concept is known, there is no reported in-the-wild exploitation, and the issue is not in CISA's KEV catalog.

Do: Update the kernel via your distribution's security channel as fixes ship (the patch makes ntfs_get_ea()/ntfs_read_ea() require ef->size to cover the record's name and value); fixed version numbers were not provided in the advisory. Until patched, avoid mounting untrusted NTFS images or USB devices with the in-kernel ntfs3 driver (prefer the FUSE-based ntfs-3g) and restrict mount privileges to trusted users. Check whether CONFIG_NTFS3 is enabled or the ntfs3 module is loaded on your systems to gauge exposure.

The Linux kernel's isofs zisofs decompressor mishandles empty compression blocks: a crafted "ZF" Rock Ridge record inside an ISO9660 image can set the compression block size below the kernel page size, and an ordinary read() of such a compressed file then drives zisofs_read_folio() one entry past the end of the allocated page-pointer array (KASAN reports a slab-out-of-bounds 8-byte read immediately past an 8-byte kmalloc-8 allocation, i.e. a single-entry array). An attacker triggers this by supplying a specially crafted ISO image that a user or automated service mounts and then reads; the page-aligned case (poffset == 0) is unaffected. An attacker gains kernel out-of-bounds memory access, potentially yielding information disclosure or a kernel crash, and the assigned CVSS 3.1 score is 9.8 critical, though the practical trigger requires mounting an attacker-controlled image rather than a purely remote path. Any Linux system that mounts untrusted ISO9660 images with ISO9660/zisofs support enabled is affected, including desktops handling removable media, CI/build and VM services that mount ISOs, and file managers with auto-mount. No public proof-of-concept or confirmed in-the-wild exploitation is known; the flaw is fixed by the upstream commit "isofs: fix out-of-bounds page array access on empty zisofs block," and no affected/fixed version ranges are specified in the available data.

Do: Update the kernel to a release that includes the upstream fix "isofs: fix out-of-bounds page array access on empty zisofs block" once it reaches your distribution's stable channel; no fixed version numbers are available in the current data, so track your vendor's advisory. Until patched, avoid mounting ISO images from untrusted sources and restrict or disable automatic mounting of removable media and ISO files by unprivileged users. Verify whether your kernel is built with CONFIG_ISO9660_FS/CONFIG_ZISOFS; images using page-aligned blocks (poffset == 0) are unaffected.

CVE-2026-89775 is a flaw in the Linux kernel's KVM implementation for arm64, where the helper pgshift_level_to_ttl() mishandles negative walk levels when computing the size covered by a stage-1 TLB invalidation on the VNCR (nested virtualization) path. When a guest's stage-1 MMU is off, the level is encoded as the special value -127 (S1_MMU_DISABLED), but this is cast to a u8 and truncated to its bottom two bits, producing an invalidation size of 0 so stale TLB entries survive an operation that should have removed them. On a hypervisor, stale translations can allow memory mappings to outlive the pages they refer to, potentially letting a local attacker or guest read or corrupt memory across the trust boundary, consistent with the critical 9.3 CVSS (local attack, scope change, high confidentiality/integrity/availability impact). Only arm64 Linux systems running KVM with the nested-virtualization (VNCR/FEAT_NV2) code paths are affected; the advisory does not specify concrete affected or fixed version numbers. No public proof-of-concept, CISA KEV listing, or known exploitation has been reported.

Do: Install a kernel update containing the upstream fix "KVM: arm64: Handle negative S1 walk levels in VNCR TLB size evaluation" from your vendor's stable tree once available. As an interim mitigation, do not enable nested virtualization (FEAT_NV2/NV2) for KVM guests on arm64 hosts. If you operate KVM guests on arm64, confirm whether your running kernel includes the fix by checking the package changelog or git history for this commit.

Unbound, NLnet Labs' widely used validating recursive DNS resolver, contains a buffer overflow (CWE-122) in the DNSSEC validator's DNSKEY digesting routine. A crafted DNSKEY record whose owner name uses a compression pointer back into its own RDATA overflows the digest buffer while the resolver is validating the zone. An attacker who controls a malicious authoritative zone and can cause a vulnerable Unbound resolver to query it can crash the service (denial of service) and, using attacker-controlled data, potentially achieve remote code execution on the resolver host. All Unbound deployments up to and including version 1.26.0 that perform DNSSEC validation are affected. No public proof-of-concept or confirmed in-the-wild exploitation is currently known, and the issue is not in CISA's KEV catalog.

Do: Upgrade Unbound to the patched release announced by NLnet Labs (any version beyond 1.26.0 containing the fix) as soon as it is available, and confirm the running version with 'unbound -V'. Until patching, restrict recursion to trusted clients, monitor NLnet Labs' advisory for fixed versions and workarounds, and treat unexplained resolver crashes or restarts as suspicious.

Arista EOS contains a privilege-assignment flaw (CWE-266) in which gRPC requests from an authenticated user to the OpenConfig interface may be evaluated at the wrong privilege level, causing authorization to run against the wrong AAA method list. It is triggered when a user sends a gRPC OpenConfig request to a device on which AAA-based gRPC authorization for OpenConfig is enabled; non-gRPC OpenConfig transports such as NETCONF are not affected. An attacker holding valid credentials could gain authorization for configuration changes or operations beyond their intended privileges, consistent with the 9.4 CVSS 4.0 score's high confidentiality, integrity, and availability impact. Only Arista EOS platforms with this specific gRPC/OpenConfig AAA configuration are affected. No exploitation in the wild, public proof-of-concept, or CISA KEV listing is currently known.

Do: Inventory EOS devices for OpenConfig over gRPC and check whether AAA-based gRPC authorization is enabled; where present, restrict gRPC access to trusted management hosts via ACLs or management-plane filtering while awaiting the fixed release, since specific fixed EOS versions are not listed in the available data. Review AAA method lists and audit recent gRPC-authenticated sessions for activity performed at unintended privilege levels.

CVE-2026-27565 is an unauthenticated OS command injection flaw (CWE-78) in the affected product's processing of IODD files. A remote attacker can upload a maliciously crafted IODD file with no credentials and no user interaction, causing the device to write and execute a shell script with root privileges. The injected script persists across reboots, giving the attacker a durable foothold at the highest privilege level on the device and a potential pivot point into the attached host or network. Owners and operators of IODD encrypted portable storage devices are affected. No exploitation has been observed, no public proof-of-concept is known, and the issue is not listed in CISA's KEV.

Do: Monitor the CERT@VDE advisory and IODD vendor channels for a fixed firmware release and update all affected devices as soon as one is available. Until patched, limit which hosts can reach the device's management/file-upload interface, avoid loading IODD files from untrusted sources, and inspect devices for unexpected scripts or persistence mechanisms that survive a reboot, which would indicate compromise.

CVE-2026-27546 is a critical (CVSS 9.8) authentication bypass (CWE-288) in the _account_log function of the affected application, coordinated by CERT VDE; the specific vendor, product, and version range are not identified in the available data. An unauthenticated remote attacker can reach the vulnerable login routine over the network with low attack complexity, no privileges, and no user interaction, and is authenticated as an administrator even when accounts are properly configured. Full admin access yields the complete confidentiality, integrity, and availability impact reflected in the score, including reading and modifying data, changing application settings, and creating or altering accounts. Any deployment of the affected product is at risk, especially instances reachable from the internet; defenders should consult the CERT VDE advisory for the definitive product and version list. Exploitation has not been observed, the issue is not in CISA KEV, and no public proof-of-concept is known.

Do: Because no fixed version or vendor is given in the available data, monitor the CERT VDE advisory feed (cert.vde.com) for CVE-2026-27546 and apply the vendor's patch as soon as the affected product is identified. Until patched, restrict network access to the application's login endpoint (allow-list, VPN, or reverse-proxy rule) and review authentication logs for successful admin logins from unexpected source IPs. If unauthorized admin activity is found, rotate all administrative credentials after patching.

CVE-2026-73447 is an OS command injection flaw (CWE-78) in the gRPC Network Security Interface (gNSI) Certz service on Arista EOS-based products. An authenticated attacker who already holds high privileges can send a crafted Certz Rotate request, causing arbitrary operating system commands to run with root privileges; the Bootz service is also affected. Successful exploitation grants full control of the device, including its configuration, traffic, and availability. All operators running Arista EOS-based products with the gNSI Certz or Bootz services enabled are in scope. As of this analysis there is no CISA KEV listing, no public proof-of-concept, and no known exploitation.

Do: Track Arista's PSIRT advisory (CVE assigned by [email protected]) and upgrade EOS to the fixed release it specifies once published. In the interim, restrict access to gNSI/gRPC management services (Certz and Bootz) to trusted management networks via management-plane ACLs, and audit which accounts hold the privileged access required to invoke Certz Rotate. Monitor logs for unexpected or anomalous Certz Rotate and Bootz requests.

The TrueBooker – Appointment Booking and Scheduler System plugin for WordPress contains an authorization bypass (CWE-862, missing authorization check) in all versions up to and including 1.2.3. Because the plugin does not properly verify that a user is authorized to perform an action, an unauthenticated attacker can craft a request to change the email address of arbitrary user accounts, including administrators. Once the email address is changed, the attacker can trigger a password reset and take over the account, ultimately gaining full administrative access to the affected site. Any WordPress site running TrueBooker at or below version 1.2.3 is affected; the flaw is rated critical (CVSS 3.1: 9.8). No public proof-of-concept or exploitation in the wild is currently known.

Do: Update TrueBooker to the latest available version immediately, since every release through 1.2.3 is vulnerable; if no fixed version is available yet, deactivate and remove the plugin. Audit user accounts — especially administrators — for unexpected email address changes or password resets that could indicate compromise. Enable two-factor authentication on administrator accounts and rotate passwords for any account showing signs of tampering.

The JetFormBuilder — Dynamic Blocks Form Builder plugin for WordPress is vulnerable to a critical unauthenticated privilege escalation flaw (CVSS 3.1: 9.8) in all versions up to and including 3.6.2. The plugin fails to verify that a submitted form ID actually corresponds to a JetFormBuilder form before parsing the referenced post's content as form schema and executing an Advanced Validation server-side callback. By submitting crafted form data that references an arbitrary post, an unauthenticated attacker can cause the callback to run and create a new administrator-level user account, effectively taking full control of the site. Any WordPress site running the plugin at version 3.6.2 or earlier is affected. No public PoC or known in-the-wild exploitation exists, and the issue is not in CISA's KEV catalog, but the unauthenticated, high-impact nature means defenders should treat it as urgently patchable.

Do: Upgrade JetFormBuilder to a version newer than 3.6.2 (the latest available release) immediately; if no update is available yet, deactivate the plugin or use a firewall/WAF rule to restrict its form-submission endpoint. After patching, review the WordPress user list for any unexpected administrator accounts created recently and check access logs for anomalous form submissions from unauthenticated sources. If a rogue admin is found, remove the account, rotate all credentials and salts, and audit for malicious plugins, uploads, or modified theme files.

CVE-2026-15640 is a critical (CVSS 4.0: 9.5) authentication bypass flaw (CWE-290) in Delinea Secret Server in which, under certain conditions, a valid SAML Identity Provider response can be used to impersonate another Secret Server user. An attacker with a legitimate SAML response for their own account (or the ability to influence how the response is processed) could authenticate as a different user of the privileged access management platform, potentially gaining access to that user's stored secrets, credentials, and privileged accounts. Exploitation is network-based but has high attack complexity and requires attacker prerequisites, suggesting specific SAML configuration or assertion conditions must be met. The flaw affects organizations deploying Delinea Secret Server with SAML single sign-on enabled; the specific affected versions were not stated in the available data. There is no known public proof of concept and the CVE is not in CISA's Known Exploited Vulnerabilities catalog, indicating no confirmed in-the-wild exploitation at this time.

Do: Apply the vendor's patched Secret Server release as soon as Delinea publishes the fixed version, prioritizing instances with SAML SSO enabled. Review authentication and audit logs for SAML logins where the authenticated identity does not match the asserted NameID, and validate SAML claim/NameID mapping configuration against vendor guidance. Until patched, consider increasing monitoring on SAML-authenticated sessions or temporarily restricting SAML SSO for high-privilege accounts.

CVE-2026-15639 is a reflected cross-site scripting (XSS) flaw in which an attacker crafts a malicious link that, when clicked by a legitimate user, causes the victim's browser to execute attacker-supplied JavaScript. Exploitation requires user interaction (CVSS:4.0 UI:A), so victims would typically be lured through phishing messages or embedded links pointing at the vulnerable application. Successful abuse lets the attacker run script in the victim's browser session, enabling session/cookie theft, credential capture, defacement, or unauthorized actions taken as the victim, reflected in the 9.3 critical CVSS:4.0 vector with high confidentiality and integrity impact. The data provided does not name an affected vendor, product, or version range, so the vulnerable population cannot yet be scoped. No public proof-of-concept is known and the flaw is not in CISA's Known Exploited Vulnerabilities catalog, so no in-the-wild exploitation has been observed.

Do: Monitor the assigning CNA's advisory and NVD for the affected product and patched versions, and upgrade to the fixed release as soon as they are identified. In the meantime, apply generic XSS mitigations on the site in question: context-aware output encoding, a restrictive Content-Security-Policy, and HttpOnly/SameSite session cookies, and warn users against following unsolicited deep links. Review application and proxy logs for URLs carrying script-like payloads in parameters, which would indicate probing for this flaw.

CVE-2026-15638 is a padding oracle vulnerability in Delinea Secret Server that allows an unauthenticated attacker with network access to a Secret Server instance to decrypt existing ciphertext or encrypt new data using one of the server's own cryptographic keys, without ever learning the key itself. It is triggered by sending carefully crafted encrypted payloads to the server and observing padding-validity differences in responses, a classic chosen-ciphertext technique (CWE-327, use of a broken or risky cryptographic construction). Successful exploitation lets an attacker read protected data handled by the server — a serious concern since Secret Server is a privileged access management vault storing credentials for downstream systems — and forge encrypted data, with CVSS 4.0 rating it critical (9.1) largely due to high confidentiality impact on both the vault and subsequent systems. Note the vector requires high attack complexity and present attack prerequisites, so exploitation is non-trivial despite the score. There is no known public proof-of-concept, no confirmed exploitation in the wild, and the CVE is not on CISA's KEV list.

Do: Apply Delinea's patched Secret Server release as soon as it is available per the vendor's security bulletin, prioritizing any instance reachable from untrusted networks. Restrict access to Secret Server endpoints via VPN or IP allowlisting, since the attack requires network access to the server. After patching, review logs for anomalous repeated or failed decryption attempts against encrypted fields and rotate high-value stored secrets and the server's crypto items if suspicious activity is found.

Wärtsilä FOS-Onboard, a shipboard fleet operations software suite, contains a hardcoded cryptographic client authentication key (CWE-321) in its robot testing framework component. Because the key is embedded in shipped software, anyone who obtains a copy of the product can extract it and impersonate a legitimate client to the authentication mechanism, with no privileges or user interaction required (CVSS 4.0: 9.3, network vector, high confidentiality and integrity impact). A successful attacker could gain unauthorized read and write access to onboard system data, though the advisory indicates no direct availability impact. Affected parties are vessel operators and offshore assets running FOS-Onboard, particularly any deployments where the testing framework component is present and reachable on the ship's network. No public proof-of-concept exists and the flaw is not in CISA's Known Exploited Vulnerabilities catalog, so exploitation is not known to be occurring.

Do: Contact Wärtsilä to confirm which FOS-Onboard builds are affected and apply the vendor's patched release when available. In the meantime, disable or remove the robot testing framework component from production onboard systems, and use network segmentation/firewall rules to restrict which hosts can reach the affected authentication service. Rotate any related keys or credentials and review authentication logs for anomalous client connections.

Wärtsilä FOS-Onboard, a maritime fleet operations software suite deployed onboard vessels, contains a hardcoded cryptographic server key (CWE-321) in its deployer-ng Update Controller component. Because the key is embedded in the shipped software, anyone with access to the product binaries could extract it and then impersonate the legitimate update server or forge/tamper with update communications against exposed installations over the network, with no privileges or user interaction required. Successful abuse could allow an attacker to push manipulated updates or otherwise compromise the onboard system, with the CVSS 4.0 vector (9.5, all impact dimensions high, including safety) indicating severe consequences for vessel system confidentiality, integrity, availability, and safety. Vessel operators running FOS-Onboard with the deployer-ng Update Controller reachable from ship or shore networks are affected. No public proof-of-concept exists, the flaw is not on the CISA KEV list, and no exploitation in the wild is known at this time.

Do: Apply the vendor fix per the Wärtsilä and CISA ICS advisory and replace/rotate the hardcoded key, since the shipped key must be treated as compromised. Until patched, restrict network reachability of the deployer-ng Update Controller by segmenting onboard OT networks, firewalling the update path, and limiting update services to trusted shore-side endpoints. Monitor update traffic and controller logs for anomalous or unsigned update attempts, and verify with Wärtsilä exactly which FOS-Onboard versions are vulnerable and which version remediates the issue.

The mySCADA myPRO Manager command API fails to enforce authentication on privileged functions (CWE-862, missing authorization), allowing any unauthenticated attacker with network access to the API to invoke those functions directly. Exploitation requires no credentials, privileges, or user interaction (CVSS v4.0 9.3, critical, network attack vector), making it a simple crafted-request attack against any reachable instance. A successful attacker gains access to privileged management functions of the Manager component, which could be leveraged to manipulate the myPRO HMI/SCADA environment it administers. Affected users are industrial organizations running mySCADA myPRO Manager with the command API reachable from untrusted networks; the advisory data does not specify affected version ranges. No public PoC is known, the CVE is not on CISA's KEV list, and there is no evidence of exploitation in the wild.

Do: Restrict network access to the myPRO Manager command API so it is reachable only from trusted management hosts via firewall rules, VPN, or OT network segmentation — it should never be internet-facing. Check the ICS-CERT and mySCADA advisories for a fixed release and upgrade Manager as soon as one is available. Review Manager logs for unauthenticated or unexpected API calls that could indicate probing or attempted exploitation.

@zereight/mcp-gitlab, a Model Context Protocol (MCP) server for GitLab, in all versions prior to 2.1.27 exposes every MCP tool without authentication when run in SSE transport mode (SSE=true), which is the default for Docker deployments. An unauthenticated attacker who can reach the server over the network can invoke the upload_markdown tool, whose unsanitized file_path parameter permits path traversal (CWE-22) to read arbitrary files from the server's local filesystem, which are then uploaded to an attacker-visible GitLab project. By reading /proc/self/environ, the attacker can steal the server's GITLAB_PERSONAL_ACCESS_TOKEN and achieve full takeover of the associated GitLab account. Anyone running the package below 2.1.27 in SSE mode on a network-reachable host is affected, with a critical CVSS 3.1 score of 9.8. No public proof-of-concept is known and the flaw is not on the CISA KEV catalog, so exploitation status is currently none known.

Do: Upgrade to @zereight/mcp-gitlab version 2.1.27 or later immediately. If the SSE port was ever reachable by untrusted hosts (check Docker port bindings and firewall rules for 0.0.0.0 exposure), treat the GITLAB_PERSONAL_ACCESS_TOKEN as compromised: revoke and rotate it, review GitLab audit logs and personal access token usage for anomalous activity, and restrict the service to localhost or an authenticated reverse proxy going forward.

Cotonti 1.0.0's Comments plugin feeds the unauthenticated 'ci' GET parameter directly into PHP's unserialize() without the allowed_classes restriction, allowing arbitrary PHP objects with attacker-controlled properties to be instantiated. By sending a crafted serialized payload in the URL, an unauthenticated attacker can trigger gadget chains available in the application, resulting in database manipulation or remote code execution. The flaw is rated critical (CVSS 4.0: 9.3) and is classified as CWE-502 (deserialization of untrusted data). Sites running Cotonti 1.0.0 with the Comments plugin enabled are affected. No public proof of concept is known, the issue is not in CISA's KEV catalog, and there is no evidence of exploitation in the wild, but exploitation requires only a simple HTTP request once a viable gadget chain is identified.

Do: Upgrade Cotonti to the latest release as soon as a fixed version is available, or disable the Comments plugin if it is not needed. In the meantime, use a WAF or reverse proxy rule to block requests to the Comments plugin containing suspicious serialized data in the 'ci' parameter (e.g., strings starting with 'O:' or 'a:'). Audit web server logs for historical requests with a 'ci' parameter carrying serialized payload markers, and verify database integrity and web roots for signs of code injection.

CVE-2026-91749 is a critical-severity use-after-free vulnerability (CWE-416) in the Workers component of Google Chrome, fixed in version 153.0.8010.47. A remote attacker triggers the flaw by luring a victim to a crafted HTML page, where a freed memory object in the Worker implementation is improperly reused, potentially allowing arbitrary code execution outside the browser sandbox. Successful exploitation means a malicious webpage can escape Chrome's sandbox and run code on the underlying operating system with the user's privileges, effectively fully compromising the workstation. All Chrome installations prior to 153.0.8010.47 are affected on every platform, and third-party Chromium-based browsers inherit the vulnerable engine code until they ship the upstream fix. No public proof-of-concept is known and the bug is not on CISA's Known Exploited Vulnerabilities catalog, but the Critical severity rating indicates Google judged the potential impact to be severe.

Do: Update Google Chrome to version 153.0.8010.47 or later immediately and verify via chrome://settings/help; enterprises should confirm update policies have applied the fix fleet-wide. Because exploitation requires only that a victim visit a crafted page, defenders should monitor EDR telemetry for renderer/worker-process crashes or unexpected child processes spawned by Chrome until the fleet is fully patched. Administrators of Chromium-based browsers that bundle the same engine (e.g., Edge, Brave, Vivaldi, Opera) should deploy those vendors' equivalent updates as soon as they are released.

CVE-2026-91738 is an improper input validation flaw (CWE-20) in ANGLE, the graphics translation layer Chrome uses to render WebGL content, affecting Google Chrome versions prior to 153.0.8010.47. An attacker can trigger it by luring a user to a crafted HTML page whose graphics/WebGL content sends malformed input to ANGLE. Successful exploitation could allow arbitrary code execution outside the browser's renderer sandbox, defeating Chrome's core isolation boundary and giving the attacker code execution with greater system access. Effectively every Chrome user on an unpatched version is exposed, since ANGLE ships enabled by default, and Chromium-based browsers that inherit the ANGLE code are likely affected pending vendor advisories. No public proof-of-concept, CISA KEV listing, or known in-the-wild exploitation has been reported, and Google rates the issue Medium even though the supplied CVSS score is 9.6 (critical).

Do: Update Google Chrome to 153.0.8010.47 or later as soon as it is available (verify via chrome://settings/help), and have administrators force the update through browser management or patch-deployment tools. As an interim mitigation for high-risk users, consider restricting WebGL or JavaScript on untrusted sites. Users of Chromium-based browsers (e.g., Edge, Brave, Opera) should watch for and apply vendor updates that incorporate this ANGLE fix, since they share the vulnerable code.

CVE-2026-91729 is a use-after-free memory corruption flaw (CWE-416) in the DigitalCredentials component of Google Chrome, fixed in version 153.0.8010.47. A remote attacker triggers it by using social engineering to lure a victim to a crafted HTML page that causes the browser to access freed memory in that component. Successful exploitation allows the attacker to execute arbitrary code outside Chrome's sandbox, a capability Chromium's security team rates as High severity. All users running Chrome versions earlier than 153.0.8010.47 are affected. No public proof-of-concept is known, the flaw is not on CISA's Known Exploited Vulnerabilities catalog, and there is no evidence of exploitation in the wild.

Do: Update Google Chrome to version 153.0.8010.47 or later immediately; the fix ships in the Chrome 153 stable release, which resolved 42 security flaws. Enterprise and IT admins should verify that auto-update has applied the new version across managed fleets (check Help > About or chrome://version on endpoints). Chromium-derived browsers such as Edge, Brave, and Opera generally inherit this component, so apply their corresponding security updates as vendors release them.

CVE-2026-91728 is an integer overflow (CWE-190) in the V8 JavaScript engine used by Google Chrome, fixed in version 153.0.8010.47. The flaw is triggered when a user visits a crafted HTML page, where malformed JavaScript causes an integer overflow leading to memory corruption in the renderer. Successful exploitation allows a remote attacker to execute arbitrary code inside the browser sandbox, and Chromium rates the severity High; the CVSS 3.1 score of 9.6 reflects high impact to confidentiality, integrity, and availability if chained with a separate sandbox escape. All users running Chrome versions prior to 153.0.8010.47 on any platform are affected. No public proof-of-concept is known, the flaw is not on CISA's KEV list, and no exploitation in the wild has been reported.

Do: Update Google Chrome to version 153.0.8010.47 or later immediately and verify via Help > About Chrome; enterprises should confirm auto-update policies are not delaying rollout. Because the flaw resides in V8, users of other Chromium-based browsers (Edge, Brave, Opera, Vivaldi) should apply those vendors' updates as the fix propagates. Exploitation requires user interaction with a malicious page, so blocking known-bad links adds defense-in-depth, but patching is the definitive mitigation.

CVE-2026-91718 is a use-after-free vulnerability in the Core component of Google Chrome that allows a remote attacker to execute arbitrary code outside the browser sandbox via a specially crafted HTML page. The flaw exists in Chrome versions prior to 153.0.8010.47 and is rated High severity by the Chromium security team. An attacker who successfully exploits this vulnerability gains the ability to run arbitrary code on the victim's system, potentially bypassing Chrome's sandbox protections. All users of Google Chrome who have not yet updated to version 153.0.8010.47 or later are affected. No public proof-of-concept or known in-the-wild exploitation has been reported at this time.

Do: Update Google Chrome to version 153.0.8010.47 or later immediately via Chrome Settings > About Chrome. Enterprise administrators should verify that managed deployments are pulling the latest stable channel update and consider using Chrome's auto-update policies to enforce rapid patching. Monitor for any future reports of in-the-wild exploitation, as use-after-free flaws in Chrome are frequently weaponized once details become public.

CVE-2026-91716 is a use-after-free vulnerability (CWE-416) in the Auth component of Google Chrome that was fixed in version 153.0.8010.47. A remote attacker can exploit it by tricking a victim into visiting a crafted HTML page, which triggers the memory-corruption flaw during authentication handling. Successful exploitation allows the attacker to execute arbitrary code outside the browser's sandbox, meaning full compromise of the underlying user account rather than confinement to the sandboxed renderer. All users running Chrome versions prior to 153.0.8010.47 on any supported desktop platform are affected. Google rates the severity High; there is no known public proof-of-concept, it is not in the CISA Known Exploited Vulnerabilities catalog, and no exploitation in the wild has been reported at this time.

Do: Update Google Chrome to version 153.0.8010.47 or later immediately; users can confirm their version via chrome://settings/help. Enterprise administrators should verify that Chrome's auto-update mechanism is enabled and functioning across managed fleets, and push the update to any devices lagging behind. Because the flaw lies in Chromium's Auth component, users of other Chromium-based browsers should also apply their vendors' updates as they become available, since this Chrome CVE version number does not map directly to those products.