Export limit exceeded: 44126 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (44126 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2026-31478 | 1 Linux | 1 Linux Kernel | 2026-04-27 | 9.8 Critical |
| In the Linux kernel, the following vulnerability has been resolved: ksmbd: replace hardcoded hdr2_len with offsetof() in smb2_calc_max_out_buf_len() After this commit (e2b76ab8b5c9 "ksmbd: add support for read compound"), response buffer management was changed to use dynamic iov array. In the new design, smb2_calc_max_out_buf_len() expects the second argument (hdr2_len) to be the offset of ->Buffer field in the response structure, not a hardcoded magic number. Fix the remaining call sites to use the correct offsetof() value. | ||||
| CVE-2025-43447 | 1 Apple | 5 Ios, Ipados, Iphone Os and 2 more | 2026-04-27 | 5.5 Medium |
| The issue was addressed with improved memory handling. This issue is fixed in iOS 26.1 and iPadOS 26.1, macOS Tahoe 26.1, visionOS 26.1, watchOS 26.1. An app may be able to cause unexpected system termination or corrupt kernel memory. | ||||
| CVE-2025-43205 | 1 Apple | 6 Ios, Ipados, Iphone Os and 3 more | 2026-04-27 | 4 Medium |
| An out-of-bounds access issue was addressed with improved bounds checking. This issue is fixed in iOS 18.4 and iPadOS 18.4, iPadOS 17.7.6, macOS Sequoia 15.4, macOS Sonoma 14.7.5, macOS Ventura 13.7.5, tvOS 18.4, visionOS 2.4, watchOS 11.4. An app may be able to bypass ASLR. | ||||
| CVE-2025-43374 | 1 Apple | 9 Ios, Ipados, Iphone Os and 6 more | 2026-04-27 | 4.3 Medium |
| An out-of-bounds read was addressed with improved bounds checking. This issue is fixed in iOS 18.5 and iPadOS 18.5, iPadOS 17.7.7, macOS Sequoia 15.5, macOS Sonoma 14.7.3, macOS Ventura 13.7.3, tvOS 18.5, visionOS 2.5, watchOS 11.5. An attacker in physical proximity may be able to cause an out-of-bounds read in kernel memory. | ||||
| CVE-2025-43520 | 1 Apple | 11 Ios, Ipad Os, Ipados and 8 more | 2026-04-27 | 5.5 Medium |
| A memory corruption issue was addressed with improved memory handling. This issue is fixed in iOS 18.7.2 and iPadOS 18.7.2, iOS 26.1 and iPadOS 26.1, macOS Sequoia 15.7.2, macOS Sonoma 14.8.2, macOS Tahoe 26.1, tvOS 26.1, visionOS 26.1, watchOS 26.1. A malicious application may be able to cause unexpected system termination or write kernel memory. | ||||
| CVE-2025-46285 | 1 Apple | 3 Macos, Macos Sequoia, Macos Sonoma | 2026-04-27 | 7.8 High |
| An integer overflow was addressed by adopting 64-bit timestamps. This issue is fixed in iOS 18.7.3 and iPadOS 18.7.3, iOS 26.2 and iPadOS 26.2, macOS Sequoia 15.7.3, macOS Sonoma 14.8.3, macOS Tahoe 26.2, tvOS 26.2, visionOS 26.2, watchOS 26.2. An app may be able to gain root privileges. | ||||
| CVE-2025-43539 | 1 Apple | 3 Macos, Macos Sequoia, Macos Sonoma | 2026-04-27 | 8.8 High |
| The issue was addressed with improved bounds checks. This issue is fixed in iOS 18.7.3 and iPadOS 18.7.3, iOS 26.2 and iPadOS 26.2, macOS Sequoia 15.7.3, macOS Sonoma 14.8.3, macOS Tahoe 26.2, tvOS 26.2, visionOS 26.2, watchOS 26.2. Processing a file may lead to memory corruption. | ||||
| CVE-2025-43467 | 1 Apple | 2 Macos, Macos Tahoe | 2026-04-27 | 7.8 High |
| This issue was addressed with improved checks. This issue is fixed in macOS Tahoe 26.1. An app may be able to gain root privileges. | ||||
| CVE-2025-46316 | 1 Apple | 6 Ios, Ipados, Iphone Os and 3 more | 2026-04-27 | 4.3 Medium |
| An out-of-bounds read was addressed with improved input validation. This issue is fixed in Pages 15.1, iOS 26.1 and iPadOS 26.1, macOS Tahoe 26.1. Processing a maliciously crafted Pages document may result in unexpected termination or disclosure of process memory. | ||||
| CVE-2025-46305 | 1 Apple | 4 Ios And Ipados, Ipados, Iphone Os and 1 more | 2026-04-27 | 5.7 Medium |
| The issue was addressed with improved bounds checks. This issue is fixed in iOS 18.7.5 and iPadOS 18.7.5, iOS 26.2 and iPadOS 26.2, macOS Sequoia 15.7.4, macOS Sonoma 14.8.4, macOS Tahoe 26.2, tvOS 26.2, visionOS 26.2, watchOS 26.2. A malicious HID device may cause an unexpected process crash. | ||||
| CVE-2025-46303 | 1 Apple | 4 Ios And Ipados, Ipados, Iphone Os and 1 more | 2026-04-27 | 5.7 Medium |
| The issue was addressed with improved bounds checks. This issue is fixed in iOS 18.7.5 and iPadOS 18.7.5, iOS 26.2 and iPadOS 26.2, macOS Sequoia 15.7.4, macOS Sonoma 14.8.4, macOS Tahoe 26.2, tvOS 26.2, visionOS 26.2, watchOS 26.2. A malicious HID device may cause an unexpected process crash. | ||||
| CVE-2026-41318 | 1 Mintplexlabs | 2 Anything-llm, Anythingllm | 2026-04-27 | 5.4 Medium |
| AnythingLLM is an application that turns pieces of content into context that any LLM can use as references during chatting. Prior to version 1.12.1, AnythingLLM's in-chat markdown renderer has an unsafe custom rule for images that interpolates the markdown image's `alt` text into an HTML `alt="..."` attribute without any HTML encoding. Every call-site in the app wraps `renderMarkdown(...)` with `DOMPurify.sanitize(...)` as defense-in-depth — except the `Chartable` component, which renders chart captions with no sanitization. The chart caption is the natural-language text the LLM emits around a `create-chart` tool call, so any attacker who can influence the LLM's output — most cheaply via indirect prompt injection in a shared workspace document, or directly if they can create a chart record in a multi-user workspace — can trigger stored DOM-level XSS in every other user's browser when they open that conversation. AnythingLLM chat history is loaded server-side via `GET /api/workspace/:slug/chats` and rendered directly into the chat UI. Version 1.12.1 contains a patch for this issue. | ||||
| CVE-2026-31570 | 1 Linux | 1 Linux Kernel | 2026-04-27 | 8.8 High |
| In the Linux kernel, the following vulnerability has been resolved: can: gw: fix OOB heap access in cgw_csum_crc8_rel() cgw_csum_crc8_rel() correctly computes bounds-safe indices via calc_idx(): int from = calc_idx(crc8->from_idx, cf->len); int to = calc_idx(crc8->to_idx, cf->len); int res = calc_idx(crc8->result_idx, cf->len); if (from < 0 || to < 0 || res < 0) return; However, the loop and the result write then use the raw s8 fields directly instead of the computed variables: for (i = crc8->from_idx; ...) /* BUG: raw negative index */ cf->data[crc8->result_idx] = ...; /* BUG: raw negative index */ With from_idx = to_idx = result_idx = -64 on a 64-byte CAN FD frame, calc_idx(-64, 64) = 0 so the guard passes, but the loop iterates with i = -64, reading cf->data[-64], and the write goes to cf->data[-64]. This write might end up to 56 (7.0-rc) or 40 (<= 6.19) bytes before the start of the canfd_frame on the heap. The companion function cgw_csum_xor_rel() uses `from`/`to`/`res` correctly throughout; fix cgw_csum_crc8_rel() to match. Confirmed with KASAN on linux-7.0-rc2: BUG: KASAN: slab-out-of-bounds in cgw_csum_crc8_rel+0x515/0x5b0 Read of size 1 at addr ffff8880076619c8 by task poc_cgw_oob/62 To configure the can-gw crc8 checksums CAP_NET_ADMIN is needed. | ||||
| CVE-2026-31569 | 1 Linux | 1 Linux Kernel | 2026-04-27 | 7.3 High |
| In the Linux kernel, the following vulnerability has been resolved: LoongArch: KVM: Handle the case that EIOINTC's coremap is empty EIOINTC's coremap in eiointc_update_sw_coremap() can be empty, currently we get a cpuid with -1 in this case, but we actually need 0 because it's similar as the case that cpuid >= 4. This fix an out-of-bounds access to kvm_arch::phyid_map::phys_map[]. | ||||
| CVE-2026-31568 | 1 Linux | 1 Linux Kernel | 2026-04-27 | 7.1 High |
| In the Linux kernel, the following vulnerability has been resolved: s390/mm: Add missing secure storage access fixups for donated memory There are special cases where secure storage access exceptions happen in a kernel context for pages that don't have the PG_arch_1 bit set. That bit is set for non-exported guest secure storage (memory) but is absent on storage donated to the Ultravisor since the kernel isn't allowed to export donated pages. Prior to this patch we would try to export the page by calling arch_make_folio_accessible() which would instantly return since the arch bit is absent signifying that the page was already exported and no further action is necessary. This leads to secure storage access exception loops which can never be resolved. With this patch we unconditionally try to export and if that fails we fixup. | ||||
| CVE-2026-31630 | 1 Linux | 1 Linux Kernel | 2026-04-27 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: rxrpc: proc: size address buffers for %pISpc output The AF_RXRPC procfs helpers format local and remote socket addresses into fixed 50-byte stack buffers with "%pISpc". That is too small for the longest current-tree IPv6-with-port form the formatter can produce. In lib/vsprintf.c, the compressed IPv6 path uses a dotted-quad tail not only for v4mapped addresses, but also for ISATAP addresses via ipv6_addr_is_isatap(). As a result, a case such as [ffff:ffff:ffff:ffff:0:5efe:255.255.255.255]:65535 is possible with the current formatter. That is 50 visible characters, so 51 bytes including the trailing NUL, which does not fit in the existing char[50] buffers used by net/rxrpc/proc.c. Size the buffers from the formatter's maximum textual form and switch the call sites to scnprintf(). Changes since v1: - correct the changelog to cite the actual maximum current-tree case explicitly - frame the proof around the ISATAP formatting path instead of the earlier mapped-v4 example | ||||
| CVE-2026-31633 | 1 Linux | 1 Linux Kernel | 2026-04-27 | 9.8 Critical |
| In the Linux kernel, the following vulnerability has been resolved: rxrpc: Fix integer overflow in rxgk_verify_response() In rxgk_verify_response(), there's a potential integer overflow due to rounding up token_len before checking it, thereby allowing the length check to be bypassed. Fix this by checking the unrounded value against len too (len is limited as the response must fit in a single UDP packet). | ||||
| CVE-2026-31635 | 1 Linux | 1 Linux Kernel | 2026-04-27 | 7.5 High |
| In the Linux kernel, the following vulnerability has been resolved: rxrpc: fix oversized RESPONSE authenticator length check rxgk_verify_response() decodes auth_len from the packet and is supposed to verify that it fits in the remaining bytes. The existing check is inverted, so oversized RESPONSE authenticators are accepted and passed to rxgk_decrypt_skb(), which can later reach skb_to_sgvec() with an impossible length and hit BUG_ON(len). Decoded from the original latest-net reproduction logs with scripts/decode_stacktrace.sh: RIP: __skb_to_sgvec() [net/core/skbuff.c:5285 (discriminator 1)] Call Trace: skb_to_sgvec() [net/core/skbuff.c:5305] rxgk_decrypt_skb() [net/rxrpc/rxgk_common.h:81] rxgk_verify_response() [net/rxrpc/rxgk.c:1268] rxrpc_process_connection() [net/rxrpc/conn_event.c:266 net/rxrpc/conn_event.c:364 net/rxrpc/conn_event.c:386] process_one_work() [kernel/workqueue.c:3281] worker_thread() [kernel/workqueue.c:3353 kernel/workqueue.c:3440] kthread() [kernel/kthread.c:436] ret_from_fork() [arch/x86/kernel/process.c:164] Reject authenticator lengths that exceed the remaining packet payload. | ||||
| CVE-2026-31561 | 1 Linux | 1 Linux Kernel | 2026-04-27 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: x86/cpu: Remove X86_CR4_FRED from the CR4 pinned bits mask Commit in Fixes added the FRED CR4 bit to the CR4 pinned bits mask so that whenever something else modifies CR4, that bit remains set. Which in itself is a perfectly fine idea. However, there's an issue when during boot FRED is initialized: first on the BSP and later on the APs. Thus, there's a window in time when exceptions cannot be handled. This becomes particularly nasty when running as SEV-{ES,SNP} or TDX guests which, when they manage to trigger exceptions during that short window described above, triple fault due to FRED MSRs not being set up yet. See Link tag below for a much more detailed explanation of the situation. So, as a result, the commit in that Link URL tried to address this shortcoming by temporarily disabling CR4 pinning when an AP is not online yet. However, that is a problem in itself because in this case, an attack on the kernel needs to only modify the online bit - a single bit in RW memory - and then disable CR4 pinning and then disable SM*P, leading to more and worse things to happen to the system. So, instead, remove the FRED bit from the CR4 pinning mask, thus obviating the need to temporarily disable CR4 pinning. If someone manages to disable FRED when poking at CR4, then idt_invalidate() would make sure the system would crash'n'burn on the first exception triggered, which is a much better outcome security-wise. | ||||
| CVE-2026-6843 | 1 Redhat | 4 Enterprise Linux, Nano, Openshift and 1 more | 2026-04-27 | 5.5 Medium |
| A flaw was found in nano. A local user could exploit a format string vulnerability in the `statusline()` function. By creating a directory with a name containing `printf` specifiers, the application attempts to display this name, leading to a segmentation fault (SEGV). This results in a Denial of Service (DoS) for the `nano` application. | ||||