Vulnerabilities
All
My stack
Known exploited
Public exploit
Critical (9+)
Likely exploited (EPSS ≥ 50%)
Changed, 24 h
New, 24 h
Sort:
risk
modified
published
CVSS
EPSS
| CVE | CVSS | EPSS | Vendor, product | Description | Modified |
|---|---|---|---|---|---|
| CVE-2026-99081 | 7.5 high | 0.00% | no CPE yet | In the Linux kernel, the following vulnerability has been resolved: bnxt_en: fix DMA mapping length for padded small packets Stefan Fleischmann reported Intel IOMMU DMA Read faults on BCM57412 NetXtreme-E NICs when transmitting packets on VLAN/macvlan interfaces: DMAR: [DMA Read NO_PASID] Request device [18:00.0] fault addr 0xfc499000 [fault reason 0x06] PTE Read access is not set bnxt_en 0000:18:00.0 eno1np0: Abandoning msg {0xb4 0x41a} len: 0 due to firmware status: 0x2000001 ... NETDEV WATCHDOG: eno1np0 (bnxt_en): transmit queue 0 timed out The fault address (0xfc499000) is on an exact 4KB page boundary, pointing to a DMA read buffer overrun. In bnxt_start_xmit(), packets smaller than BNXT_MIN_PKT_SIZE (52 bytes), such as 42-byte untagged ARP frames, are padded: if (length < BNXT_MIN_PKT_SIZE) { pad = BNXT_MIN_PKT_SIZE - length; if (skb_pad(skb, pad)) goto tx_kick_pending; length = BNXT_MIN_PKT_SIZE; } mapping = dma_map_single(&pdev->dev, skb->data, len, DMA_TO_DEVICE); ... dma_unmap_len_set(tx_buf, len, len); However, 'len' was initialized earlier to skb_headlen(skb) (e.g. 42 bytes) and is left unadjusted after padding. Consequently, dma_map_single() and dma_unmap_len_set() map and track only 42 bytes. Later, the hardware TX buffer descriptor is programmed with the padded length: txbd->tx_bd_len_flags_type = cpu_to_le32(((len + pad) << TX_BD_LEN_SHIFT) | flags | TX_BD_FLAGS_PACKET_END); The NIC DMA engine is thus instructed to read 52 bytes from a region where only 42 bytes were DMA-mapped. If skb->data ends near the boundary of a 4KB page (within 'pad' bytes of the next page), the hardware DMA read overruns into the unmapped adjacent page, triggering an IOMMU fault. This issue was exposed after commit 447cbe95ebb9 ("vlan: fix skb_under_panic and races when toggling HW VLAN offload") because reserving extra VLAN headroom rounded LL_RESERVED_SPACE from 48 up to 64 bytes, shifting skb->data offsets and potentially causing small frames to land right against page boundaries. Fix this by using skb_put_padto(skb, BNXT_MIN_PKT_SIZE) in bnxt_start_xmit(), before skb_shinfo(skb)->nr_frags is sampled, because padding might linearize the skb. This ensures skb->len and skb_headlen(skb) reflect the padded size so that dma_map_single() maps the full buffer and the descriptor length is consistent. This also removes the temporary 'pad' variable and masking logic. The padding is done after the SW USO branch, otherwise bnxt_sw_udp_gso_xmit() would account the padding as UDP payload and send it in extra segments. Note that SW USO segments are still not padded: with IPv4, a segment carrying less than 10 bytes of UDP payload (small gso_size, or a short last segment) is sent as a frame shorter than BNXT_MIN_PKT_SIZE. This is a separate issue, left for a followup patch. | 24 Oct |
| CVE-2025-13016 | 7.5 high | 0.00% | mozilla, firefox | Incorrect boundary conditions in the JavaScript: WebAssembly component. This vulnerability was fixed in Firefox 145, Firefox ESR 140.5, Thunderbird 145, and Thunderbird 140.5. | 23 Oct |
| CVE-2026-68414 | 7.5 high | 0.00% | no CPE yet | In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: cancel sched scan results work on unregister cfg80211_sched_scan_results() can queue rdev->sched_scan_res_wk from a driver result notification while a scheduled scan request is present. The work callback recovers the containing cfg80211_registered_device and then locks the wiphy and walks the scheduled-scan request list. wiphy_unregister() already makes the wiphy unreachable and drains rdev work items before cfg80211_dev_free() can release the object, but it does not drain sched_scan_res_wk. A queued or running result work item can therefore cross the unregister/free boundary and access freed rdev state. The buggy scenario involves two paths, with each column showing the order within that path: scheduled-scan result path: unregister/free path: 1. cfg80211_sched_scan_results() 1. interface teardown stops and queues rdev->sched_scan_res_wk. removes the scheduled scan request. 2. cfg80211_wq starts the work 2. wiphy_unregister() drains other item and recovers rdev. rdev work items. 3. The worker locks rdev->wiphy 3. cfg80211_dev_free() destroys and and walks rdev state. frees rdev. Cancel sched_scan_res_wk in wiphy_unregister() alongside the other rdev work items. cancel_work_sync() removes a pending result notification and waits for an already running callback, so cfg80211_dev_free() cannot free rdev while this work item is still active. Validation reproduced this kernel report: BUG: KASAN: use-after-free in cfg80211_sched_scan_results_wk+0x4a6/0x530 Workqueue: cfg80211 cfg80211_sched_scan_results_wk [cfg80211] Read of size 8 Call trace: dump_stack_lvl+0x66/0xa0 print_report+0xce/0x630 cfg80211_sched_scan_results_wk+0x4a6/0x530 srso_alias_return_thunk+0x5/0xfbef5 __virt_addr_valid+0x224/0x430 kasan_report+0xac/0xe0 lockdep_hardirqs_on_prepare+0xea/0x1a0 process_one_work+0x8d0/0x18f0 (kernel/workqueue.c:3212) lock_is_held_type+0x8f/0x100 worker_thread+0x5ad/0xfd0 __kthread_parkme+0xc6/0x200 kthread+0x31e/0x410 trace_hardirqs_on+0x1a/0x170 ret_from_fork+0x576/0x810 __switch_to+0x57e/0xe20 __switch_to_asm+0x33/0x70 ret_from_fork_asm+0x1a/0x30 | 19 Oct |
| CVE-2025-58147 | 7.5 high | 0.00% | xen | [This CNA information record relates to multiple CVEs; the text explains which aspects/vulnerabilities correspond to which CVE.] Some Viridian hypercalls can specify a mask of vCPU IDs as an input, in one of three formats. Xen has boundary checking bugs with all three formats, which can cause out-of-bounds reads and writes while processing the inputs. * CVE-2025-58147. Hypercalls using the HV_VP_SET Sparse format can cause vpmask_set() to write out of bounds when converting the bitmap to Xen's format. * CVE-2025-58148. Hypercalls using any input format can cause send_ipi() to read d->vcpu[] out-of-bounds, and operate on a wild vCPU pointer. | 19 Oct |
| CVE-2025-58148 | 7.5 high | 0.00% | xen | [This CNA information record relates to multiple CVEs; the text explains which aspects/vulnerabilities correspond to which CVE.] Some Viridian hypercalls can specify a mask of vCPU IDs as an input, in one of three formats. Xen has boundary checking bugs with all three formats, which can cause out-of-bounds reads and writes while processing the inputs. * CVE-2025-58147. Hypercalls using the HV_VP_SET Sparse format can cause vpmask_set() to write out of bounds when converting the bitmap to Xen's format. * CVE-2025-58148. Hypercalls using any input format can cause send_ipi() to read d->vcpu[] out-of-bounds, and operate on a wild vCPU pointer. | 19 Oct |
| CVE-2025-42940 | 7.5 high | 0.00% | no CPE yet | SAP CommonCryptoLib does not perform necessary boundary checks during pre-authentication parsing of manipulated ASN.1 data over the network. This may result in memory corruption followed by an application crash, hence leading to a high impact on availability. There is no impact on confidentiality or integrity. | 18 Oct |
| CVE-2025-13025 | 7.5 high | 0.00% | mozilla, firefox | Incorrect boundary conditions in the Graphics: WebGPU component. This vulnerability was fixed in Firefox 145 and Thunderbird 145. | 18 Oct |
| CVE-2026-8954 | 7.5 high | 0.00% | mozilla, firefox, thunderbird | Incorrect boundary conditions, integer overflow in the Audio/Video component. This vulnerability was fixed in Firefox 151, Firefox ESR 140.11, Thunderbird 151, and Thunderbird 140.11. | 14 Oct |
| CVE-2026-84783 | 7.5 high | 0.00% | openssl | Issue summary: The first concurrent use of the same X.509 certificate by several threads may cause its cached extension data to be freed while another thread is still using it. Impact summary: A remote, unauthenticated peer could crash a multi-threaded TLS client, or a multi-threaded TLS server that requests client certificates, if the first certificate chains built to the same trusted CA certificate are built by several connections at the same time. This is a use-after-free read, which is likely to crash the process, resulting in a Denial of Service. CWE: CWE-416: Use After Free Description: OpenSSL caches the decoded values of a certificate's X.509v3 extensions inside the X509 object the first time they are needed. In OpenSSL 4.0 this cache is built in two phases: the extension values are computed while holding a read lock on the certificate, and the results are then installed into the certificate under a write lock. Because a read lock does not exclude other readers, several threads can compute the cache for the same certificate at the same time. Each thread that subsequently acquires the write lock installs its own results and frees the values installed by the thread before it, even though that earlier thread has already marked the cache as complete and may have returned pointers into it to its caller. A caller still using those pointers then reads freed memory. Any certificate shared between threads is exposed the first time its extensions are decoded. In TLS the certificates at risk are the trusted CA certificates supplied for chain verification, by whatever means, since these are shared by every connection and their extensions are decoded and cached the first time a chain is built to them. Certificates sent by the peer are decoded separately for each connection and are not shared, so they are not affected. In a TLS client verifying server certificates, or a TLS server that requests and verifies client certificates, the use-after-free could only occur if the first chains built to the same trusted CA are built by several connections at the same time. FIPS impact: no The FIPS module is not affected as X.509 certificate handling is outside of the OpenSSL FIPS module boundary. OpenSSL 4.0 is vulnerable to this issue. OpenSSL 3.6, 3.5, 3.4, 3.0, 1.1.1 and 1.0.2 are not affected by this issue. OpenSSL 4.0 users should upgrade to OpenSSL 4.0.3. This issue was reported on 27 August 2026 by Tim Becker (Xint.io) and independently in a public report on 31 August 2026 by aydinmercan. The fix has been developed by Bob Beck. -- cut (non-publishing metadata for internal use) -- Reported by: Tim Becker (Xint.io), aydinmercan Fixed by: Bob Beck | 8 Oct |
| CVE-2026-72897 | 7.5 high | 0.00% | openssl | Issue summary: A TLS server that calls SSL_set_SSL_CTX() to switch a connection to a different SSL_CTX part way through a handshake may access memory beyond the end of an internal array if the replacement context knows about more provider signature algorithms than the context the connection was created from. Applications which never call SSL_set_SSL_CTX() are not affected. Impact summary: A remote peer may be able to cause a small out-of-bounds read, and in some circumstances a fixed-value out-of-bounds write, on the server heap. This may lead to a Denial of Service. CWE: CWE-787: Out-of-bounds Write Description: A TLS connection records how many certificate slots it has when it is created, taken from the SSL_CTX that created it: the built-in certificate types plus one slot for each provider TLS-SIGALG entry that context was aware of. That count sizes an internal array of per-slot certificate validity flags. An application may replace a connection's SSL_CTX part way through the handshake by calling SSL_set_SSL_CTX(), most commonly from a servername callback in order to serve a different virtual host. Doing so did not refresh the recorded count. A provider signature algorithm's slot index is its position in the list of whichever context resolves it, so if the replacement context is aware of more of them than the original, an algorithm offered by the peer can resolve to an index beyond the end of the array. Processing the peer's signature algorithms then reads one four byte word past the end for each such algorithm and, where the word read is zero, writes a fixed value over it. A peer offering many of them can corrupt heap metadata and abort the process. Only provider signature algorithms which occupy one of the excess slots, and which the server also has configured, have this effect. Codepoints the replacement context does not recognise are discarded without being resolved to a slot, and provider signature algorithms are usable only from TLS 1.3. The two contexts must therefore be aware of different numbers of provider signature algorithms, which requires separate library contexts, a provider loaded between the two being created, or providers which differ in what they advertise - in 4.0, for example, the default provider advertises SM2 where the FIPS provider does not. A deployment meeting the condition is also unable to negotiate the affected algorithms with legitimate clients, since the same stale count hides the corresponding certificates, so the misconfiguration is likely to be noticed. For that reason, and because the configuration is not the default, this issue has been assessed as Low severity. FIPS impact: no No FIPS modules are affected by this issue as the affected code is outside the OpenSSL FIPS module boundary. | 8 Oct |
| CVE-2026-10652 | 7.4 high | 0.00% | zephyrproject, zephyr | Zephyr's DNS resolver (subsys/net/lib/dns) parses resource records from DNS responses in dns_unpack_answer(), which validated only the fixed RR header (type, class, TTL, rdlength) and accepted any attacker-declared rdlength, including one extending past the end of the received datagram. The TXT and SRV consumers in dns_validate_record() (resolve.c) then read up to rdlength bytes (clamped only to a record-type maximum such as DNS_MAX_TEXT_SIZE, default 64, not to the packet) from the receive buffer via memcpy without their own bounds check, and pass the result to the application's resolve callback. A malicious or spoofed DNS server, an on-path attacker forging UDP DNS replies, or (with mDNS/LLMNR enabled) any LAN node can craft a truncated TXT or SRV response that causes an out-of-bounds read of adjacent receive-pool memory; the disclosed stale bytes (residual contents of prior DNS packets / uninitialized pool memory) are returned to the application as TXT/SRV record contents, an information leak, and may in some configurations cross the allocation boundary and fault, causing a denial of service. The read is bounded (~64 bytes for TXT, ~6 for SRV) and read-only (no write). The fix rejects any record whose declared rdata extends past dns_msg->msg_size at the single chokepoint in dns_unpack_answer(). Affected: v4.3.0 and v4.4.0. | Sun 25 Oct |
| CVE-2026-62848 | 7.3 high | — | metalama | Metalama is a Roslyn-based open-source patterns and architecture toolkit for C#. From 2023.0.101-rc until 2025.1.18, 2026.0.25 and 2026.1.19, the Windows Visual Studio integration deserializes local named-pipe messages without restricting which CLR types can be instantiated. The pipe connects `devenv`, the out-of-process Roslyn code-analysis process and the `CodeLens` process, and has the predictable name `Metalama_{role}_{processId}_{hash(PackageVersion)}`. Releases from the first public 2023.0 line through 2026.0.x use Newtonsoft.Json with `TypeNameHandling.All`; the later `SerializationBinder` only remaps assembly names, and `BindToType` resolves arbitrary wire-supplied types without an allow-list. Releases 2026.1.0 through 2026.1.18 use typeless MessagePack with `TypelessObjectResolver` and likewise instantiate arbitrary types. A same-user local process able to write to the pipe can send crafted messages that lead to arbitrary code execution with confidentiality, integrity and availability impacts inside the affected Visual Studio process. Default Windows pipe ACLs limit writers to the same logged-in user, so this does not escalate privileges or cross a security boundary; command-line and MSBuild-only builds do not use the channel. The maintained Metalama + PostSharp extension is affected from 2024.1 through 2026.1.4, while earlier Metalama-free PostSharp versions are unaffected. The retired Metalama and Caravela extensions remain affected and require removal or migration. The framework issue is fixed in versions 2025.1.18, 2026.0.25 and 2026.1.19; the maintained Metalama + PostSharp Visual Studio extension is fixed in version 2026.1.5. The retired Metalama and Caravela extensions require removal or migration. | Fri 30 Oct |
| CVE-2026-6753 | 7.3 high | 0.00% | mozilla, firefox, thunderbird | Incorrect boundary conditions in the WebRTC component. This vulnerability was fixed in Firefox 150, Firefox ESR 140.10, Thunderbird 150, and Thunderbird 140.10. | Mon 26 Oct |
| CVE-2026-12318 | 7.3 high | 0.00% | mozilla, firefox, thunderbird | Incorrect boundary conditions in the Libraries component in NSS. This vulnerability was fixed in Firefox 152 and Thunderbird 152. | Mon 26 Oct |
| CVE-2026-12324 | 7.3 high | 0.00% | mozilla, firefox, thunderbird | Incorrect boundary conditions in the Graphics: CanvasWebGL component. This vulnerability was fixed in Firefox 152, Firefox ESR 140.12, Thunderbird 152, and Thunderbird 140.12. | Mon 26 Oct |
| CVE-2026-6752 | 7.3 high | 0.00% | mozilla, firefox, thunderbird | Incorrect boundary conditions in the WebRTC component. This vulnerability was fixed in Firefox 150, Firefox ESR 115.35, Firefox ESR 140.10, Thunderbird 150, and Thunderbird 140.10. | Sun 25 Oct |
| CVE-2026-65705 | 7.3 high | 0.00% | ffmpeg | FFmpeg versions 3.4 through 8.1.2 contain an out-of-bounds write vulnerability in the vf_floodfill video filter that allows attackers to corrupt heap memory by supplying a dynamically sized video stream with filtergraph reinitialization disabled via -reinit_filter 0. When config_input() allocates the points traversal stack based on initial frame dimensions and a subsequent larger frame is processed, filter_frame() performs flood-fill neighbor pushes beyond the original allocation boundary, resulting in heap corruption and process crash with potential for code execution depending on heap layout and process hardening. | 24 Oct |
| CVE-2025-39968 | 7.3 high | 0.00% | no CPE yet | In the Linux kernel, the following vulnerability has been resolved: i40e: add max boundary check for VF filters There is no check for max filters that VF can request. Add it. | 19 Oct |
| CVE-2026-43025 | 7.3 high | 0.00% | linux, linux_kernel | In the Linux kernel, the following vulnerability has been resolved: netfilter: ctnetlink: ignore explicit helper on new expectations Use the existing master conntrack helper, anything else is not really supported and it just makes validation more complicated, so just ignore what helper userspace suggests for this expectation. This was uncovered when validating CTA_EXPECT_CLASS via different helper provided by userspace than the existing master conntrack helper: BUG: KASAN: slab-out-of-bounds in nf_ct_expect_related_report+0x2479/0x27c0 Read of size 4 at addr ffff8880043fe408 by task poc/102 Call Trace: nf_ct_expect_related_report+0x2479/0x27c0 ctnetlink_create_expect+0x22b/0x3b0 ctnetlink_new_expect+0x4bd/0x5c0 nfnetlink_rcv_msg+0x67a/0x950 netlink_rcv_skb+0x120/0x350 Allowing to read kernel memory bytes off the expectation boundary. CTA_EXPECT_HELP_NAME is still used to offer the helper name to userspace via netlink dump. | 19 Oct |
| CVE-2026-54702 | 7.3 high | 0.00% | no CPE yet | Markdown Preview Enhanced is a Markdown preview extension for Visual Studio Code. Prior to 0.8.30, the webview message handler in src/preview-provider.ts accepts an attacker-controlled command value and attacker-controlled args, constructs a command in the _crossnote namespace, and invokes vscode.commands.executeCommand without an allowlist or type validation. JavaScript already executing in the preview webview can use this bridge to invoke privileged extension commands, including file modification, code-chunk execution, export-tool execution, and arbitrary URL opening, with attacker-selected arguments. Exploitation requires a separate webview JavaScript execution path, such as the independently tracked .crossnote/head.html injection, but no further authorization check protects the extension-host command boundary. This issue is fixed in version 0.8.30. | 16 Oct |
| CVE-2026-44320 | 7.3 high | 0.00% | free5gc | free5GC is an open-source implementation of the 5G core network. Prior to 4.2.2, free5GC's NEF mounts the nnef-callback route group without inbound OAuth2/bearer-token authorization. A forged or arbitrary bearer token (e.g. Authorization: Bearer not-a-real-token) is enough to reach the SMF-callback handler -- the callback body is parsed and dispatched into NEF business logic instead of being rejected at the auth boundary. Same root cause as the other NEF SBI findings: the route group is mounted without any inbound auth middleware. NEF does not authenticate the producer NF identity before processing callback content; if an attacker can guess or obtain a valid NotifId, this missing auth boundary lets forged callbacks act on real subscription state. The route group is also reachable even when the runtime ServiceList does not declare it (it lists only nnef-pfdmanagement and nnef-oam). This vulnerability is fixed in 4.2.2. | 14 Oct |
| CVE-2026-63224 | 7.2 high | — | openremote | OpenRemote is an open-source internet-of-things platform. Prior to 1.26.0, the `datapoint export` API constructs `CSV crosstab` SQL by concatenating an `asset name` and `attribute name` into a `COPY` query that uses `crosstab` and streams `TO STDOUT`. The `asset name` enters both a double-quoted column identifier and a category query enclosed by the fixed `$cat$` delimiter. Escaping single quotes in one string context does not escape embedded double quotes in identifiers or protect that dollar-quote boundary. An authenticated user permitted to create or rename an asset and read/export datapoints for one of its attributes can store SQL metacharacters in the name and request a `crosstab` export, causing injected SELECT output to be returned in the normal ZIP/CSV response. This enables database exfiltration without direct database or filesystem access or token forgery. In a multi-tenant deployment it can expose other tenants' data if the manager's database role can read shared tables; integrity and availability effects are not established by the demonstrated read primitive. This issue is fixed in version 1.26.0. | 23 h ago |
| CVE-2026-6832 | 7.2 high | 0.00% | get-hermes, hermes_web_ui | Hermes WebUI contains an arbitrary file deletion vulnerability in the /api/session/delete endpoint that allows authenticated attackers to delete files outside the session directory by supplying an absolute path or path traversal payload in the session_id parameter. Attackers can exploit unvalidated session identifiers to construct paths that bypass the SESSION_DIR boundary and delete writable JSON files on the host system. | Mon 26 Oct |
| CVE-2026-44000 | 7.2 high | 0.00% | vm2_project, vm2 | vm2 is an open source vm/sandbox for Node.js. Prior to 3.11.0, a sandbox boundary violation in vm2 allows host object identity to cross into the sandbox through host Promise resolution. When a host-side Promise that resolves to a host object is exposed to the sandbox, the value delivered to the sandbox .then() callback preserves host identity. This allows the sandbox to interact with the host object directly, including performing identity checks using host-side WeakMap and mutating host object state from inside the sandbox. This behavior occurs because the Promise fulfillment wrapper uses ensureThis() instead of the stronger cross-realm conversion path (from() / proxy wrapping). If no prototype mapping is found, ensureThis() returns the original object. As a result, objects resolved by host Promises can cross the sandbox boundary without proper isolation. This vulnerability is fixed in 3.11.0. | Mon 26 Oct |
| CVE-2026-96570 | 7.2 high | 0.00% | no CPE yet | The Schema & Structured Data for WP & AMP plugin for WordPress is vulnerable to Stored Cross-Site Scripting via the 'saswp_review_text' parameter in all versions up to, and including, 1.67 due to insufficient input sanitization and output escaping. This makes it possible for unauthenticated attackers to inject arbitrary web scripts in pages that will execute whenever a user accesses an injected page. The nonce that serves as the only authorization gate is publicly printed in the [saswp-reviews-form] shortcode HTML, making it obtainable by any anonymous visitor and rendering it ineffective as an access control boundary. | 16 Oct |
| CVE-2026-100532 | 7.2 high | 0.00% | no CPE yet | @openclaw/whatsapp (npm) before 2026.8.1 exposes the WhatsApp login tool through the generic channel-tool path without preserving the originating sender's owner status, so the owner-only tool boundary is not enforced. An admitted non-owner sender able to steer the tool can request a forced login and receive a new QR code for a configured account, disconnecting the Gateway's WhatsApp account and causing loss of availability; full account relinking additionally requires the attacker to scan the returned QR code with another phone. The issue affects the owner-only tool boundary rather than WhatsApp transport authentication. Fixed in 2026.8.1. | 8 Oct |
| CVE-2026-63201 | 7.1 high | — | cesnet, netopeer2 | Netopeer2 is a server for implementing network configuration management based on the `NETCONF` Protocol. In affected versions, a low-privileged authenticated `NETCONF` user can remotely crash `netopeer2-server` by sending a `get RPC` with an invalid `subtree filter` whose text contains format specifiers. In `src/netconf.c`, `np2srv_rpc_get_cb()` sends the invalid value through `ERR()` to `np2log_printf()`, where `vsnprintf()` first formats the message safely. In `src/log.c`, that already formatted buffer is subsequently passed to `np2log()` as the format string itself, causing `vsyslog()` to interpret attacker-controlled percent sequences and read invalid pointer arguments. The reported denial of service was confirmed on version 2.8.7 using `NETCONF`-over-SSH and AddressSanitizer; reliable remote code execution was not confirmed. `The advisory identifies 2.8.8 as patched`; repository comparisons verify the fix in public release 2.8.21. The affected/fixed boundary remains unresolved because no public 2.8.8 tag was located, which does not establish the status of an untagged 2.8.8 build. | 23 h ago |
| CVE-2026-119337 | 7.1 high | — | infiniflow, ragflow | RAGFlow is an open-source RAG (Retrieval-Augmented Generation) engine. From 0.25.2 until 0.27.3, POST /api/v1/agents/chat/completions invokes completion_openai and returns through the openai-compatible branch before UserCanvasService.accessible() checks whether the caller may access the requested agent. An authenticated user who knows another user's private agent UUID can execute that Only me workflow and read its output across the user or tenant boundary; configured tools may also cause side effects, but stronger impacts were not demonstrated. This issue is fixed in version 0.27.3. | Fri 30 Oct |
| CVE-2026-62301 | 7.1 high | — | franklioxygen, mytube | MyTube is a self-hosted downloader and player for several video websites. Prior to version 1.10.3, backend video access does not enforce the visitor role's intended public-only restriction when `loginEnabled=true` and a visitor password is configured. The frontend filter in `VideoContext.tsx` is only client-side, `roleBasedAuthMiddleware.ts` allows all visitor GET requests, and `storageService/videos.ts` performs `getVideos()` and `getVideoById(id)` queries without checking the caller's role or `visibility`. A visitor can enumerate `/api/videos` or request `/api/videos/:id` to retrieve hidden `visibility`=0 records, exposing titles, `sourceUrl` values, `videoPath` values, subtitle paths and `thumbnailPath` values. The `serveMountVideo()` path also serves mounted video files without `visibility` checks. Leaked paths work against unauthenticated `/videos/*` and `/subtitles/*` routes, allowing media downloads without credentials. The RSS visitor feed already filters `visibility`=1 content and is not the affected query path. Default loginEnabled=false single-user deployments are unaffected by this role-boundary issue because all callers are owner-equivalent. This issue is fixed in version 1.10.3. | Fri 30 Oct |
| CVE-2026-31707 | 7.1 high | 0.00% | linux | In the Linux kernel, the following vulnerability has been resolved: ksmbd: validate response sizes in ipc_validate_msg() ipc_validate_msg() computes the expected message size for each response type by adding (or multiplying) attacker-controlled fields from the daemon response to a fixed struct size in unsigned int arithmetic. Three cases can overflow: KSMBD_EVENT_RPC_REQUEST: msg_sz = sizeof(struct ksmbd_rpc_command) + resp->payload_sz; KSMBD_EVENT_SHARE_CONFIG_REQUEST: msg_sz = sizeof(struct ksmbd_share_config_response) + resp->payload_sz; KSMBD_EVENT_LOGIN_REQUEST_EXT: msg_sz = sizeof(struct ksmbd_login_response_ext) + resp->ngroups * sizeof(gid_t); resp->payload_sz is __u32 and resp->ngroups is __s32. Each addition can wrap in unsigned int; the multiplication by sizeof(gid_t) mixes signed and size_t, so a negative ngroups is converted to SIZE_MAX before the multiply. A wrapped value of msg_sz that happens to equal entry->msg_sz bypasses the size check on the next line, and downstream consumers (smb2pdu.c:6742 memcpy using rpc_resp->payload_sz, kmemdup in ksmbd_alloc_user using resp_ext->ngroups) then trust the unverified length. Use check_add_overflow() on the RPC_REQUEST and SHARE_CONFIG_REQUEST paths to detect integer overflow without constraining functional payload size; userspace ksmbd-tools grows NDR responses in 4096-byte chunks for calls like NetShareEnumAll, so a hard transport cap is unworkable on the response side. For LOGIN_REQUEST_EXT, reject resp->ngroups outside the signed [0, NGROUPS_MAX] range up front and report the error from ipc_validate_msg() so it fires at the IPC boundary; with that bound the subsequent multiplication and addition stay well below UINT_MAX. The now-redundant ngroups check and pr_err in ksmbd_alloc_user() are removed. This is the response-side analogue of aab98e2dbd64 ("ksmbd: fix integer overflows on 32 bit systems"), which hardened the request side. | Fri 30 Oct |
| CVE-2026-98110 | 7.1 high | 0.00% | linux, linux_kernel | In the Linux kernel, the following vulnerability has been resolved: Bluetooth: btintel: bound firmware ID by TLV length The firmware ID is treated as a NUL-terminated string even though the TLV length is its only boundary. If the value does not contain a NUL terminator, snprintf() can read beyond the received response. Limit the conversion to the advertised TLV value length. | Wed 28 Oct |
| CVE-2026-44215 | 7.1 high | 0.00% | m2team, nanazip | NanaZip is an open source file archive. From 5.0.1252.0 to before 6.0.1698.0, a one-byte heap out-of-bounds null write exists in the UFS/UFS2 filesystem image parser in NanaZip. The vulnerability is triggered when opening a crafted UFS filesystem image. The attacker controls the byte offset of the write within a ~254-byte window past the heap allocation boundary. This vulnerability is fixed in 6.0.1698.0. | Mon 26 Oct |
| CVE-2026-42919 | 7.1 high | 0.00% | f5, big-ip_access_policy_manager, big-ip_advanced_firewall_manager, big-ip_advanced_web_application_firewall | A vulnerability exists in BIG-IP systems that may allow an authenticated attacker with administrative access to escalate their privileges. A successful exploit may allow the attacker to cross a security boundary. Note: Software versions which have reached End of Technical Support (EoTS) are not evaluated. | Mon 26 Oct |
| CVE-2026-44647 | 7.1 high | 0.00% | no CPE yet | OneDev is a Git server with CI/CD, kanban, and packages. Prior to 15.0.2, there is behavior that breaks the expected boundary between repository-controlled LFS metadata and server-local filesystem paths. A repository object can steer raw blob reads to arbitrary local files that the server account can access. User with push permission to any repository will be able to access any server files accessible by server process. This vulnerability is fixed in 15.0.2. | Mon 26 Oct |
| CVE-2026-48856 | 7.1 high | 0.00% | erlang, erlang\/inets, erlang\/otp | Sensitive Data Exposure vulnerability in Erlang OTP inets (httpc_response module) allows Retrieve Embedded Sensitive Data. The httpc client forwards the Authorization and Proxy-Authorization request headers to redirect targets without checking whether the redirect crosses an origin boundary. httpc_response:redirect/2 constructs the redirected request by updating only the host field of the header record; all other fields (including authorization and proxy_authorization) are copied verbatim. The redirect target host is never compared against the original host. autoredirect defaults to true, so this affects all httpc callers that do not explicitly disable automatic redirects. An attacker who controls a server that the victim contacts via httpc can issue a cross-origin 3xx redirect to a server they also control. The Authorization header (including Basic credentials derived from URL userinfo via httpc_request:handle_user_info/2) is forwarded to the redirect target, allowing credential theft. The same applies to the Proxy-Authorization header. This vulnerability is associated with program files lib/inets/src/http_client/httpc_response.erl. This issue affects OTP from OTP 17.0 before OTP 27.3.4.19, OTP 28.5.0.8, and OTP 29.1.2, corresponding to inets from 5.10 before 9.3.2.8, 9.6.2.4, and 9.8.1. Whether OTP before OTP 17.0, corresponding to inets before 5.10, is affected is unknown. | Mon 26 Oct |
| CVE-2026-55197 | 7.1 high | 0.00% | no CPE yet | Hermes WebUI before 0.51.443 contains a broken access control vulnerability in the /api/session endpoint that allows authenticated users to disclose cross-profile session transcripts. Attackers can bypass profile boundary checks by directly querying session IDs belonging to other profiles via GET /api/session?session_id=<foreign_id>&messages=1 to retrieve unauthorized conversation transcripts and metadata. | Mon 26 Oct |
| CVE-2026-49338 | 7.1 high | 0.00% | no CPE yet | gonic is a music streaming server / free-software subsonic server API implementation. Prior to version 0.21.0, the Subsonic API endpoints `/rest/deletePlaylist.view` and `/rest/getPlaylist.view` perform no per-resource authorization. Once authenticated as any user (admin or not), an attacker can delete any playlist owned by any other user (including admin) by passing its `id` and read the full contents (name, comment, song list) of any other user's **private** (non-public) playlist by passing its `id`. The Subsonic playlist `id` is `base64url("<userID>/<filename>.m3u")`. Because filenames are user-supplied or time-derived and the `userID` is a small integer, IDs are guessable and frequently exposed (e.g. a previously-public playlist that was later made private still has the same ID). This breaks the multi-user trust boundary of gonic: a low-privileged user can wipe an administrator's curated playlists, and a user can exfiltrate any private playlist they obtain an ID for. The issue was fixed in commit `6dd71e6a3c966867ef8c900d359a7df75789f410`, which is part of version 0.21.0. | Sun 25 Oct |
| CVE-2026-49339 | 7.1 high | 0.00% | no CPE yet | gonic is a music streaming server / free-software subsonic server API implementation. The maintainer's fix in commit `6dd71e6a3c966867ef8c900d359a7df75789f410` added an ownership check based on `playlist.UserID`. However, `playlist.UserID` is derived from the first path segment of the attacker-controlled playlist ID, with no path containment on the resolved file path. Any authenticated Subsonic user can therefore bypass the ownership check and read any other user's playlist, delete any other user's playlist, and probe arbitrary file paths on the host for existence/readability. This is a bypass of the boundary the `6dd71e6` fix is trying to enforce; it is closely related to the original GONIC-1 IDOR but uses a different primitive (path traversal in the `id` parameter rather than direct cross-user access). Commit 0824bed88f6bbc490ba28bf09d28e5dfeb07b445 in version 0.21.0 fixes the issue. | Sun 25 Oct |
| CVE-2026-56320 | 7.1 high | 0.00% | no CPE yet | Capgo before 12.128.2 contains an authorization flaw in POST /private/create_device that accepts a caller-supplied org_id parameter without validating it matches the target app's owner organization. Authenticated attackers can create device records for an application using a foreign organization identifier, bypassing the intended org/app authorization boundary. | Sun 25 Oct |
| CVE-2026-63550 | 7.1 high | 0.00% | no CPE yet | The MMS BER decoder contains a boundary-handling flaw in the processing of certain fields within confirmed-request messages. When a crafted BER-encoded element is received over an established MMS session (TCP port 102), the decoder may advance its internal read position incorrectly, leading to a heap out-of-bounds read. This condition causes the MMS handling process to terminate unexpectedly, resulting in a denial-of-service. | 23 Oct |
| CVE-2026-79976 | 7.1 high | 0.00% | no CPE yet | The MCTP-over-I2C+GPIO target binding in subsys/pmci/mctp/mctp_i2c_gpio_target.c emulates a small pseudo-register file, where the bus controller first writes a register number and then writes or reads payload bytes. The selected register (b->reg_addr) and the data-phase flag (b->rxtx) were never cleared when the controller issued an I2C STOP, so after a completed transfer the target still had a data register selected while the packet buffer that register refers to had already been consumed and set to NULL by mctp_i2c_gpio_target_stop(). A controller on the bus can re-enter the same branch of mctp_i2c_gpio_target_stop() with a NULL buffer using two ordinary transactions and no authentication: first a normal packet write to MCTP_I2C_GPIO_RX_MSG_ADDR followed by STOP (which delivers and frees b->rx_pkt), then a bare read transaction followed by STOP. The failing read_requested() call leaves the stale state untouched and the I2C driver still delivers the STOP callback, which then calls mctp_bus_rx() with a NULL packet. The symmetric case exists on the transmit side, where the stale MCTP_I2C_GPIO_TX_MSG_ADDR selection dereferences b->tx_pkt->end after b->tx_pkt has been cleared and additionally signals b->tx_complete a second time, causing the next outbound packet to be dropped. The dereference happens in the I2C target interrupt handler, so on any target that traps accesses to address 0 the result is a fatal exception and a device reset or halt — a denial of service inflicted by any device able to act as controller on the shared management bus (for example compromised firmware on a peer MCTP endpoint or on the BMC). On parts where address 0 is readable, the impact degrades to a malformed packet buffer being handed to the MCTP stack and lost transmit packets. No attacker-controlled value is written and no confidentiality or integrity boundary is crossed. The fix resets b->reg_addr to MCTP_I2C_GPIO_INVALID_ADDR and clears b->rxtx at every STOP, so a new register must be selected before any data phase can run again. Only builds that opt into the experimental CONFIG_MCTP subsystem with CONFIG_MCTP_I2C_GPIO_TARGET=y are affected. | 23 Oct |
| CVE-2026-90648 | 7.1 high | 0.00% | no CPE yet | wasm2c in WebAssembly wabt through 1.0.41 allows sandbox escape in some situations that primarily involve 32-bit platforms, aka a "table flip" attack. It does not check the return value of calloc() in wasm_rt_allocate_funcref_table() (wasm2c/wasm-rt-impl-tableops.inc). When the funcref table allocation fails, table->data is left NULL while table->size keeps the guest-declared element count; thus, bounds checks still pass and table element accesses resolve to absolute memory addresses (i * sizeof(wasm_rt_funcref_t)). This gives arbitrary read and write of host process memory and - via table.get, table.set, and call_indirect - arbitrary code execution, defeating the isolation that wasm2c exists to provide (a full sandbox escape). wasm2c is used as an in-process sandboxing boundary by RLBox and WasmBoxC, including in Firefox, which compiles the Graphite, Hunspell, Ogg, Expat, and Woff2 libraries via wasm2c to contain untrusted font, media, and XML input. Therefore, sandboxing in these applications is potentially affected. Exploitation requires the funcref table allocation to fail, for example under an address-space limit (RLIMIT_AS), on 32-bit hosts, with vm.overcommit_memory=2, or under memory pressure. On 64-bit Linux with default overcommit the allocation succeeds and the defect is not triggered. The wasm2c memory allocator aborts on calloc failure in the same runtime; the table allocator lacks this abort behavior. This was introduced in commit ab9e0b55 (PR #813). | 23 Oct |
| CVE-2026-46130 | 7.1 high | 0.00% | linux, linux_kernel | In the Linux kernel, the following vulnerability has been resolved: dm-verity-fec: fix reading parity bytes split across blocks (take 3) fec_decode_bufs() assumes that the parity bytes of the first RS codeword it decodes are never split across parity blocks. This assumption is false. Consider v->fec->block_size == 4096 && v->fec->roots == 17 && fio->nbufs == 1, for example. In that case, each call to fec_decode_bufs() consumes v->fec->roots * (fio->nbufs << DM_VERITY_FEC_BUF_RS_BITS) = 272 parity bytes. Considering that the parity data for each message block starts on a block boundary, the byte alignment in the parity data will iterate through 272*i mod 4096 until the 3 parity blocks have been consumed. On the 16th call (i=15), the alignment will be 4080 bytes into the first block. Only 16 bytes remain in that block, but 17 parity bytes will be needed. The code reads out-of-bounds from the parity block buffer. Fortunately this doesn't normally happen, since it can occur only for certain non-default values of fec_roots *and* when the maximum number of buffers couldn't be allocated due to low memory. For example with block_size=4096 only the following cases are affected: fec_roots=17: nbufs in [1, 3, 5, 15] fec_roots=19: nbufs in [1, 229] fec_roots=21: nbufs in [1, 3, 5, 13, 15, 39, 65, 195] fec_roots=23: nbufs in [1, 89] Regardless, fix it by refactoring how the parity blocks are read. | 21 Oct |
| CVE-2026-34118 | 7.1 high | 0.00% | tp-link, tapo_c520ws_firmware | A heap-based buffer overflow vulnerability was identified in TP-Link Tapo C100/C101 v5, C210 v3.6 and C520WS v2.6 in the HTTP POST body parsing logic due to missing validation of remaining buffer capacity after dynamic allocation, due to insufficient boundary validation when handling externally supplied HTTP input. An attacker on the same network segment could trigger heap memory corruption conditions by sending crafted payloads that cause write operations beyond allocated buffer boundaries. Successful exploitation causes a Denial-of-Service (DoS) condition, causing the device’s process to crash or become unresponsive. | 19 Oct |
| CVE-2026-64299 | 7.1 high | 0.00% | linux, linux_kernel | In the Linux kernel, the following vulnerability has been resolved: tracing: Prevent out-of-bounds read in glob matching String event fields are not necessarily NUL-terminated, so the filter predicate functions (filter_pred_string(), filter_pred_strloc() and filter_pred_strrelloc()) pass the field length to the regex match callbacks, and the length-aware matchers honour it. regex_match_glob() was the exception: it ignored the length and called glob_match(), which scans the string until it hits a NUL byte. Some string fields are not NUL-terminated. One example is the dynamic char array of the xfs_* namespace tracepoints, which is copied without a trailing NUL. For such a field, glob matching reads past the end of the event field, causing a KASAN slab-out-of-bounds read in glob_match(), reached via regex_match_glob() and filter_match_preds() from the xfs_lookup tracepoint. Add a length-bounded glob_match_len() and use it from regex_match_glob() so glob matching always stops at the field boundary. The matching loop is factored into a shared helper so glob_match() keeps its behaviour. | 19 Oct |
| CVE-2025-38677 | 7.1 high | 0.00% | linux, debian, linux_kernel, debian_linux | In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to avoid out-of-boundary access in dnode page As Jiaming Zhang reported: <TASK> __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x1c1/0x2a0 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0x17e/0x800 mm/kasan/report.c:480 kasan_report+0x147/0x180 mm/kasan/report.c:593 data_blkaddr fs/f2fs/f2fs.h:3053 [inline] f2fs_data_blkaddr fs/f2fs/f2fs.h:3058 [inline] f2fs_get_dnode_of_data+0x1a09/0x1c40 fs/f2fs/node.c:855 f2fs_reserve_block+0x53/0x310 fs/f2fs/data.c:1195 prepare_write_begin fs/f2fs/data.c:3395 [inline] f2fs_write_begin+0xf39/0x2190 fs/f2fs/data.c:3594 generic_perform_write+0x2c7/0x910 mm/filemap.c:4112 f2fs_buffered_write_iter fs/f2fs/file.c:4988 [inline] f2fs_file_write_iter+0x1ec8/0x2410 fs/f2fs/file.c:5216 new_sync_write fs/read_write.c:593 [inline] vfs_write+0x546/0xa90 fs/read_write.c:686 ksys_write+0x149/0x250 fs/read_write.c:738 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xf3/0x3d0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f The root cause is in the corrupted image, there is a dnode has the same node id w/ its inode, so during f2fs_get_dnode_of_data(), it tries to access block address in dnode at offset 934, however it parses the dnode as inode node, so that get_dnode_addr() returns 360, then it tries to access page address from 360 + 934 * 4 = 4096 w/ 4 bytes. To fix this issue, let's add sanity check for node id of all direct nodes during f2fs_get_dnode_of_data(). | 19 Oct |
| CVE-2026-46078 | 7.1 high | 0.00% | linux, linux_kernel | In the Linux kernel, the following vulnerability has been resolved: erofs: fix the out-of-bounds nameoff handling for trailing dirents Currently we already have boundary-checks for nameoffs, but the trailing dirents are special since the namelens are calculated with strnlen() with unchecked nameoffs. If a crafted EROFS has a trailing dirent with nameoff >= maxsize, maxsize - nameoff can underflow, causing strnlen() to read past the directory block. nameoff0 should also be verified to be a multiple of `sizeof(struct erofs_dirent)` as well [1]. [1] https://sashiko.dev/#/patchset/20260416063511.3173774-1-hsiangkao%40linux.alibaba.com | 19 Oct |
| CVE-2026-46070 | 7.1 high | 0.00% | linux, linux_kernel | In the Linux kernel, the following vulnerability has been resolved: md/raid5: validate payload size before accessing journal metadata r5c_recovery_analyze_meta_block() and r5l_recovery_verify_data_checksum_for_mb() iterate over payloads in a journal metadata block using on-disk payload size fields without validating them against the remaining space in the metadata block. A corrupted journal contains payload sizes extending beyond the PAGE_SIZE boundary can cause out-of-bounds reads when accessing payload fields or computing offsets. Add bounds validation for each payload type to ensure the full payload fits within meta_size before processing. | 19 Oct |
| CVE-2025-68753 | 7.1 high | 0.00% | no CPE yet | In the Linux kernel, the following vulnerability has been resolved: ALSA: firewire-motu: add bounds check in put_user loop for DSP events In the DSP event handling code, a put_user() loop copies event data. When the user buffer size is not aligned to 4 bytes, it could overwrite beyond the buffer boundary. Fix by adding a bounds check before put_user(). | 19 Oct |
| CVE-2022-50200 | 7.1 high | 0.00% | linux, linux_kernel | In the Linux kernel, the following vulnerability has been resolved: selinux: Add boundary check in put_entry() Just like next_entry(), boundary check is necessary to prevent memory out-of-bound access. | 15 Oct |
Download these 567 as CSV · subscribe to this list.
EPSS scores: 2026-10-30. NVD cursor: 2026-10-29 00:22. The News page shows only notable CVEs (KEV, your stack, new criticals, EPSS over 50%, or active exploitation per SSVC); this table has all of them.