Export limit exceeded: 417581 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (417581 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2026-85829 | 1 Microsoft | 28 Windows 10 1607, Windows 10 1809, Windows 10 21h2 and 25 more | 2026-10-29 | 7.8 High |
| Double free in Windows Wired AutoConfig Service allows an authorized attacker to elevate privileges locally. | ||||
| CVE-2026-85830 | 1 Microsoft | 28 Windows 10 1607, Windows 10 1809, Windows 10 21h2 and 25 more | 2026-10-29 | 5.5 Medium |
| Out-of-bounds read in Windows Installer allows an authorized attacker to disclose information locally. | ||||
| CVE-2026-85831 | 1 Microsoft | 20 Windows 10 1809, Windows 10 21h2, Windows 10 21h2 and 17 more | 2026-10-29 | 5.5 Medium |
| Heap-based buffer overflow in Windows Biometric Service allows an authorized attacker to disclose information locally. | ||||
| CVE-2026-85832 | 1 Microsoft | 28 Windows 10 1607, Windows 10 1809, Windows 10 21h2 and 25 more | 2026-10-29 | 7.8 High |
| Heap-based buffer overflow in Windows Background Intelligent Transfer Service (BITS) allows an authorized attacker to elevate privileges locally. | ||||
| CVE-2026-98995 | 1 Linux | 2 Linux, Linux Kernel | 2026-10-29 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: namespace: reset the old parent's ->overmount in mnt_change_mountpoint() __umount_mnt() resets ->overmount of the parent when it unmounts the mount that overmounts it. mnt_change_mountpoint() doesn't. It moves the mount to its new parent and leaves the old one pointing at it. For a mount that is moved beneath in attach_recursive_mnt() that doesn't matter. The new mount has already reset ->overmount of the old parent by the time the old top mount is moved onto it. It matters for reparent() though. propagate_umount() moves a surviving overmount onto the first ancestor that isn't going to be unmounted. The mount it was taken from is unmounted immediately afterwards. If a file descriptor keeps that unmounted mount alive ->overmount points at the moved mount. That's a dangling pointer and UAF as the moved mount is unmounted and freed. do_lock_mount() follows ->overmount from the target path under mount_lock. With a file descriptor on such a mount as the target of a mount beneath topmost_overmount() walks into the freed mount and do_lock_mount() takes references on whatever it finds there. So reset ->overmount of the old parent in mnt_change_mountpoint() the same way __umount_mnt() does. A mount's ->overmount is then always a mount that is attached to it. | ||||
| CVE-2026-98996 | 1 Linux | 2 Linux, Linux Kernel | 2026-10-29 | 2.5 Low |
| In the Linux kernel, the following vulnerability has been resolved: fs: don't silently unmount busy mounts The propagate_mount_busy() helper exists to decide whether a synchronous can suceed. It does that by looking at the copies of the victims in the mounts its parent propagates to. One of those functions from propagation hell. It skips a copy that has child mounts except for the case of a single child mount covering the copy's root. That algorithm used to be exact. It isn't anymore. Originally only childless copies were unmounted during propagation. And 1064f874abc0 ("mnt: Tuck mounts under others instead of creating shadow/side mounts.") ended up adding covered mounts to both sides in one go. Along came 99b19d16471e ("mnt: In propgate_umount handle visiting mounts in any order") and that started to unmount more than before: [1]: A copy of a mount is unmounted when each of its children is either its overmount or a copy of the victim itself. In the former case the overmount gets reparented. In the latter case the copy of the victim will end up being unmounted. So propagate_umount() ended up being rewritten without adjusting propagate_mount_busy(). And currently propagate_mount_busy() doesn't look at copies of the victim that have two or more children nor a single child that is not the overmount. So any such copy in [1] is not checked for references. The result is that a synchronous unmount succeeds, pulling out a mount that is still in use. A container can run into this with its own mounts. The host shares a tree with the container and the host has a mount in that tree: mount -t tmpfs none /mnt mount --make-shared /mnt mount -t tmpfs none /mnt/a The container's /mnt is a slave copy of the host mount. The container now takes a detached copy of the tree and mounts that copy beneath its propagated copy of /mnt/a and keeps the file descriptor to the tree open: unshare -m --propagation unchanged mount --make-rslave / fd = open_tree(AT_FDCWD, "/mnt", OPEN_TREE_CLONE | AT_RECURSIVE) move_mount(fd, "", AT_FDCWD, "/mnt/a", MOVE_MOUNT_BENEATH) grep /mnt /proc/self/mountinfo 775 355 ... /mnt ... master:646 777 775 ... /mnt/a ... master:646 776 777 ... /mnt/a ... master:647 778 777 ... /mnt/a/a ... master:647 The now attached tree (777) is now mounted beneath the container's copy of /mnt/a. That's also where the host mount sits (as seen from the host mount namespace). So the propagated copy (776) of the host's mount is on top of its root and the copy of that (778) is inside it. Now the host runs: umount /mnt/a and it succeeds. The moved tree tree and the copy inside of it are gone from the container. Now only the propagated copy is left and it got reparented to where it was before: grep /mnt /proc/self/mountinfo 775 355 ... /mnt ... master:646 776 775 ... /mnt/a ... But the file descriptor still refers to the moved tree. So a synchronous umount detached a mount that is still in use. Teach propagate_mount_busy() the same checks that propagate_umount() does. It now checks for a single victim mount without children for which it can assume that MNT_LOCKED is cleared on every copy like propagate_umount() does. The copies form chains. IOW, when a copy itself receives propagation from the victim's parent then the mount at the same mountpoint inside that copy is a copy as well. Whether a mount receives propagation from the victim's can simply be checked by walking its masters. Walk each chain once from its top so we are sure that nested copies stay linear. Check every reference once of every copy that gets unmounted. | ||||
| CVE-2026-98997 | 1 Linux | 2 Linux, Linux Kernel | 2026-10-29 | 4.4 Medium |
| In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/userq: only accept doorbell BOs as queue doorbell amdgpu_userq_get_doorbell_index() pins any BO passed as doorbell_handle into the doorbell domain. For a regular BO, TTM moves it with ttm_bo_move_null() and its contents are lost. Since an importer on the same device gets the exporter's GEM object, a client can do this to a buffer another client shared with it. Reject BOs that were not created in the doorbell domain. v2: drop the error message, use a local abo variable (Christian) (cherry picked from commit f7497bbc19db4821c62b9d97b31c9086feb2d917) | ||||
| CVE-2026-98998 | 1 Linux | 2 Linux, Linux Kernel | 2026-10-29 | 4.4 Medium |
| In the Linux kernel, the following vulnerability has been resolved: drm/bridge: th1520-dw-hdmi: Fix remove() callback This driver stores struct th1520_hdmi * in platform drvdata, but th1520_dw_hdmi_remove() was reading it back as struct dw_hdmi * and passing it to dw_hdmi_remove(), so teardown runs on the wrong pointer. Retrieve struct th1520_hdmi * from platform drvdata and pass hdmi->dw_hdmi to dw_hdmi_remove(). | ||||
| CVE-2026-107025 | 2026-10-29 | N/A | ||
| Insecure permissions in WikiAndPad alpha/beta v0.2alpha03 (versionCode 200300) allows unauthorized attackers to export the application's data. | ||||
| CVE-2026-51851 | 2026-10-29 | N/A | ||
| modelscope agent-zero 1.7, 1.8, 1.9, and 1.10 is vulnerable to Directory Traversal in python/helpers/file_browser.py:FileBrowser.save_text_file. The save_text_file method accepts user-controlled file paths without normalization or validation, allowing path traversal attacks. | ||||
| CVE-2026-119119 | 1 Unclecode | 1 Crawl4ai | 2026-10-29 | 7.5 High |
| Crawl4AI before 0.9.5 contains a denial of service vulnerability in the Docker API server where _clamp_untrusted() fails to cap the delay_before_return_html, mean_delay, and max_range fields of untrusted CrawlerRunConfig bodies. Unauthenticated attackers can send huge values to /crawl or /crawl/stream to hold browser pages or stall the rate limiter, exhausting the page pool and blocking other crawls. | ||||
| CVE-2026-119120 | 1 Unclecode | 1 Crawl4ai | 2026-10-29 | 7.5 High |
| Crawl4AI from 0.9.0 before 0.9.5 fails to filter the CosineStrategy model_name field in untrusted Docker API request bodies, allowing authenticated clients to choose which HuggingFace model the server loads. Attackers can reference a malicious repository with a pickle weight file to execute Python code under PyTorch below 2.6, or exhaust disk and memory. | ||||
| CVE-2026-119121 | 1 Unclecode | 1 Crawl4ai | 2026-10-29 | 4.3 Medium |
| Crawl4AI from 0.9.0 before 0.9.5 contains a JavaScript injection vulnerability in the Docker API server that allows authenticated API clients to run arbitrary JavaScript in the crawl page via allowlisted css_selector and wait_for fields. Attackers can inject quotes into css_selector or supply js: conditions in wait_for, bypassing the js_code block to alter page state and returned crawl content. | ||||
| CVE-2026-119123 | 1 Imagemagick | 1 Imagemagick | 2026-10-29 | 3.7 Low |
| ImageMagick before 7.1.2-34 contains a stack overflow vulnerability in the TIFF decoder that occurs when the DNG decoder is disabled. Attackers can supply a crafted image file for processing to trigger the stack overflow and crash the application, causing denial of service. | ||||
| CVE-2026-119124 | 1 Imagemagick | 1 Imagemagick | 2026-10-29 | 3.3 Low |
| ImageMagick before 7.1.2-34 contains a heap-based buffer overflow in its -morph processing, where crafted images cause writes beyond the bounds of a heap buffer. An attacker can supply a crafted image that, when processed by a user with the -morph option, corrupts heap memory and crashes the application. | ||||
| CVE-2026-119125 | 2 Parse Community, Parseplatform | 2 Parse Server, Parse-server | 2026-10-29 | 3.1 Low |
| Parse Server before 8.6.107 and 9.0.0 before 9.10.5-alpha.8 returns the stored value of a field reverted by a beforeSave trigger in object update responses, even to clients without read access to that object or field. An authenticated client able to update an object whose beforeSave trigger reverts a field, via revert() or a constant: true validator, can read protected values, including its own account's raw MFA authData when protectedFieldsTriggerExempt is enabled. | ||||
| CVE-2026-119133 | 1 Bytecodealliance | 1 Wasmtime | 2026-10-29 | 2.6 Low |
| Wasmtime 47.0.0 before 48.0.6 and 49.0.0 before 49.0.3 contains a memory misalignment flaw in VMContext layout that causes undefined behavior when modules contain an odd number of exception tags. A WebAssembly module with an odd tag count misaligns subsequent host fields in embedders with exceptions enabled, although no exploitation path is currently known. | ||||
| CVE-2026-119136 | 1 Bytecodealliance | 1 Wasmtime | 2026-10-29 | 4.8 Medium |
| Wasmtime 42.0.0 before 48.0.6 and 49.0.0 before 49.0.3 contains insufficient checks in Store when mixing async-style and sync-style WebAssembly calls. Embedders re-entering WebAssembly via sync APIs from host functions called asynchronously can trigger runtime panics or unsound cross-thread movement of !Send host variables. | ||||
| CVE-2026-119137 | 1 Bytecodealliance | 1 Wasmtime | 2026-10-29 | 5.3 Medium |
| Wasmtime 42.0.0 before 48.0.6 and 49.0.0 before 49.0.3 contains a stack overflow vulnerability that allows guests to crash the host through recursive type drops. Guests can define a long chain of recursive types so that removing the top-level type triggers unbounded recursive drops, exhausting the host stack. | ||||
| CVE-2026-119139 | 1 Bytecodealliance | 1 Wasmtime | 2026-10-29 | 4.8 Medium |
| Wasmtime 46.0.0 before 48.0.6 and 49.0.0 before 49.0.3 contains a leftover assertion in component::Func::call that rejects guest exports using the async ABI option. An attacker who supplies a component with an async-lifted export can crash the host process when an embedder invokes that export through Func::call. | ||||