Export limit exceeded: 15183 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (15183 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2026-19739 | 1 Zephyrproject | 1 Zephyr | 2026-10-11 | 6.5 Medium |
| The Bluetooth Link Layer control procedure code in subsys/bluetooth/controller/ll_sw/ull_llcp_conn_upd.c retains the received RX node while a Connection Update / Connection Parameter procedure waits for its instant, so the node can later carry the host notification (llcp_rx_node_retain(), which marks it NODE_RX_TYPE_RETAIN and thereby suppresses the normal recycling in ull.c). The default: arm of llcp_rp_cu_rx() and llcp_lp_cu_rx() — the "invalid PDU, terminate the connection" path — completed the procedure without releasing that retained node. llcp_rr_check_done() then dequeued and freed the procedure context with ctx->node_ref.rx still pointing at the retained node, dropping the last reference to it. A peer device in radio range can reach this without pairing, bonding, or encryption. Against a peripheral, the peer sends a well-formed LL_CONNECTION_UPDATE_IND with an instant a few connection events in the future (the node is retained and the procedure enters RP_CU_STATE_WAIT_INSTANT), then, before the instant is reached, sends any other LL Control PDU such as LL_LENGTH_REQ. ull_cp_rx() routes that PDU into the active remote Connection Update procedure, which takes the invalid-PDU path. The central role is reachable symmetrically after accepting an LL_CONNECTION_PARAM_REQ, and the local-procedure variant is reachable with LL_REJECT_IND. With CONFIG_BT_CTLR_ASSERT_DEBUG enabled (its default), the resulting state violates the invariant asserted in llcp_rr_check_done(), so the two-PDU sequence produces an immediate fatal error in the controller. With those asserts disabled, each occurrence permanently loses one node from the controller's small fixed RX pool (sized from CONFIG_BT_CTLR_RX_BUFFERS, which defaults to 1); repeating the sequence across reconnections exhausts the pool, after which the link-layer receive path operates on a NULL node. The impact is an unauthenticated, remotely triggerable denial of service persisting until reboot; there is no memory-disclosure or memory-corruption consequence, since the leaked node simply becomes unreachable. | ||||
| CVE-2026-19740 | 1 Zephyrproject | 1 Zephyr | 2026-10-11 | 6.5 Medium |
| The Link Layer Control Procedure (LLCP) implementation of the Zephyr software Bluetooth LE Controller retains the receive node that carried an accepted LL_PHY_UPDATE_IND so that it can later be reused for the host notification when the update instant is reached (llcp_rx_node_retain() in subsys/bluetooth/controller/ll_sw/ull_llcp.c, and the node is deliberately not recycled while marked NODE_RX_TYPE_RETAIN). The invalid-PDU arms of llcp_lp_pu_rx() and llcp_rp_pu_rx() in subsys/bluetooth/controller/ll_sw/ull_llcp_phy.c completed the procedure via llcp_lr_complete() / llcp_rr_complete() without first releasing that retained node, so the procedure context — the only remaining reference to the node — was freed while the node was still held out of the receive pool. A peer device on an established LE connection can drive this deterministically and without pairing or encryption. Against a peripheral it sends LL_PHY_REQ, receives LL_PHY_RSP, sends a valid LL_PHY_UPDATE_IND with an instant a few connection events in the future (so the node becomes retained), and then, before the instant is reached, sends any other LL Control PDU such as LL_LENGTH_REQ; ull_cp_rx() routes it to the active remote PHY Update procedure, which takes the invalid-PDU path. The mirror case applies to a locally initiated PHY Update followed by an LL_REJECT_IND. In the default configuration (CONFIG_BT_ASSERT and CONFIG_BT_CTLR_ASSERT_DEBUG both default y) the violated invariant in llcp_lr_check_done() / llcp_rr_check_done() triggers a controller assertion, ending in k_oops() (or k_panic()) — a single crafted PDU sequence from radio range faults the device. With those assertions compiled out, each attempt silently leaks one receive PDU node and its memq link; because the controller receive pool is small (PDU_RX_CNT, driven by CONFIG_BT_CTLR_RX_BUFFERS, which defaults to 1) and each attempt costs the attacker only a reconnect, a few repetitions exhaust the pool and leave Bluetooth inoperable until reboot. On releases v3.4.0 through v3.7.x the assertion is never reached, whatever the configuration, so every attempt leaks silently. The impact is limited to availability: the orphaned node leaves no dangling pointer that is later dereferenced and is never delivered to the host, so there is no memory corruption or information disclosure. The same pull request applies the identical release to the Connection Update and CIS-create procedures, whose invalid-PDU arms had the same omission. | ||||
| CVE-2026-108879 | 1 Jeecg | 2 Jeecg-boot, Jeecg Boot | 2026-10-11 | 4.3 Medium |
| JeecgBoot through 3.9.5 contains an insecure direct object reference vulnerability in AiragBaseApiController that allows authenticated users to read other users' AI chat variables via the username parameter. Attackers can send POST requests to /airag/api/getChatVariable with a target appId, username, and variable name to retrieve stored chat memory values from Redis. | ||||
| CVE-2026-108574 | 2 Berriai, Litellm | 2 Litellm, Litellm | 2026-10-11 | 4.3 Medium |
| A flaw has been found in BerriAI LiteLLM up to 1.95.0. Affected by this issue is the function ui_view_session_spend_logs of the file litellm/proxy/spend_tracking/spend_management_endpoints.py of the component Spend Tracking. Executing a manipulation of the argument session_id can lead to authorization bypass. It is possible to launch the attack remotely. The exploit has been published and may be used. Upgrading to version 1.96.0 can resolve this issue. This patch is called 722d9ffa4f6c5ae15702ab9ab2c5f6bf1688308b. The affected component should be upgraded. | ||||
| CVE-2026-93746 | 2026-10-11 | 7.5 High | ||
| The WebToffee WooCommerce PDF Invoices, Packing Slips, Delivery Notes & Shipping Labels plugin for WordPress is vulnerable to Insecure Direct Object Reference in versions up to, and including, 5.0.2 via the 'email' parameter of the guest print_document_from_the_mail_link handler dispatched from print_window() on init. This is due to the handler authorizing access to an order's printable documents when the attacker-supplied (base64-encoded) 'email' equals the order's billing email — a non-secret identifier — instead of requiring the WooCommerce order_key. This makes it possible for unauthenticated attackers, when the site is configured to allow guest access to documents ('wt_pklist_print_button_access_for' != 'logged_in'), to retrieve any other customer's invoice, packing slip, delivery note, dispatch label or shipping label — including customer name, billing/shipping address, phone number, purchased products, prices, taxes and invoice metadata — by knowing the target order ID and the associated billing email address. | ||||
| CVE-2026-91050 | 2026-10-11 | 4.3 Medium | ||
| The Appointment Booking Plugin – LatePoint | Calendar & Scheduling for WordPress plugin for WordPress is vulnerable to Insecure Direct Object Reference / Missing Authorization in versions up to, and including, 5.7.2. This is due to the publicly reachable steps__start and steps__load_step routes accepting a params[presets][order_item_id] value that is copied verbatim into the booking object without verifying that the referenced order item belongs to the current customer, is a bundle item, is paid, or has remaining capacity — the is_bundle_scheduling() bundle discriminator is a mere !empty(order_item_id) truthiness check, and the code flow explicitly removes the customer and payment steps when this is truthy (the source even carries a TODO acknowledging the missing validation). This makes it possible for unauthenticated attackers to create approved appointments against other customers' order items and to read those customers' names, email addresses, and order codes returned in the booking confirmation. | ||||
| CVE-2026-39453 | 1 Red Lion Controls | 1 700 Series | 2026-10-11 | 8.3 High |
| Navigating to a certain URL on the switch’s web server causes the switch to reboot. This can be automated using a tool like curl to create DoS conditions where the switch constantly reboots. | ||||
| CVE-2026-104898 | 2026-10-11 | 6.8 Medium | ||
| The Online Scheduling and Appointment Booking System – Bookly plugin for WordPress is vulnerable to Insecure Direct Object Reference in all versions up to, and including, 28.4 via the 'id, wp_user_id' parameter due to missing validation on a user controlled key. This makes it possible for authenticated attackers, with subscriber-level access and above, to overwrite the WordPress account binding of any Bookly staff record, including those owned by administrators, effectively hijacking a higher-privileged staff member's account association and escalating privileges. Exploitation requires the attacking user to be linked to at least one Bookly staff record, which occurs by default whenever an admin enables the bookly_gen_allow_staff_edit_profile option (active on fresh installs) and links a WordPress user to a staff entry. | ||||
| CVE-2026-102262 | 1 Newell Brands | 1 Dymo Id | 2026-10-11 | 7.3 High |
| Newell Brands DYMO ID 1.5.1.71 resolves its plugin Modules directory relative to the process working directory. An attacker could store a job file alongside malicious modules / DLL that sets the process working directory to the job file's folder when a victim clicks on the file, resulting in code execution at the victim's privilege level. Fixed in 1.6.0. | ||||
| CVE-2026-101893 | 1 Newell Brands | 1 Dymo Id | 2026-10-11 | 4.4 Medium |
| Newell Brands DYMO ID 1.5.1.71 parses job files using XmlDocument.Load() without disabling DTD processing. The PC Job Files view automatically parses every recognized job file extension on folder browse. A crafted file on any browsed network share can perform SSRF, capture NTLMv2 credentials, read local files, or crash the process. Fixed in 1.6.0. | ||||
| CVE-2026-98306 | 1 Linux | 1 Linux Kernel | 2026-10-11 | 7.0 High |
| In the Linux kernel, the following vulnerability has been resolved: seg6: set IPSKB_L3SLAVE from IP6SKB_L3SLAVE on IPIP decapsulation When an SRv6 packet arrives on an interface enslaved to a VRF, vrf_ip6_rcv() sets IP6SKB_L3SLAVE in IP6CB, but decap_and_validate() has never set IPSKB_L3SLAVE in IPCB. The bit stayed clear in the common case, and with CONFIG_IPV6_MIP6 the leftover frag_max_size of a reassembled outer packet could even set it, with no VRF involved. Commit 44930446dde4 ("ipv6: seg6: clear IPv4 control block on IPIP decapsulation") then made the unreliable bit reliably clear. The effect of the missing flag is visible with End.DX4 when a delivery to a local address of the node reaches the socket lookup. For example, a UDP socket bound to the enslaved ingress interface does not receive any of the decapsulated packets, while an unbound socket outside the VRF does. This contradicts Documentation/networking/vrf.rst: by default the scope of an unbound UDP or TCP socket is limited to the default VRF. Set IPSKB_L3SLAVE for IPv4 in decap_and_validate(), which already does the same for IPv6. The socket lookup then matches the decapsulated packet like any other packet received on that enslaved interface. Such a packet matches an unbound UDP or TCP socket only when udp_l3mdev_accept or tcp_l3mdev_accept is set. | ||||
| CVE-2026-98310 | 1 Linux | 1 Linux Kernel | 2026-10-11 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: drm/xe/shrinker: Take a runtime PM ref before shrinking non-system memory __xe_shrinker_walk() walks the SYSTEM and TT LRUs without a runtime PM reference. Shrinking a bo outside system memory invalidates its GPU mappings, which needs the device resumed, so while it is runtime suspended the page table zap trips an assert and the TLB invalidation returns -ENODEV: WARNING: drivers/gpu/drm/xe/xe_bo.c:770 at xe_bo_move_notify+0x1fc/0x450 [xe] xe_bo_shrink+0x20f/0x2b0 [xe] __xe_shrinker_walk+0x174/0x410 [xe] xe_shrinker_scan+0x10c/0x1e0 [xe] do_shrink_slab+0x176/0x7e0 drop_caches_sysctl_handler+0x9c/0xf0 Take a reference before walking a memory type other than XE_PL_SYSTEM and stop there if it cannot be acquired. Reuse the shrinker's existing acquire path, which resumes the device directly where reclaim allows that and otherwise queues the PM worker for a later scan. Stop the walk once the scan target is met, so a satisfied scan does not wake the device. System memory is still reclaimed while the device is suspended. Gate this on xe_device_is_l2_flush_optimized(), the same condition under which xe_bo_trigger_rebind() issues the invalidation for a non-fault-mode vm, so reclaim is unaffected elsewhere. The System CCS copy already has its own reference in xe_bo_shrink(). Only a non-fault-mode vm can reach this, since a fault-mode vm requires LR mode and that holds a runtime PM reference for the vm's lifetime. Reproduced with igt@xe_madvise@dontneed-before-exec while the GPU is runtime suspended. v2: simplify needs_rpm check. (Matt) retarget Fixes tag since the issue occurs with the non-fault-mode path added by 4e7ebff69aed. v3: handle this in xe_shrinker.c instead of xe_bo.c (Thomas) v4: stop the walk once the scan target is met. (Sashiko) v5: rebase on the freed page accounting fix. (Sashiko) v6: reuse the shrinker acquire path so runtime pm can be resumed directly instead of always queueing a worker. (Thomas) v7: replace xe_pm_runtime_put() with xe_shrinker_runtime_pm_put(). (Thomas) (cherry picked from commit 628f92b28bf4c371c10207daf6fc4caee0c0db2e) | ||||
| CVE-2026-104684 | 2026-10-11 | 2.7 Low | ||
| The Envira Gallery WordPress plugin before 1.16.2 does not verify that a user is authorized to read a gallery before rendering it, allowing authors to embed and expose other users' non-public gallery metadata to unauthenticated visitors. | ||||
| CVE-2026-108864 | 1 Iflytek | 1 Astron-agent | 2026-10-11 | 4.2 Medium |
| iFlytek Astron Agent through 1.1.2 contains an insecure direct object reference vulnerability that allows authenticated applications to resume other applications' paused workflows by supplying their event_id to POST /workflow/v1/resume. Attackers can predict Snowflake event IDs to inject resume content into victim workflows and read their continuation output stream, breaking cross-tenant isolation. | ||||
| CVE-2026-108575 | 1 Litellm | 1 Litellm | 2026-10-11 | 6.3 Medium |
| A vulnerability has been found in BerriAI LiteLLM up to 1.94.0. This affects the function get_secret of the file secret_managers/main.py of the component Secret Resolution. The manipulation of the argument api_key leads to improper authorization. The attack can be initiated remotely. The exploit has been disclosed to the public and may be used. The vendor was contacted early about this disclosure but did not respond in any way. | ||||
| CVE-2026-108747 | 1 Lightdash | 1 Lightdash | 2026-10-11 | 4.2 Medium |
| Lightdash through 2.556.0 contains an authorization bypass vulnerability that allows authenticated organization members to delete other users' personal access tokens by supplying their UUID. Attackers can send DELETE requests to the personal-access-tokens route with a victim's token UUID, even across organizations, to revoke it and break API integrations. | ||||
| CVE-2026-108752 | 2 Jupyter, Jupyterhub | 2 Jupyterhub, Jupyterhub | 2026-10-11 | 4.2 Medium |
| JupyterHub through 6.0.1 contains an identifier collision vulnerability that allows authenticated users to overwrite another user's named-server OAuth client by registering a hyphenated username. Attackers holding a name like alice-prod can overwrite the client for alice's server prod, breaking OAuth login and revoking tokens by stopping their own server. | ||||
| CVE-2026-80734 | 1 Linux | 1 Linux Kernel | 2026-10-11 | 8.8 High |
| In the Linux kernel, the following vulnerability has been resolved: btrfs: initialize inode mapping flags for cached inodes [BUG] When running generic/795 with 8K block size, 4K page size, the test always fails, triggering some ASSERT()s related to folio size: 795 (241074): drop_caches: 3 assertion failed: IS_ALIGNED(start, blocksize) && IS_ALIGNED(end + 1, blocksize), in extent_io.c:1404 (blocksize=8192 root=262 ino=258 start=16826368 end=16830463 mapping min order=0) ------------[ cut here ]------------ kernel BUG at extent_io.c:1404! Oops: invalid opcode: 0000 [#1] SMP CPU: 8 UID: 0 PID: 241105 Comm: fsstress Tainted: G OE 7.2.0-rc5-custom+ #442 PREEMPT(full) f4bfb352566f3949f29c233ce6f735050a03b245 Tainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODULE Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS unknown 02/02/2022 RIP: 0010:assert_folio_range.cold+0x3d/0x3f [btrfs] Call Trace: <TASK> btrfs_read_folio+0x9e/0x170 [btrfs 4cd1dd93b341b8ef766643f9512f4a86259567a3] prepare_one_folio.constprop.0+0x104/0x2a0 [btrfs 4cd1dd93b341b8ef766643f9512f4a86259567a3] btrfs_buffered_write+0x285/0xa50 [btrfs 4cd1dd93b341b8ef766643f9512f4a86259567a3] btrfs_do_write_iter+0x1aa/0x210 [btrfs 4cd1dd93b341b8ef766643f9512f4a86259567a3] iter_file_splice_write+0x31a/0x540 direct_splice_actor+0x53/0x170 splice_direct_to_actor+0xe9/0x240 do_splice_direct+0x76/0xb0 vfs_copy_file_range+0x1fd/0x630 __x64_sys_copy_file_range+0xf9/0x220 do_syscall_64+0xe1/0x790 entry_SYSCALL_64_after_hwframe+0x4b/0x53 </TASK> ---[ end trace 0000000000000000 ]--- The ASSERT() itself is added by a later patch. The crash is triggered with that new debug patch, and without this fix. [CAUSE] In the above case, the start 16826368 is properly 8K aligned, but the end (16830463 + 1) is not 8K aligned. Furthermore the mapping's minimal folio order is 0, not the expected 1 for 8K block size with 4K page size. So this means some inodes do not have btrfs_set_inode_mapping_order() called on it. The missing btrfs_set_inode_mapping_order() call happens for cached inodes, through the following events: - btrfs_create_new_inode() called for inode X Which properly sets minimal folio order for the VFS inode. - btrfs_update_inode() called for inode X Which calls btrfs_delayed_update_inode() to create a delayed_node into root->delayed_nodes xarray. - Drop cache/memory pressure, evicting in-memory inode X Which evicted the inode X, but delayed_node is still in root->delayed_nodes for future reuse. - btrfs_iget() for inode X called again btrfs_iget() |- btrfs_iget_locked() | |- iget5_locked_rcu() | Which creates a new vfs_inode for btrfs, whose mapping still | has the minimal order as 0. | |- btrfs_read_locked_inode() |- btrfs_fill_inode() | |- btrfs_get_delayed_node() | Which found out the previous node, and use that delayed | node to initialize the new inode. | |- filled = true; |- if (filled) goto cache_index; Which skips the btrfs_update_inode_mapping_flags() and btrfs_set_inode_mapping_order() calls. So the inode still has minimal folio order set as 0, not the required 1. Thus later page cache read will get a folio whose size is smaller than block size, as the mapping has its minimal folio order set as 0 not 1, then trigger the ASSERT(). [FIX] Move the btrfs_update_inode_mapping_flags() and btrfs_set_inode_mapping_order() calls under cache_index label, so that the mapping flags and minimal folio order is always set no matter if we have a cached inode. | ||||
| CVE-2026-80729 | 1 Linux | 1 Linux Kernel | 2026-10-11 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: mm/huge_memory: initialise workingset state before folio split xas_try_split() adds __GFP_ACCOUNT for page-cache xa_nodes, but __folio_split() leaves the xa_state's xa_lru unset. That lets a live, memcg-charged xa_node exist without being linked into the mapping's shadow_nodes list_lru; when reclaim later walks the list_lru it trips VM_WARN_ON(!css_is_dying()). Use mapping_set_update() to install both the workingset update callback and the shadow_nodes list_lru on the xa_state. | ||||
| CVE-2026-108862 | 2026-10-11 | 5.3 Medium | ||
| APIPark through 1.9.7-beta contains an insecure direct object reference vulnerability that allows authenticated users to read other applications' credentials by supplying a foreign authorization UUID. Attackers with authorization-view permission on one application can query /api/v1/app/authorization or its details route to retrieve plaintext API keys regardless of HideCredential. | ||||