CPU exhaustion denial of service in Apache CXF's FIQL query parser allows remote attackers to degrade or stall a server by submitting a long search expression containing no recognizable operator, which drives the parser's operator-search logic into excessive combinatorial matching and burns CPU on a request-handling thread. Affected are CXF 3.6.x, 4.1.x and 4.2.x deployments that expose FIQL-based search/filter endpoints; the assessed CVSS 3.1 vector is AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H (base 7.5), meaning availability impact only, with confidentiality and integrity unaffected. No public exploit code and no confirmed active exploitation were identified at time of analysis, and the vendor-released fixes - 4.2.4, 4.1.9 and 3.6.13 - neutralize the long-input vector by capping FIQL expressions at 4 KiB by default while still permitting normal queries.
Dell Secure Connect Gateway (SCG) Policy Manager before 5.34.00.16 contains an improper check for unusual or exceptional conditions, allowing an authenticated, high-privileged remote attacker to tamper with information and bypass protection mechanisms. The flaw requires administrative-level access (PR:H), confining exploitation to malicious or compromised privileged operators; no public exploit code or active exploitation has been identified at time of analysis. Impact is limited to partial integrity and availability losses, with no confidentiality exposure, making this a low-priority issue despite the network attack vector.
Heap memory disclosure and application crashes affect Affinity by Canva before version 3.3.1 (October 2026 release), where insufficient bounds checking on arrays of strings inside Affinity document files triggers a heap buffer over-read (CWE-126). Exploitation requires unauthenticated but local delivery: a victim must be socially engineered into opening a crafted Affinity document with the vulnerable application, which is consistent with the assessed vector CVSS:3.1/AV:L/AC:H/PR:N/UI:R/C:L/I:N/A:L and a low base score of 3.6. Impact is limited - any leaked heap contents are non-deterministic and bounded by heap layout (AC:H), and the most likely practical outcome is a client-side crash rather than reliable data theft; no public exploit identified at time of analysis.
Heap buffer over-read in Affinity by Canva versions before 3.3.1 (October 2026 release) allows an attacker to disclose small amounts of adjacent heap memory or crash the application when a user opens a specially crafted Affinity document containing a malformed, incomplete UTF-8 character sequence in its text. The flaw sits in the local document text parser and is rated low severity (CVSS 3.6, AV:L/AC:H/PR:N/UI:R/S:U/C:L/I:N/A:L): exploitation is local, requires the victim to open the malicious file, and is high-complexity because meaningful disclosure depends on heap layout, with integrity impact absent and only limited confidentiality/availability effects. No public exploit code or confirmed active exploitation was identified at time of analysis, and the vendor has released a fixed version (3.3.1) via its trust center advisory.
Out-of-bounds heap read in Affinity by Canva for macOS before 3.3.1 (the October 2026 release) allows a crafted Affinity document to leak adjacent heap memory - including memory addresses - into the thumbnail or preview image that macOS QuickLook renders in Finder. Affected are users of the pre-3.3.1 macOS app whose QuickLook preview generator is registered with the OS; the victim only needs to select or browse to the malicious file in Finder, as automatic preview rendering triggers the bug without opening the document in the app. The issue is local-only with a high attack complexity (favorable heap layout required) and no authentication requirement (PR:N); it is not confirmed as actively exploited (no CISA KEV listing), no public exploit code was identified at time of analysis, and no EPSS score was supplied - consistent with its low assessed severity (CVSS 3.6) and its practical value as an information-leak primitive to chain with a separate vulnerability rather than a standalone compromise.
Opening a malformed Affinity document in Affinity by Canva versions before 3.3.1 (the October 2026 release) causes an out-of-bounds pointer dereference during file parsing, which crashes the desktop application. The attack requires user interaction (UI:R) to open the crafted file and a local vector (AV:L), so an attacker must rely on social engineering or a trusted-looking shared asset rather than any remote or automatic trigger. Impact is limited to availability (A:L) with no code execution, data disclosure, or integrity loss described, and no public exploit has been identified at time of analysis.
An out-of-bounds heap read in Affinity by Canva for macOS (before 3.3.1) lets a crafted Affinity document leak adjacent heap memory into the QuickLook thumbnail and preview images rendered by Finder, or crash the thumbnail/preview extension. The attack is local - the malicious file must already reside on the target Mac - and requires the victim to browse to or preview the file in Finder, which triggers the vulnerable code path; the disclosed bytes are non-deterministic, so an attacker cannot select what is exposed. No public exploit code or confirmed active exploitation has been identified at time of analysis, and the assessed severity is low (CVSS 3.1 base 2.9).
Read-only authenticated users of MongoDB Ops Manager can retrieve daily host monitoring records belonging to projects they do not have access to, exposing deployment metadata such as host and configuration details, when they already know the exact identifier of the target record. Exploitation requires a valid Ops Manager account with at least a read-only role on some project plus knowledge of a record identifier from a different project, which sharply limits practical exposure; impact is confined to low-severity information disclosure with no write or availability effect. There is no public exploit identified at time of analysis and the issue is not confirmed actively exploited (CISA KEV), consistent with the vendor-assigned CVSS 4.0 score of 2.3 and our independent CVSS 3.1 assessment of AV:N/AC:H/PR:L/UI:N/S:U/C:L/I:N/A:N.
Local users holding an unprivileged account in any zone on an illumos-based host can send an unauthorized ZSD_CMD_NEW_ZONE request to the zonestatd door, forcing the daemon to re-create its door file in an arbitrary zone so that new zonestat requests in that zone can fail while the file is replaced, and using the command's response timing as an oracle for whether a given zone ID is currently running. The root cause is a missing authorization check (CWE-862) in zsd_server() in usr/src/cmd/zonestat/zonestatd/zonestatd.c, a gap that has existed since illumos-gate commit efd4c9b6 in 2010 and affects illumos-gate and OmniOS builds prior to illumos-gate commit 865b58d2; a vendor fix is available, and no public exploit code was identified at time of analysis. Impact is confined to transient disruption of zone statistics collection plus a zone-existence oracle - no privilege gain, persistence, or data theft - so this is a low-priority issue for single-tenant or single-admin hosts and only a modest concern in multi-tenant deployments where untrusted users hold zone-local accounts.
Local unprivileged users on illumos distributions can silently alter the persistent IP multipathing (IPMP) configuration because the ipmgmtd door service fails to require the solaris.network.interface.config authorization for the IPMGMT_CMD_IPMP_UPDATE command. Rated only CVSS 4.0 1.9 (independent assessment CVSS 3.1 7.3-adjacent vector AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:L), the issue requires an existing local account on an illumos-gate derivative such as OmniOS built before commit e8d3efa1, and the modified state only takes effect when the stored ipadm configuration is next applied (typically at reboot), so impact is delayed and limited to integrity and availability of network configuration rather than immediate disruption. No CISA KEV listing is present; the CVSS 4.0 vector's E:P metric indicates proof-of-concept-level exploit maturity, meaning publicly available exploit code exists, and the flaw has been present since illumos-gate commit a73be61a in 2021.
In the Linux kernel, the following vulnerability has been resolved: net/sched: reject IDR error pointers when deleting actions tcf_action_delete() drops the reference held by its lookup before calling tcf_idr_delete_index() with the saved action index. An unlocked classifier can remove that action and reserve the same IDR slot with ERR_PTR(-EBUSY) in between. tcf_idr_delete_index() only checks the lookup result for NULL. It therefore treats the reservation as a tc_action and dereferences tcfa_bindcnt. A hardware execution breakpoint was used to schedule the interleaving without changing the kernel source. KASAN reported this decoded trace: BUG: KASAN: null-ptr-deref in tca_action_gd+0x5b9/0x1010 Read of size 4 at addr 0000000000000010 by task poc/150 Oops: general protection fault, probably for non-canonical address 0xdffffc0000000002 RIP: tca_action_gd+0x5c0/0x1010: arch_atomic_read at arch/x86/include/asm/atomic.h:23 raw_atomic_read at include/linux/atomic/atomic-arch-fallback.h:457 atomic_read at include/linux/atomic/atomic-instrumented.h:33 tcf_idr_delete_index at net/sched/act_api.c:766 tcf_action_delete at net/sched/act_api.c:1859 tcf_del_notify at net/sched/act_api.c:2014 tca_action_gd at net/sched/act_api.c:2064 R13: 0000000000000010 R15: fffffffffffffff0 Kernel panic - not syncing: Fatal exception R15 contains ERR_PTR(-EBUSY), and adding the tcfa_bindcnt offset produces the address in R13. With the guard applied, the same reproducer returned -ENOENT without a KASAN report or panic. Treat error pointers as absent and return -ENOENT.
In the Linux kernel, the following vulnerability has been resolved: netfilter: ip6t_rpfilter: reject routes without inet6_dev ip6_route_lookup() can return an error-free route whose rt6i_idev is NULL. Lowering an external nexthop device's MTU below IPV6_MIN_MTU tears down its inet6_dev while fib6_ifdown() leaves routes using nexthop objects in the FIB. An unprivileged user can construct this state with rtnetlink in a private user and network namespace, then trigger a NULL dereference through an IPv6 rpfilter lookup: Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000 KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] RIP: rpfilter_mt (net/ipv6/netfilter/ip6t_rpfilter.c:75) Call Trace: ip6t_do_table (net/ipv6/netfilter/ip6_tables.c:316) nf_hook_slow (net/netfilter/core.c:619) ipv6_rcv (net/ipv6/ip6_input.c:351) __netif_receive_skb_one_core (net/core/dev.c:6216) process_backlog (net/core/dev.c:6680) __napi_poll (net/core/dev.c:7739) net_rx_action (net/core/dev.c:7959) handle_softirqs (kernel/softirq.c:622) do_softirq.part.0 (kernel/softirq.c:523) __local_bh_enable_ip (kernel/softirq.c:450) __dev_queue_xmit (net/core/dev.c:4913) packet_sendmsg (net/packet/af_packet.c:3139) __sys_sendto (net/socket.c:2252) __x64_sys_sendto (net/socket.c:2259) do_syscall_64 (arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121) Kernel panic - not syncing: Fatal exception in interrupt Reject routes without an inet6_dev immediately after lookup. Such routes are not eligible for reverse-path filtering, and the check protects all later rt6i_idev dereferences.
In the Linux kernel, the following vulnerability has been resolved: bpf: Fix out-of-bounds read of sk_protocol in bpf_sock_destroy() sk_protocol lives in struct sock, not in struct sock_common. A timewait or request sock handed to bpf_sock_destroy() by the tcp iterator is neither, so reading sk->sk_protocol runs past the object: ================================================================== BUG: KASAN: slab-out-of-bounds in bpf_sock_destroy+0xc7/0xe0 Read of size 2 at addr ffff8881047d11b4 by task test_progs/428 Tainted: [W]=WARN Call Trace: <TASK> dump_stack_lvl+0x91/0xf0 print_report+0xd1/0x630 kasan_report+0xf3/0x130 __asan_report_load2_noabort+0x14/0x30 bpf_sock_destroy+0xc7/0xe0 bpf_prog_c3dd61f9d9cd9f37_iter_tcp6_timewait+0x9f/0xb7 bpf_iter_run_prog+0x538/0xde0 bpf_iter_tcp_seq_show+0x26b/0x4b0 bpf_seq_read+0x424/0x1210 vfs_read+0x197/0xe40 ksys_read+0x119/0x240 __x64_sys_read+0x72/0xc0 x64_sys_call+0x647/0x27e0 do_syscall_64+0xe5/0x610 entry_SYSCALL_64_after_hwframe+0x76/0x7e Only check sk_protocol on full socks. tcp_abort() already knows how to deal with TIME_WAIT and NEW_SYN_RECV socks. Also fix the comment, it never matched the code.
In the Linux kernel, the following vulnerability has been resolved: vlan: require the MAC header to be present in __vlan_insert_inner_tag() __vlan_insert_inner_tag() only guarantees head room via skb_cow_head(), never that mac_len bytes of MAC header are present. Its ETH_HLEN wrappers - __vlan_insert_tag() under skb_vlan_push(), and vlan_insert_tag() under validate_xmit_vlan() on the generic transmit path - therefore rewrite the first 16 bytes at skb->data: a 12-byte memmove plus two 2-byte stores at +12 and +14. No caller supplies the bound, while the pop helpers use skb_ensure_writable()/pskb_may_pull(). An IFF_TUN device has hard_header_len == 0, so packet_snd() accepts a one-byte AF_PACKET/SOCK_RAW frame. The first vlan push only sets a hwaccel tag; the next - clsact "action vlan push" or bpf_skb_vlan_push() - enters the helper with skb->len still 1. The head comes from skbuff_small_head without __GFP_ZERO, so each push drags bytes from beyond skb->tail into the frame. After three the one-byte send leaves as 13 bytes carrying 11 bytes of uninitialised slab: 0000: 5a b3 62 12 80 88 ff ff 00 b3 62 12 81 `------------------------------' only 0x5a was sent; the rest is slab, here the top 56 bits of a linear-map address Require the MAC header the helper rewrites to be present, so such a frame is dropped rather than transmitted.
In the Linux kernel, the following vulnerability has been resolved: xen/netfront: drop RX packets with a short Ethernet header handle_incoming_queue() pulls pull_to bytes into the head before calling eth_type_trans(). pull_to is the length of the first RX slot, capped at RX_COPY_THRESHOLD, and that length comes from the backend. Nothing checks it against ETH_HLEN. If the first slot is shorter than ETH_HLEN and more slots follow, the head ends up shorter than an Ethernet header while skb->len is longer, and eth_type_trans() BUG()s in __skb_pull(). If the whole packet is shorter than ETH_HLEN, eth_type_trans() reads the header past the end of the data instead. Pull at least ETH_HLEN, and drop the packet if that fails, which also drops packets too short to hold an Ethernet header. This also checks the return value of the pull, which was ignored.
CVE-2026-105517 is recorded against Ubuntu Linux, with the only attribution in the available intelligence being a vendor:ubuntu report; the record carries no description, no CVSS score or vector, no CWE mapping, no CPE strings, no EPSS estimate, and no CISA KEV entry. Because the affected component, version range, and attack surface are all unspecified, the concrete security impact cannot be determined from this data alone, and no public exploit code has been identified at time of analysis. Risk cannot be meaningfully assessed until the corresponding Ubuntu Security Notice is retrieved to identify the package, vulnerable versions, and any prerequisites such as authentication or non-default configuration.
Ubuntu Linux is the vendor attribution for CVE-2026-105516, but no description, CVSS vector, CWE, CPE, or affected package detail accompanies the record, so the specific impact on any Ubuntu release cannot currently be stated. Exploitation status is unconfirmed: no public exploit identified at time of analysis and no CISA KEV listing was provided. Risk cannot be meaningfully assessed until the corresponding Ubuntu Security Notice and NVD entry are retrieved and mapped to concrete packages and releases.