Critical security advisoryCriticalFlagged by our vulnerability database: PHP2Shell is on CISA’s exploited list. Most WordPress hosting runs PHP. See if your site is affectedFlagged by our vulnerability database: PHP2Shell is being exploited. DetailsExploited: PHP2Shell. Check your site
HuttenlocherTechnologies
Updated 8 min ago

Vulnerability database

Every flaw the U.S. government’s cybersecurity agency (CISA) has confirmed attackers are using, plus the new WordPress plugin and theme bugs published each day, sorted by what they mean for a small business. We refresh it twice a day. If you see something your website or office runs, tell us.

1,766exploited flaws on CISA’s list
33added in the last 30 days
557new WordPress flaws this week
391,528entries in the database

38,316 results · page 44 of 767

  • Sep 16, 2026@fastify/proxy-addr is a Fastify plugin that determines a request's client address behind trusted reverse proxies, and it backs Fastify request.ip and request.iCVE-2026-92395 · Other software · @fastify/proxy-addr · reported by ce714d77-add3-4f53-aff5-83d477b104bbCritical 9.1

    @fastify/proxy-addr is a Fastify plugin that determines a request's client address behind trusted reverse proxies, and it backs Fastify request.ip and request.ips. In versions 3.0.0 through 5.1.0, a trust subnet written in IPv4-mapped IPv6 notation with an IPv4-sized prefix, such as ::ffff:10.0.0.0/8 instead of the correct ::ffff:10.0.0.0/104, is accepted without error but trusts every IPv4 address on the internet rather than the block it names. Because the socket peer then becomes trusted at hop 0, any unauthenticated client can supply an arbitrary X-Forwarded-For header and control the address the application reads, which defeats IP-based access control, rate limiting, geolocation, and audit logging. The plugin inherited this defect from the upstream proxy-addr module (CVE-2026-90711). The issue is fixed in @fastify/proxy-addr 5.1.1, and users should upgrade to 5.1.1 or later. As a workaround, ensure any IPv4-mapped IPv6 trust subnet uses a prefix length of at least 97, or express the range in plain IPv4 notation.

    Product
    @fastify/proxy-addr
    What to do
    Apply the vendor’s update. The NVD record links to the advisory.
  • Sep 16, 2026RabbitMQ amqp091-go is a Go AMQP 0.9.1 client.CVE-2026-77411 · Other software · rabbitmq · reported by GitHubCritical 9.5

    RabbitMQ amqp091-go is a Go AMQP 0.9.1 client. Prior to 1.13.0, readLongstr in read.go returns an empty string and a nil error when a declared AMQP longstr length exceeds 0x7FFFFFFF instead of returning ErrSyntax. The function leaves the declared field bytes unread, while readTable treats the operation as successful and continues parsing from the wrong offset. A malicious or compromised broker can provide an oversized longstr in a table field and desynchronize subsequent AMQP parsing, causing attacker-controlled trailing bytes to be interpreted as later fields or frames and disrupting connection integrity and availability. This issue is fixed in version 1.13.0.

    Product
    amqp091-go
    What to do
    Apply the vendor’s update. The NVD record links to the advisory.
  • Sep 16, 2026RabbitMQ amqp091-go is a Go AMQP 0.9.1 client.CVE-2026-77408 · Other software · rabbitmq · reported by GitHubCritical 9.1

    RabbitMQ amqp091-go is a Go AMQP 0.9.1 client. Prior to 1.13.0, the writeShortstr function in write.go casts the byte length of AMQP shortstr property values to uint8 without first rejecting values longer than 255 bytes. An application that accepts an oversized CorrelationId, ReplyTo, MessageId, Expiration, UserId, AppId, ContentType, ContentEncoding, or Type value can therefore serialize a wrapped length and only a truncated prefix, while reporting no error. The resulting silent metadata corruption can break request and reply correlation, routing, tracing, and downstream message processing. This issue is fixed in version 1.13.0.

    Product
    amqp091-go
    What to do
    Apply the vendor’s update. The NVD record links to the advisory.
  • Sep 16, 2026RabbitMQ amqp091-go is a Go AMQP 0.9.1 client.CVE-2026-77405 · Other software · rabbitmq · reported by GitHubCritical 9.4

    RabbitMQ amqp091-go is a Go AMQP 0.9.1 client. Prior to 1.13.0, tlsConfigFromURI in uri.go creates tls.Config values without setting MinVersion to tls.VersionTLS12. Builds using a Go runtime whose default permits TLS 1.0 or TLS 1.1 can therefore negotiate an obsolete protocol version when connecting through an amqps URI. A network attacker able to influence TLS negotiation with such a legacy build may weaken transport protection for AMQP messages and credentials. This issue is fixed in version 1.13.0.

    Product
    amqp091-go
    What to do
    Apply the vendor’s update. The NVD record links to the advisory.
  • Sep 16, 2026A stack overflow during the unauthenticated login process may allow an attacker to run arbitrary code remotely with root privileges.CVE-2026-91843 · Other software · checkpoint · reported by cve@checkpoint.comCritical 9.8

    A stack overflow during the unauthenticated login process may allow an attacker to run arbitrary code remotely with root privileges.

    Product
    Quantum Security Management
    What to do
    Apply the vendor’s update. The NVD record links to the advisory.
  • Sep 16, 2026Nozomi Networks Labs identified a CWE-78: Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection') vulnerability in the edgserCVE-2026-73172 · Other software · Advantech · reported by prodsec@nozominetworks.comCritical 9.3

    Nozomi Networks Labs identified a CWE-78: Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection') vulnerability in the edgserver management service of Advantech EKI-1242EIMS in firmware version V1.06.01 that allows a remote unauthenticated attacker to execute arbitrary OS commands as root via crafted requests to TCP port 5058.

    Product
    EKI-1242IEIMS
    What to do
    Apply the vendor’s update. The NVD record links to the advisory.
  • Sep 16, 2026WNC T-Mobile 5G Box IDU router contains an OS command injection vulnerability in the portal.cgi component's password change functionality.CVE-2026-58147 · Other software · WNC · reported by cvd@cert.plCritical 9.3

    WNC T-Mobile 5G Box IDU router contains an OS command injection vulnerability in the portal.cgi component's password change functionality. The application improperly neutralizes special elements in the http_passwd_hidden and http_passwdConfirm_hidden parameters, allowing an authenticated attacker to execute arbitrary commands on the underlying operating system with root privileges.This issue has been fixed in firmware version 1.1.0.651412

    Product
    T-Mobile 5G Box IDU
    What to do
    Apply the vendor’s update. The NVD record links to the advisory.
  • Sep 16, 2026WNC T-Mobile 5G Box IDU router is vulnerable to OS command injection vulnerability.CVE-2026-58146 · Other software · WNC · reported by cvd@cert.plCritical 9.4

    WNC T-Mobile 5G Box IDU router is vulnerable to OS command injection vulnerability. The vulnerability exists within the /cgi-bin/portal.cgi endpoint, specifically through the cli_cookie POST parameter. The cli_cookie parameter value is directly concatenated into a find command string without proper sanitization. This allows a remote, unauthenticated attacker to inject and execute arbitrary shell commands as root on the underlying operating system. This issue has been fixed in firmware version 1.1.0.651412

    Product
    T-Mobile 5G Box IDU
    What to do
    Apply the vendor’s update. The NVD record links to the advisory.
  • Sep 16, 2026WNC T-Mobile 5G Box IDU router is vulnerable to a command injection.CVE-2026-40855 · Other software · WNC · reported by cvd@cert.plCritical 9.3

    WNC T-Mobile 5G Box IDU router is vulnerable to a command injection. The vulnerability exists in the ping functionality within the /cgi-bin/portal.cgi endpoint, specifically affecting the ping_ip, ping_size, and ping_times POST parameters. The root cause is the failure to verify and sanitize user-supplied input before incorporating it into a system command. This allows an authenticated attacker to execute arbitrary commands on the shell and gain root access to the system.This issue has been fixed in firmware version 1.1.0.651412

    Product
    T-Mobile 5G Box IDU
    What to do
    Apply the vendor’s update. The NVD record links to the advisory.
  • Sep 16, 2026In the Linux kernel, the following vulnerability has been resolved: net: skbuff: don't skb_tx_error() the source skb in skb_zerocopy() skb_zerocopy() copies fCVE-2026-90049 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67Critical 9.3

    In the Linux kernel, the following vulnerability has been resolved: net: skbuff: don't skb_tx_error() the source skb in skb_zerocopy() skb_zerocopy() copies frags from @from into @to. On an skb_orphan_frags() failure it calls skb_tx_error(@from), a destructive operation on the source skb the copy helper does not own. That completes @from's zerocopy uarg and clears SKBFL_ALL_ZEROCOPY, including the SKBFL_SHARED_FRAG page-ownership marker. Both callers already report the failure on their own drop path. nfnetlink_queue does it at nla_put_failure, and Open vSwitch does it in the flow-miss drop arm of ovs_dp_process_packet(), so nothing is lost by dropping it here. On Open vSwitch's OVS_ACTION_ATTR_USERSPACE path the skb is not freed on this error: do_execute_actions() ignores output_userspace()'s return value and, unless the upcall was the last action, keeps forwarding the same skb through the flow's remaining actions. The uarg is completed while that skb is still in flight, telling the producer its buffers are free, and SKBFL_SHARED_FRAG is cleared on an skb the rest of the stack still handles. That flag is what makes esp_input() call skb_cow_data() instead of decrypting in place,

    Product
    Linux
    What to do
    Apply the vendor’s update. The NVD record links to the advisory.
  • Sep 16, 2026In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: fix slab-out-of-bounds write in ni_create_attr_list() ni_create_attr_list() alloCVE-2026-90048 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67Critical 9.8

    In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: fix slab-out-of-bounds write in ni_create_attr_list() ni_create_attr_list() allocates a fixed buffer of al_aligned(record_size) (== record_size) bytes and then walks every attribute of the primary MFT record, writing one ATTR_LIST_ENTRY per attribute and advancing the cursor by le_size(name_len), with no check against the end of the buffer; the total size is only computed after the loop. A minimum-size resident attribute occupies SIZEOF_RESIDENT (0x18 = 24) bytes on disk, but an unnamed attribute expands to le_size(0) (0x20 = 32) bytes in the list. Because the number of attributes in a record is not bounded (mi_enum_attr() accepts arbitrarily many equal-type, nameless minimum-size attributes), a crafted record packed with such attributes produces a list larger than record_size and overflows the heap buffer. This is reachable from a crafted, loop-mounted NTFS image: opening the 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(). BUG: KASAN: slab-out-of-bounds in ni_create_attr_list+0xc48/0x1

    Product
    Linux
    What to do
    Apply the vendor’s update. The NVD record links to the advisory.
  • Sep 16, 2026In the Linux kernel, the following vulnerability has been resolved: ceph: properly decrypt filenames in vmalloc() buffers The fscrypt subsystem uses the scattCVE-2026-90042 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67Critical 9.8

    In the Linux kernel, the following vulnerability has been resolved: ceph: properly decrypt filenames in vmalloc() buffers The fscrypt subsystem uses the scatterlist crypto API, inheriting its requirement that any buffers are in the linear mapping region. However, the messenger client uses kvmalloc() to create buffers for messages, which will occasionally place those buffers in the vmalloc() region when physical memory fragmentation doesn't permit a large enough kmalloc(). The various callers of ceph_fname_to_usr() directly pass (slices of) raw messages from the MDS without considering that the messages may be in vmalloc() buffers, resulting in oopses especially on non-x86 platforms (see 'Closes:' for more details and a reproducer). Make ceph_fname_to_usr() explicitly tolerant of vmalloc()-allocated fname->ctext, fname->name, and/or oname->name buffers, using `tname` (which, when non-null, must be a linear address; when null, is briefly allocated as necessary) as a bounce buffer to avoid passing any inappropriate addresses to fscrypt_fname_disk_to_usr(). Additionally change parse_reply_info_readdir() -- the only function to supply its own `tname` -- to follow the new "tname must

    Product
    Linux
    What to do
    Apply the vendor’s update. The NVD record links to the advisory.
  • Sep 16, 2026In the Linux kernel, the following vulnerability has been resolved: NFSD: Prevent client use-after-free during export state revocation nfsd4_revoke_export_staCVE-2026-90038 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67Critical 9.8

    In the Linux kernel, the following vulnerability has been resolved: NFSD: Prevent client use-after-free during export state revocation nfsd4_revoke_export_states() has the same use-after-free as nfsd4_revoke_states(): it drops nn->client_lock across revoke_one_stid() and the following read of clp->cl_minorversion, but the stateid reference it holds does not pin the client. A teardown racing the dropped lock can free the client while revoke_one_stid() still dereferences it. exportfs -u drives this path through NFSD_CMD_UNLOCK_EXPORT, so an administrator removing an export can race a client expiry. Skip a client that is already expiring and otherwise pin it with cl_rpc_users under client_lock before dropping the lock, matching nfsd4_revoke_states().

    Product
    Linux
    What to do
    Apply the vendor’s update. The NVD record links to the advisory.
  • Sep 16, 2026In the Linux kernel, the following vulnerability has been resolved: NFSD: Prevent client use-after-free during close_lru reaping An nfs4_openowner left on nn-CVE-2026-90037 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67Critical 9.8

    In the Linux kernel, the following vulnerability has been resolved: NFSD: Prevent client use-after-free during close_lru reaping An nfs4_openowner left on nn->close_lru after its final CLOSE keeps its last closed stateid in oo_last_closed_stid, holding only a raw pointer to its nfs4_client. The laundromat reaps timed-out entries, drops nn->client_lock, and calls nfs4_put_stid(), which dereferences the client through cl_lock. Nothing pins the client across that window, so a concurrent force_expire_client() can free it and nfs4_put_stid() reads freed memory. __destroy_client() hits the same race, walking clp->cl_openowners without cl_lock. Pin the client with cl_rpc_users before dropping client_lock, and skip clients already expiring. __destroy_client() then cleans up its own close_lru entries through release_last_closed_stateid(), so teardown no longer races the laundromat.

    Product
    Linux
    What to do
    Apply the vendor’s update. The NVD record links to the advisory.
  • Sep 16, 2026In the Linux kernel, the following vulnerability has been resolved: NFSD: Prevent client use-after-free during blocked-lock reaping A bare lock owner -- its oCVE-2026-90036 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67Critical 9.8

    In the Linux kernel, the following vulnerability has been resolved: NFSD: Prevent client use-after-free during blocked-lock reaping A bare lock owner -- its only remaining reference a blocked lock on nn->blocked_locks_lru -- holds a raw pointer to its nfs4_client but no reference keeping the client alive. When the per-net laundromat reaps such a lock, freeing the nbl drops the owner reference held through flc_owner, and the final nfs4_put_stateowner() takes the client's cl_lock. Because the laundromat detaches the nbl first, __destroy_client() no longer finds it, so a concurrent force_expire_client() can free the client before nfs4_put_stateowner() runs, dereferencing cl_lock in freed memory. Pin the client with cl_rpc_users before dropping nn->blocked_locks_lock, and skip clients already expiring, whose blocked locks __destroy_client() frees while holding an owner reference. Take nn->client_lock outside nn->blocked_locks_lock. Every other site holds nn->blocked_locks_lock as a leaf, acquiring no further lock, so placing nn->client_lock outside it cannot form a lock-order cycle.

    Product
    Linux
    What to do
    Apply the vendor’s update. The NVD record links to the advisory.
  • Sep 16, 2026In the Linux kernel, the following vulnerability has been resolved: spi: Fix DMA mapping ownership on partial map failure If RX mapping fails after TX mappingCVE-2026-90012 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67Critical 9.8

    In the Linux kernel, the following vulnerability has been resolved: spi: Fix DMA mapping ownership on partial map failure If RX mapping fails after TX mapping succeeds, __spi_map_msg() unmaps TX but leaves tx_sg_mapped set. If TX mapping fails on a later transfer, mappings created for earlier transfers remain active. In both cases, cur_{tx,rx}_dma_dev have not yet been updated because they are assigned only after every transfer has been mapped. The subsequent spi_unmap_msg() may therefore unmap the TX mapping again or release earlier mappings using a NULL or stale device. Using a NULL device can trigger an oops. An empty SG table does not prevent the NULL dereference because dma_unmap_sg_attrs() accesses the device before checking the entry count. Publish both mapping devices before mapping starts and unwind all failures through __spi_unmap_msg(). This clears the mapping flags and releases each mapping once with the device that created it. Publishing the devices before the loop also refreshes them when no transfer needs mapping. No mapping flag is set in that case, so current users do not use the pointers as mapping owners.

    Product
    Linux
    What to do
    Apply the vendor’s update. The NVD record links to the advisory.
  • Sep 16, 2026In the Linux kernel, the following vulnerability has been resolved: scsi: target: iscsi: Reserve a terminator byte for the login payload iscsi_target_check_loCVE-2026-90011 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67Critical 9.1

    In the Linux kernel, the following vulnerability has been resolved: scsi: target: iscsi: Reserve a terminator byte for the login payload iscsi_target_check_login_request() rejects a login PDU whose DataSegmentLength exceeds MAX_KEY_VALUE_PAIRS, but the test is '>' and login->req_buf is allocated with exactly MAX_KEY_VALUE_PAIRS bytes. Since iscsit_get_login_rx() receives payload_length + padding bytes, where padding = ((-payload_length) & 3); any payload_length from 8189 to 8192 fills the whole 8192 byte buffer. The write stays in bounds, but no byte is left for a NUL terminator. The buffer is subsequently consumed as a C string. In the CHAP path chap_check_algorithm() calls kstrdup(a_str), and extract_param() calls strstr(in_buf, pattern) followed by strlen_semi(), none of which take a length. convert_null_to_semi() additionally rewrites every embedded NUL to ';', so even a payload made of well formed NUL separated key=value records is left without a terminator. These walk past the end of the object into adjacent slab memory. It is reachable by an unauthenticated initiator against a portal configured for CHAP; when authentication is not required iscsi_login_zero_tsih_s2() re

    Product
    Linux
    What to do
    Apply the vendor’s update. The NVD record links to the advisory.
  • Sep 16, 2026In the Linux kernel, the following vulnerability has been resolved: ceph: lock mutex in ceph_mds_check_access() MDS session OPEN handling replaces mdsc->s_capCVE-2026-89990 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67Critical 9.8

    In the Linux kernel, the following vulnerability has been resolved: ceph: lock mutex in ceph_mds_check_access() MDS session OPEN handling replaces mdsc->s_cap_auths under mdsc->mutex, freeing the previous array and its strings. ceph_mds_check_access() traverses this array without holding the mutex. A concurrent session reopen can therefore free the array while it is being inspected, resulting in a use-after-free like this: Unable to handle kernel paging request at virtual address 003aaad64b2c8bb9 [...] Internal error: Oops: 0000000096000004 [#1] SMP Modules linked in: CPU: 56 UID: 2953037534 PID: 1253231 Comm: php-cgi8.4 Not tainted 6.18.45-i2-ampere #1146 NONE [..] pc : ceph_mds_check_access+0xd4/0x550 lr : ceph_mds_check_access+0xc8/0x550 [...] Call trace: ceph_mds_check_access+0xd4/0x550 (P) ceph_atomic_open+0x138/0xbe8 path_openat+0xa24/0xfa8 do_filp_open+0x94/0x158 do_sys_openat2+0x88/0xf8

    Product
    Linux
    What to do
    Apply the vendor’s update. The NVD record links to the advisory.
  • Sep 16, 2026In the Linux kernel, the following vulnerability has been resolved: nvme: add missing SRCU grace period in error path nvme_alloc_ns() error path at out_unlinkCVE-2026-89972 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67Critical 9.8

    In the Linux kernel, the following vulnerability has been resolved: nvme: add missing SRCU grace period in error path nvme_alloc_ns() error path at out_unlink_ns removes ns from the namespace head siblings list with list_del_rcu(&ns->siblings) but does not wait for SRCU readers before freeing the namespace struct. Multipath code iterates the head->list under srcu_read_lock() in nvme_find_path() and nvme_mpath_revalidate_paths(), so a concurrent reader can still hold a reference to ns when kfree(ns) runs. The normal removal path in nvme_ns_remove() correctly calls synchronize_srcu(&ns->head->srcu) after list_del_rcu() to wait for in-progress readers. Add the same grace period in the error path.

    Product
    Linux
    What to do
    Apply the vendor’s update. The NVD record links to the advisory.
  • Sep 16, 2026In the Linux kernel, the following vulnerability has been resolved: nvmet-auth: Synchronize timeout work during SQ teardown nvmet_auth_sq_free() cancels auth_CVE-2026-89970 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67Critical 9.8

    In the Linux kernel, the following vulnerability has been resolved: nvmet-auth: Synchronize timeout work during SQ teardown nvmet_auth_sq_free() cancels auth_expired_work with cancel_delayed_work(). If the work has already started, cancellation does not wait for the callback. Transport teardown can consequently free or reuse the queue containing struct nvmet_sq while nvmet_auth_expired_work() still accesses that SQ. Add a teardown-specific helper that synchronously drains the delayed work before freeing authentication state, and use it from nvmet_sq_destroy(). Keep the non-synchronous helper for in-band authentication state cleanup, where the SQ owner remains alive.

    Product
    Linux
    What to do
    Apply the vendor’s update. The NVD record links to the advisory.
  • Sep 16, 2026In the Linux kernel, the following vulnerability has been resolved: nvmet-tcp: fix out-of-bounds write when receiving an over-long PDU nvmet_tcp_try_recv_pdu(CVE-2026-89969 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67Critical 9.8

    In the Linux kernel, the following vulnerability has been resolved: nvmet-tcp: fix out-of-bounds write when receiving an over-long PDU nvmet_tcp_try_recv_pdu() reads a PDU header into the fixed 128-byte queue->pdu union, then computes the remaining payload length as queue->left = hdr->hlen - queue->offset + hdgst; and reads that many more bytes into &queue->pdu + queue->offset, without ever bounding the result against sizeof(queue->pdu). A struct nvme_tcp_icreq_pdu is itself 128 bytes, exactly the size of the union. Once a header digest has been negotiated (hdgst = 4), a second ICReq passes the hlen == nvmet_tcp_pdu_size() check but yields queue->left = 128 - 8 + 4 = 124, so bytes 8..132 are written into the 128-byte buffer -- 4 bytes past its end, over queue->hdr_digest and queue->data_digest. Those bytes are attacker-controlled (an ICReq carries no digest), and the duplicate ICReq is only rejected later, after the overflow. A remote unauthenticated host can thus corrupt kernel memory adjacent to the receive buffer. Reject any PDU whose declared length would read past the end of queue->pdu before the second recv.

    Product
    Linux
    What to do
    Apply the vendor’s update. The NVD record links to the advisory.
  • Sep 16, 2026In the Linux kernel, the following vulnerability has been resolved: KVM: nVMX: Service local TLB flushes on failed nested VM-Enter KVM services local TLB flusCVE-2026-89930 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67Critical 9.3

    In the Linux kernel, the following vulnerability has been resolved: KVM: nVMX: Service local TLB flushes on failed nested VM-Enter KVM services local TLB flushes on "full" nested VM-Exits (through __nested_vmx_vmexit()), but not if a nested VM-Enter fails (e.g. due to failed VMCS checks in nested_vmx_enter_non_root_mode()). However, it is possible that KVM had queued TLB flushes that need to be performed, even if the nested VM-Enter was not successful. For example, if VPID is disabled for L2 (via nested_vmx_transition_tlb_flush(), or if via the MSR load lists, as the SDM says: If any MSR is being loaded in such a way that would architecturally require a TLB flush, the TLBs are updated so that, after VM entry, the logical processor will not use any translations that were cached before the transition. The SDM is unclear about when the TLB flush should occur, and whether or not a failed VM entry would flush the TLB, so it is safer to always do the TLB flush in this case. More concretely, KVM also updates the last VPID L1 used for L2 in nested_vmx_transition_tlb_flush() (i.e. last_vpid), even if the VM entry ultimately fails. With the current code, KVM could miss a TLB fl

    Product
    Linux
    What to do
    Apply the vendor’s update. The NVD record links to the advisory.
  • Sep 16, 2026In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: Correctly handle end of VA space TLBI invalidation Our TLB invalidation by VA CVE-2026-89918 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67Critical 9.3

    In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: Correctly handle end of VA space TLBI invalidation Our TLB invalidation by VA code is based on comparing two ranges, one defined by the TLB, and one defined by the TLBI instruction. Each range is defined by a start and a size. However, the way the comparison is done doesn't account for address rollover, as it compares an address with (base + size). This works nicely until this expression represent the last page/block in the TTBR1 VA space, as the result is a big fat 0. And a failed TLB invalidation. Rewrite the comparison in a way that is immune to the address rollover (making the end address inclusive instead of exclusive), and move this into a common helper that is used by both VA and IPA invalidations, as suggested by Hyunwoo Kim (although the IPA version didn't suffer from this particular problem, obviously).

    Product
    Linux
    What to do
    Apply the vendor’s update. The NVD record links to the advisory.
  • Sep 16, 2026In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: Make VNCR invalidation participate in MMU invalidation retry A VNCR TLB invaliCVE-2026-89916 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67Critical 9.3

    In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: Make VNCR invalidation participate in MMU invalidation retry A VNCR TLB invalidation can occur on one vcpu while another vcpu is faulting in this same page. Without correctly handling this, we can end up with the following scenario: - vcpu A walks the PTs to translate VNCR - before vcpu A is able to grab the MMU lock to insert the TLB, vcpu B updates the S1 PTs with an invalid entry, and issues a TLBI S1E2 for this VA - vcpu A inserts the TLB for something that is now invalid This isn't a new problem, and we manage S2 by having the MMU notifier to bump up mmu_invalidate_seq on invalidation so that the fault can be replayed. We can perform something similar here, and extend invalidate_vncr_va() to update the same counter, clearly indicating that the context has changed under our feet. This is safe as the invalidation always happen while holding the MMU lock for write, and that we sample the sequence number before walking S1.

    Product
    Linux
    What to do
    Apply the vendor’s update. The NVD record links to the advisory.
  • Sep 16, 2026In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: Remove VM-wide VNCR mapping counter The global VNCR mapping counter is used toCVE-2026-89915 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67Critical 9.3

    In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: Remove VM-wide VNCR mapping counter The global VNCR mapping counter is used to decide whether an L1 provided VNCR page is mapped in L0 on any CPU at the point of dealing with a TLB invalidation. It is incremented when a mapping is made in the fixmap, and decremented when unmapped. As it turns out, this tracking has several flaws: - we are trying to invalidate TLBs, and the mapping is only an opportunistic consequence of the TLB. Checking this counter to decide whether a TLB needs to be invalidated may result in missed invalidations. - an L1 vcpu invalidating its own TLB (a very likely case) will not succeed in invalidating the VNCR pseudo TLB because that page is not mapped in L0 at this stage. Given that this tracking fails at delivering the minimum guarantees that are required and is only a performance optimisation, remove it completely.

    Product
    Linux
    What to do
    Apply the vendor’s update. The NVD record links to the advisory.
  • Sep 16, 2026In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: Sign-extend VA for range-based TLBI invalidation When the decode_range_tlbi() CVE-2026-89914 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67Critical 9.3

    In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: Sign-extend VA for range-based TLBI invalidation When the decode_range_tlbi() helper was moved to be used for S1 TLBIs, the required sign extension was omitted. Add it. As a result, special care must be taken to not overflow PA bits when this is used for S2 invalidation.

    Product
    Linux
    What to do
    Apply the vendor’s update. The NVD record links to the advisory.
  • Sep 16, 2026In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Hold qpair lock when sending NVMe LS reject qla_nvme_ls_reject_iocb() allocCVE-2026-89857 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67Critical 9.8

    In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Hold qpair lock when sending NVMe LS reject qla_nvme_ls_reject_iocb() allocates from and advances the request ring through __qla2x00_alloc_iocbs() (which assumes the hardware_lock is held) and qla2x00_start_iocbs() (which advances the ring and rings the request-in doorbell), but takes no lock itself. Two of its callers invoke it without the producer lock held: - qla_nvme_xmt_ls_rsp(), the NVMe-FC .xmt_ls_rsp transport callback, on its error path, and - qla2xxx_process_purls_pkt(), run from the purex work/DPC context. Both use ha->base_qpair, whose qp_lock_ptr is hardware_lock, so they can run concurrently with normal I/O submission on the base ring and corrupt the ring producer state, leading to duplicated or dropped commands. The third caller, qla2xxx_process_purls_iocb(), runs inside qla24xx_process_response_queue() with the qpair lock already held and is safe; that is also why the lock cannot be taken inside the helper itself (it would recursively re-acquire hardware_lock on the response path). Take qp_lock_ptr around the two unlocked callers and document the helper as caller-locked. Bo

    Product
    Linux
    What to do
    Apply the vendor’s update. The NVD record links to the advisory.
  • Sep 16, 2026In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Avoid double completion in async IOCB timeout qla2x00_async_iocb_timeout() CVE-2026-89847 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67Critical 9.8

    In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Avoid double completion in async IOCB timeout qla2x00_async_iocb_timeout() tries to abort a timed-out async IOCB. When qla24xx_async_abort_cmd() fails, both the SRB_LOGIN_CMD path and the SRB_CTRL_VP/default path scan outstanding_cmds[] for the SRB and then call sp->done(sp, QLA_FUNCTION_TIMEOUT) unconditionally, without checking whether the SRB was actually found and removed. If the response ISR completes the same handle first, it removes the SRB under qp_lock_ptr and runs sp->done() -> complete(sp->comp). The submitter qla24xx_control_vp() wakes from wait_for_completion(), clears sp->comp, drops its reference and returns, reclaiming the on-stack completion. The timer reference keeps the SRB alive across the timeout handler, but not the submitter's stack. The timeout then issues a second sp->done() -> qla_ctrlvp_sp_done(), which evaluates "if (sp->comp) complete(sp->comp)"; with the pointer loaded before the submitter's NULL store, complete() writes into the freed stack frame, a use-after-free. Track whether this path removed the SRB from outstanding_cmds and only call sp->done() when it did, so

    Product
    Linux
    What to do
    Apply the vendor’s update. The NVD record links to the advisory.
  • Sep 16, 2026In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Bound rsp_info_len to avoid OOB sense-data read In qla2x00_status_entry(), CVE-2026-89846 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67Critical 9.1

    In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Bound rsp_info_len to avoid OOB sense-data read In qla2x00_status_entry(), the FWI2 status path advances sense_data and shrinks par_sense_len by rsp_info_len: if (IS_FWI2_CAPABLE(ha)) { sense_data += rsp_info_len; par_sense_len -= rsp_info_len; } rsp_info_len is a 32-bit value taken directly from the target's FCP response (sf.rsp_data_len), while par_sense_len is the IOCB data area size (28 bytes for 24xx, 60 bytes for 29xx). A hostile or buggy target reporting an rsp_info_len larger than par_sense_len makes the unsigned subtraction underflow to a huge value and advances sense_data out of bounds. The underflowed par_sense_len then defeats the cap in qla2x00_handle_sense(): if (sense_len > par_sense_len) sense_len = par_sense_len; memcpy(cp->sense_buffer, sense_data, sense_len); so the memcpy reads up to SCSI_SENSE_BUFFERSIZE bytes from the out-of-bounds sense_data pointer, leaking adjacent response-ring/heap memory into the command's sense buffer. Clamp rsp_info_len to par_sense_len before the subtraction so par_sense_len can never underflow and sense_data stays within the IOCB data

    Product
    Linux
    What to do
    Apply the vendor’s update. The NVD record links to the advisory.
  • Sep 16, 2026Apache Airflow Keycloak provider: the unauthenticated token endpoint accepts a client-credentials grant for any confidential client registered in the Keycloak rCVE-2026-76187 · Websites & servers · Apache Software Foundation · reported by security@apache.orgCritical 9.8

    Apache Airflow Keycloak provider: the unauthenticated token endpoint accepts a client-credentials grant for any confidential client registered in the Keycloak realm, not only the client configured for Airflow. No allowlist restricts which client ids may authenticate, so the credentials of an unrelated application that happens to share the realm are valid Airflow login credentials, and Airflow mints a signed session token for that application's service account. The endpoint also answers unauthenticated credential guesses against Keycloak under Airflow's identity. Affects deployments using the Keycloak auth manager whose realm is shared with other confidential clients. The attacker needs valid credentials for any one of those clients, not for Airflow. Resource authorization is still evaluated per subject, so the access gained is whatever that service account holds, plus any endpoint gated only on being authenticated. Users of apache-airflow-providers-keycloak are recommended to upgrade to version 0.10.0 or later, which accepts only the configured client on that grant.

    Product
    Apache Airflow Keycloak provider
    What to do
    Apply the vendor’s update. The NVD record links to the advisory.
  • Sep 16, 2026Apache Airflow Keycloak provider: from Airflow 3.3 the Keycloak auth manager takes a user's identity from the signed Airflow session token but takes the KeycloaCVE-2026-76186 · Websites & servers · Apache Software Foundation · reported by security@apache.orgCritical 9.1

    Apache Airflow Keycloak provider: from Airflow 3.3 the Keycloak auth manager takes a user's identity from the signed Airflow session token but takes the Keycloak access and refresh tokens used for every authorization decision from separate, unauthenticated cookies, and never checks that the two describe the same subject. A user who holds any valid Airflow login of their own, together with another subject's Keycloak access or refresh token obtained out of band, can pair the two: Airflow then authorizes requests with the foreign token's privileges while the session identity, audit log and cache keys continue to name the attacker's own account. The refresh path re-issues an Airflow session token for the original identity carrying the foreign tokens, so the mismatched pairing survives across sessions. Affects deployments running Airflow 3.3 or later with the Keycloak auth manager. Earlier versions carried the Keycloak tokens inside the signed session token, so the binding existed and was lost when they moved into separate cookies. Users of apache-airflow-providers-keycloak are recommended to upgrade to version 0.10.0 or later, which binds the cookie-supplied tokens to the session ide

    Product
    Apache Airflow Keycloak provider
    What to do
    Apply the vendor’s update. The NVD record links to the advisory.
  • Sep 16, 2026An unauthenticated P4Runtime (Programming Protocol-Independent Packet Processors Runtime) client can achieve arbitrary code execution under certain conditions oCVE-2026-73453 · Other software · Arista Networks · reported by psirt@arista.comCritical 9.5

    An unauthenticated P4Runtime (Programming Protocol-Independent Packet Processors Runtime) client can achieve arbitrary code execution under certain conditions on affected platforms running Arista EOS configured with P4Runtime. P4Runtime is disabled by default in Arista EOS. By crafting a malicious packet during the initiation of a P4Runtime session, an attacker can obtain complete administrative control over the compromised switch. This issue was discovered internally by Arista, and the company is not aware of any malicious exploitation of this vulnerability in customer networks.

    Product
    EOS
    What to do
    Apply the vendor’s update. The NVD record links to the advisory.
  • Sep 16, 2026In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix tree connection use-after-free in smb2_tree_connect() ksmbd_tree_conn_connect()CVE-2026-89788 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67Critical 9.8

    In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix tree connection use-after-free in smb2_tree_connect() ksmbd_tree_conn_connect() publishes a new tree connection in sess->tree_conns with a single reference and returns its pointer to smb2_tree_connect(). The handler continues to initialize the object and build the response after publication. A concurrent session logoff can erase the connection and drop that reference, freeing the object while the handler still uses it. BUG: KASAN: slab-use-after-free in smb2_tree_connect+0xe3d/0xf90 smb2_tree_connect (fs/smb/server/smb2pdu.c:2872) handle_ksmbd_work process_one_work worker_thread kthread After xa_store() succeeds, take a second reference before releasing tree_conns_lock. The original reference belongs to the xarray entry and the second belongs to the creating smb2_tree_connect() handler. Keep the references balanced in every path: - On normal exit or an error after publication, smb2_tree_connect() drops its creator reference. Error cleanup also calls ksmbd_tree_conn_disconnect(), which drops the xarray reference only if it removes the exact entry. - SMB2 TREE_DISCONNECT uses the same

    Product
    Linux
    What to do
    Apply the vendor’s update. The NVD record links to the advisory.
  • Sep 16, 2026In the Linux kernel, the following vulnerability has been resolved: ext4: fix out-of-bounds read in ext4_read_inline_dir() ext4_read_inline_dir() can read a dCVE-2026-89786 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67Critical 9.1

    In the Linux kernel, the following vulnerability has been resolved: ext4: fix out-of-bounds read in ext4_read_inline_dir() ext4_read_inline_dir() can read a dirent header past the end of its inline buffer, triggering a slab-out-of-bounds read during getdents64(): BUG: KASAN: slab-out-of-bounds in __ext4_check_dir_entry Read of size 2 at addr ffff88800f3dd23c by task exploit/148 ... __ext4_check_dir_entry ext4_read_inline_dir iterate_dir The dirent payload lives in a buffer of exactly inline_size bytes: dir_buf = kmalloc(inline_size, GFP_NOFS); but iteration runs in a position space extra_offset bytes larger (extra_size = extra_offset + inline_size) so the synthetic "." and ".." land at their block-dir offsets. A dirent is formed at "dir_buf + pos - extra_offset", yet the ext4_check_dir_entry() length argument uses the larger extra_size. A position whose dirent header would extend past extra_size is therefore accepted, and the rescan loop's rec_len probe and ext4_check_dir_entry() dereference de->rec_len before the entry is rejected. Reject a position whose minimum-size dirent header would not fit within extra_size before forming de, in both the rescan and ma

    Product
    Linux
    What to do
    Apply the vendor’s update. The NVD record links to the advisory.
  • Sep 16, 2026In the Linux kernel, the following vulnerability has been resolved: xfrm6: fix out-of-bounds write in xfrm6_input_addr() when secpath is full The depth check CVE-2026-89783 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67Critical 9.8

    In the Linux kernel, the following vulnerability has been resolved: xfrm6: fix out-of-bounds write in xfrm6_input_addr() when secpath is full The depth check in xfrm6_input_addr() is off by one: if (1 + sp->len == XFRM_MAX_DEPTH) goto drop; ... sp->xvec[sp->len++] = x; xfrm_input() can leave sp->len == XFRM_MAX_DEPTH, and the transport-mode receive path re-enters IPv6 input via xfrm_trans_reinject() with that secpath preserved. If the inner packet carries a destination-options HAO option or a type-2 routing header, xfrm6_input_addr() is called with sp->len == XFRM_MAX_DEPTH; the check (1 + 6 == 6) is false, so sp->xvec[sp->len++] writes one slot past the 6-element xvec[]. The write stays within the sec_path allocation (invisible to KASAN); UBSAN_BOUNDS flags it and panics under panic_on_warn. Use "sp->len >= XFRM_MAX_DEPTH", matching xfrm_input(). This also restores one chain level the old check rejected at sp->len == 5. UBSAN: array-index-out-of-bounds in net/ipv6/xfrm6_input.c:309:10 index 6 is out of range for type 'xfrm_state *[6]'

    Product
    Linux
    What to do
    Apply the vendor’s update. The NVD record links to the advisory.
  • Sep 16, 2026In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: validate ef->size covers the record's name and value When an EA record has a nonCVE-2026-89779 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67Critical 9.1

    In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: validate ef->size covers the record's name and value When an EA record has a non-zero ef->size, ntfs_read_ea() only checks that the record fits in the remaining buffer (ea_size > bytes), not that ef->size is large enough to hold the record's own name_len + 1 + elength. A crafted image can pass validation with, e.g., ef->size = 24 but elength = 0xffff. ntfs_get_ea() then trusts elength and copies it out of the undersized record, reading past the kmalloc(info->size) allocation and leaking heap memory to userspace via getxattr(): BUG: KASAN: slab-out-of-bounds in ntfs_get_ea (fs/ntfs3/xattr.c:302) Read of size 65535 at addr ffff888100794550 by task exploit __asan_memcpy (mm/kasan/shadow.c:105) ntfs_get_ea (fs/ntfs3/xattr.c:302) ntfs_getxattr (fs/ntfs3/xattr.c:848) __vfs_getxattr (fs/xattr.c:441) vfs_getxattr (fs/xattr.c:474) do_getxattr (fs/xattr.c:800) path_getxattrat (fs/xattr.c:868) do_syscall_64 (arch/x86/entry/syscall_64.c:94) The buggy address is located 80 bytes inside of allocated 84-byte region in cache kmalloc-96 Compute the size the record needs and require ef->size to c

    Product
    Linux
    What to do
    Apply the vendor’s update. The NVD record links to the advisory.
  • Sep 16, 2026In the Linux kernel, the following vulnerability has been resolved: isofs: fix out-of-bounds page array access on empty zisofs block zisofs_uncompress_block()CVE-2026-89778 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67Critical 9.8

    In the Linux kernel, the following vulnerability has been resolved: isofs: fix out-of-bounds page array access on empty zisofs block zisofs_uncompress_block()'s empty-block fast path returns pcount << PAGE_SHIFT, ignoring the incoming poffset, unlike the decompression path which returns bytes produced relative to poffset. zisofs_fill_pages() uses that return to advance its page cursor, so when the zisofs block size is below PAGE_SIZE and a sub-page block leaves poffset partway into a page, a following empty block over-counts and advances pages[] one element past its end, after which "if (poffset && *pages)" reads pages[1] out of bounds. rock.c only rejects a block-size shift > 17, so a crafted "ZF" Rock Ridge record can set it below PAGE_SHIFT; the bug is reached by an ordinary read() of a compressed file on such a mounted ISO9660 image. Return the byte count relative to poffset and zero only [poffset, PAGE_SIZE) of the first page, matching the decompression path. The page-aligned case (poffset == 0) is unaffected. BUG: KASAN: slab-out-of-bounds in zisofs_read_folio (fs/isofs/compress.c:290) Read of size 8 at addr ffff88800f5eac48 by task exploit/142 zisofs_read_folio (

    Product
    Linux
    What to do
    Apply the vendor’s update. The NVD record links to the advisory.
  • Sep 16, 2026In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: Handle negative S1 walk levels in VNCR TLB size evaluation Computing the effecCVE-2026-89775 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67Critical 9.3

    In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: Handle negative S1 walk levels in VNCR TLB size evaluation Computing the effects of a TLB invalidation involves looking at the size of the mapping cached by the TLB. For S1 mappings such as VNCR, this is deducted from the combination of the base granule size and the mapping level. However, this implies that the S1 MMU is *on*. When the MMU is off, we indicate this with the level being set to a "creative" value of -127 (S1_MMU_DISABLED). This ends-up being misinterpreted by pgshift_level_to_ttl() as it doesn't handle negative levels at all (the level is immediately cast to a u8 and only the bottom two bits considered), leading to an invalidation size of 0. Not helpful. Tidy-up pgshift_level_to_ttl() to handle these negative levels, and ttl_to_size() to always return SZ_1G when no valid TTL is present. This allows the removal of open-coded checks for similar situations. Note that the check for a negative value not explicitely checking for S1_MMU_DISABLED is deliberate, so that actual negative levels introduced with LVA2 and D128 can take the same path if we ever support them.

    Product
    Linux
    What to do
    Apply the vendor’s update. The NVD record links to the advisory.
  • Sep 16, 2026Apache Airflow FAB provider: changing a user's password through the Admin user-edit PATCH endpoint does not invalidate that user's existing database-backed sessCVE-2026-86462 · Websites & servers · Apache Software Foundation · reported by security@apache.orgCritical 9.1

    Apache Airflow FAB provider: changing a user's password through the Admin user-edit PATCH endpoint does not invalidate that user's existing database-backed sessions. An attacker who already holds a copy of the victim's session cookie keeps full access as that user after the password change, so the password reset does not evict them. Affects deployments using the FAB auth manager with database-backed sessions; an administrator (or the user themselves) performing a routine password change is the trigger, and no attacker interaction with the endpoint is needed. This is a second, independent route to the outcome addressed by CVE-2026-82311, which corrected an identifier comparison in the session-invalidation helper. That fix does not repair this endpoint, because the PATCH path never calls the helper at all. Deployments that applied the CVE-2026-82311 fix must also upgrade for this one. Users of apache-airflow-providers-fab are recommended to upgrade to version 3.9.0 or later, which fixes the issue.

    Product
    Apache Airflow FAB provider
    What to do
    Apply the vendor’s update. The NVD record links to the advisory.
  • Sep 16, 2026Apache Airflow FAB provider: resetting a user's password does not delete that user's existing database-backed sessions, despite documented behaviour that it doeCVE-2026-82311 · Websites & servers · Apache Software Foundation · reported by security@apache.orgCritical 9.8

    Apache Airflow FAB provider: resetting a user's password does not delete that user's existing database-backed sessions, despite documented behaviour that it does. The cleanup compares the string identifier Flask-Login stores in the session against the user's integer database identifier, so the comparison never matches and no session is removed. An attacker who already holds a copy of the victim's session cookie keeps access as that user after the password change, so the reset does not evict them. Affects deployments using the FAB auth manager with `[fab] session_backend=database`. The trigger is an administrator (or the user) running the supported password-reset command as a containment action after a session cookie has been compromised; the secure-cookie backend is out of scope, as it documents that it cannot centrally delete sessions. apache-airflow-providers-fab 3.9.0 also fixes CVE-2026-86462, a second, independent route to the same outcome via the Admin user-edit endpoint; a single upgrade closes both. Users of apache-airflow-providers-fab are recommended to upgrade to version 3.9.0 or later, which compares the identifiers consistently.

    Product
    Apache Airflow FAB provider
    What to do
    Apply the vendor’s update. The NVD record links to the advisory.
  • Sep 16, 2026In NLnet Labs Unbound up to and including 1.26.0, a vulnerability was found in the DNSSEC validator that enables denial of service and possible remote code execCVE-2026-81642 · Other software · NLnet Labs · reported by sep@nlnetlabs.nlCritical 9.1

    In NLnet Labs Unbound up to and including 1.26.0, a vulnerability was found in the DNSSEC validator that enables denial of service and possible remote code execution as a result of digesting DNSKEYs. A DNSKEY with an owner compression pointer to its own RDATA can overflow the digest buffer. Remote code execution is possible through attacker controlled data. An adversary can exploit the vulnerability by controlling a malicious zone and querying a vulnerable Unbound.

    Product
    Unbound
    What to do
    Apply the vendor’s update. The NVD record links to the advisory.
  • Sep 16, 2026On affected EOS platforms with AAA-based gRPC authorization enabled for OpenConfig, gRPC requests of an authenticated user to OpenConfig may use the wrong priviCVE-2026-73461 · Other software · Arista Networks · reported by psirt@arista.comCritical 9.4

    On affected EOS platforms with AAA-based gRPC authorization enabled for OpenConfig, gRPC requests of an authenticated user to OpenConfig may use the wrong privilege level, resulting in an authorization using the wrong AAA method list. This does not impact non-gRPC OpenConfig requests such as NETCONF.

    Product
    EOS
    What to do
    Apply the vendor’s update. The NVD record links to the advisory.
  • Sep 16, 2026An unauthenticated remote attacker can upload a malicious IODD file that places and executes a shell script with root privileges.CVE-2026-27565 · Other software · Pepperl+Fuchs · reported by info@cert.vde.comCritical 9.8

    An unauthenticated remote attacker can upload a malicious IODD file that places and executes a shell script with root privileges. The shell script remains active even after a reboot.

    Product
    ICE2-8IOL1-G65L-V1D
    What to do
    Apply the vendor’s update. The NVD record links to the advisory.
  • Sep 16, 2026An unauthenticated remote attacker can exploit an authentication bypass in the _account_log function to log in as an admin, even when accounts are properly confCVE-2026-27546 · Other software · Pepperl+Fuchs · reported by info@cert.vde.comCritical 9.8

    An unauthenticated remote attacker can exploit an authentication bypass in the _account_log function to log in as an admin, even when accounts are properly configured.

    Product
    ICE2-8IOL1-G65L-V1D
    What to do
    Apply the vendor’s update. The NVD record links to the advisory.
  • Sep 16, 2026A privileged attacker can exploit certain operation to execute arbitrary commands with root privileges, leading to full device compromise.CVE-2026-73447 · Other software · Arista Networks · reported by psirt@arista.comCritical 9.4

    A privileged attacker can exploit certain operation to execute arbitrary commands with root privileges, leading to full device compromise. An authenticated user can exploit gRPC Network Security Interface (gNSI) Certz service on Arista EOS-based products to escalate privileges and execute arbitrary OS commands via a crafted Certz Rotate request. The Bootz service is also affected.

    Product
    EOS
    What to do
    Apply the vendor’s update. The NVD record links to the advisory.
  • Sep 16, 2026TrueBooker – Appointment Booking and Scheduler System: Authorization bypassCVE-2026-14349 · WordPress plugins & themes · reported by WordfenceCritical 9.8

    The TrueBooker – Appointment Booking and Scheduler System plugin for WordPress is vulnerable to authorization bypass in all versions up to, and including, 1.2.3. This is due to the plugin not properly verifying that a user is authorized to perform an action. This makes it possible for unauthenticated attackers to modify the email address of arbitrary user accounts, including administrators, which can be leveraged to reset the account's password and gain access to it.

    Product
    TrueBooker – Appointment Booking and Scheduler System
    Affected
    up to 1.2.3
    What to do
    Affects up to 1.2.3. Update TrueBooker – Appointment Booking and Scheduler System to the newest version and check its changelog mentions this fix; if there isn’t one yet, deactivate it until there is.
  • Sep 16, 2026JetFormBuilder — Dynamic Blocks Form Builder: Privilege EscalationCVE-2026-12793 · WordPress plugins & themes · reported by WordfenceCritical 9.8

    The JetFormBuilder — Dynamic Blocks Form Builder plugin for WordPress is vulnerable to Privilege Escalation in all versions up to, and including, 3.6.2. This is due to the plugin not validating that a submitted form ID belongs to a JetFormBuilder form before parsing the referenced post's content as form schema and executing an Advanced Validation server-side callback. This makes it possible for unauthenticated attackers to create a new administrator-level user account.

    Product
    JetFormBuilder — Dynamic Blocks Form Builder
    Affected
    up to 3.6.2
    What to do
    Affects up to 3.6.2. Update JetFormBuilder — Dynamic Blocks Form Builder to the newest version and check its changelog mentions this fix; if there isn’t one yet, deactivate it until there is.
  • Sep 15, 2026Under certain conditions a valid SAML IdP response may be used to impersonate another Secret Server user.CVE-2026-15640 · Other software · Delinea · reported by 1443cd92-d354-46d2-9290-d812316ca43aCritical 9.5

    Under certain conditions a valid SAML IdP response may be used to impersonate another Secret Server user.

    Product
    Secret Server (On-Prem)
    What to do
    Apply the vendor’s update. The NVD record links to the advisory.
  • Sep 15, 2026An attacker can craft a malicious link that, if used by a legitimate user, may cause the user's browser to run JavaScript supplied by the attacker.CVE-2026-15639 · Other software · Delinea · reported by 1443cd92-d354-46d2-9290-d812316ca43aCritical 9.3

    An attacker can craft a malicious link that, if used by a legitimate user, may cause the user's browser to run JavaScript supplied by the attacker.

    Product
    Secret Server (On-Prem)
    What to do
    Apply the vendor’s update. The NVD record links to the advisory.
  • Sep 15, 2026An unauthenticated user with access to Secret Server could leverage a padding oracle to decrypt or encrypt data using one of the server's cryptographic keys.CVE-2026-15638 · Other software · Delinea · reported by 1443cd92-d354-46d2-9290-d812316ca43aCritical 9.1

    An unauthenticated user with access to Secret Server could leverage a padding oracle to decrypt or encrypt data using one of the server's cryptographic keys. The key itself is not exposed.

    Product
    Secret Server (On-Prem)
    What to do
    Apply the vendor’s update. The NVD record links to the advisory.

Where this comes from: the exploited list is CISA’s Known Exploited Vulnerabilities catalog. Everything else is the whole National Vulnerability Database, where each record is published by the team that found the bug (Wordfence, Patchstack, WPScan, the vendors themselves and others); we show who. Exploit odds are FIRST’s EPSS, updated daily. Titles and categories are ours, so check the linked record before acting on a detail. For a write-up of the big ones, see our advisories. Every vendor, and every WordPress plugin and theme with a recorded flaw, also has its own page. All of it is free to reuse as JSON, CSV or RSS.

Weekly security brief

The flaws that hit local websites, every Friday.

One short email: what got exploited this week, which WordPress plugins broke, and what to check. Unsubscribe in one click.

Get in touch

Tell us what you're building.

A website, your marketing, a security check, an app, or the thing you've been running out of a spreadsheet for three years. A few lines is plenty.

01The person who'll do the work writes back
02A short call, then a written plan with the price
03Nothing starts until you say yes
04Hacked or down right now? Call, and we pick up the same day
843-331-6339

Not ready to talk yet? Run the free website check and see what Google sees.

What do you need?
Build
Grow
Protect
Urgent

No newsletter, no sales sequence. Just a reply.