Export limit exceeded: 416849 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (416849 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2026-98952 | 1 Linux | 2 Linux, Linux Kernel | 2026-10-29 | 7.3 High |
| In the Linux kernel, the following vulnerability has been resolved: pfcp: make sure the SEID is linear before reading it pfcp_encap_recv() only makes sure that the UDP header and the 4 byte PFCP header are in the linear area. When the S flag is set, pfcp_session_recv() then reads the 8 byte SEID that follows, which is not covered by the pskb_may_pull() check. A short PFCP packet with the S flag set, or one whose session header lies in a fragment, therefore makes pfcp_session_recv() read beyond the end of the packet data, and whatever it finds there is stored in the tunnel metadata that flower later classifies on. Pull up to the end of the SEID before reading it, and drop packets that are too short to contain it. Reload the header pointer afterwards since pskb_may_pull() may reallocate the skb head. Use offsetofend() rather than sizeof(struct pfcphdr_session): the structure is not packed, so its size is 16 bytes because of the alignment of the __be64 member, while the header on the wire is only 12 bytes, and valid session messages would be dropped. | ||||
| CVE-2026-98955 | 1 Linux | 2 Linux, Linux Kernel | 2026-10-29 | 5.9 Medium |
| In the Linux kernel, the following vulnerability has been resolved: flow_dissector: avoid u16 truncation of skb->len when computing thoff __skb_flow_dissect() computes key_control->thoff using: key_control->thoff = min_t(u16, nhoff, skb ? skb->len : hlen); min_t(u16, ...) casts both arguments to u16 before comparing them. Whenever skb->len (or hlen) modulo 65536 is smaller than nhoff, the truncated length wins and thoff is set to a bogus small value, even when the dissection succeeded. For example, an IPv4/TCP frame with skb->len == 65540 and nhoff == 34 gets thoff == 4, so callers such as skb_probe_transport_header() point the transport header inside the Ethernet header. Such skbs are not exotic: - At the time of commit d0c081b49137 ("flow_dissector: properly cap thoff field"), AF_PACKET with PACKET_VNET_HDR could already build GSO skbs larger than 64KB (MTU checks are skipped for GSO, and alloc_skb_with_frags() accepted up to MAX_SKB_FRAGS (17) order-0 pages on top of the linear part). - BIG TCP now makes skbs larger than 64KB common. - The following patch makes tun_get_user() dissect IFF_TAP frames before eth_type_trans() pulls the Ethernet header, so a GSO frame carrying a 65522..65535 byte L3 packet will be dissected with skb->len in [65536, 65549]. Compare as u32 instead. If the resulting offset cannot be represented in the u16 key_control->thoff, cap it to U16_MAX and report the dissection as failed rather than silently returning a wrong transport offset. thoff is still set on failure, as some callers (such as eth_get_headlen()) use it regardless of the return value. | ||||
| CVE-2026-98962 | 1 Linux | 2 Linux, Linux Kernel | 2026-10-29 | 3.3 Low |
| In the Linux kernel, the following vulnerability has been resolved: btrfs: free iov when btrfs_uring_read_extent() fails After btrfs_uring_read_extent(), the caller always jumped to out_acct. That skips kfree(data->iov), which is only correct for -EIOCBQUEUED where the deferred path owns the iov. On failure, fall through to out_free instead. | ||||
| CVE-2026-98964 | 1 Linux | 2 Linux, Linux Kernel | 2026-10-29 | 7.5 High |
| In the Linux kernel, the following vulnerability has been resolved: nvmet: use the local P2P device on metadata allocation failure nvmet_req_alloc_p2pmem_sgls() assigns req->p2p_dev only after the data and metadata SGL allocations succeed. If the data allocation succeeds but the metadata allocation fails, out_free_sg passes req->p2p_dev to pci_p2pmem_free_sgl() before that assignment has taken place. Pass the local p2p_dev argument instead, so cleanup uses the same PCI device as the successful data allocation. | ||||
| CVE-2026-98988 | 1 Linux | 2 Linux, Linux Kernel | 2026-10-29 | 8.8 High |
| In the Linux kernel, the following vulnerability has been resolved: namespace: keep covered mounts covered in OPEN_TREE_NAMESPACE open_tree(OPEN_TREE_NAMESPACE) creates a new mount namespace from a copy of the tree at the given path. The caller needs to be privileged over its current user namespace because the new mount namespace will be owned by it. It doesn't need to be privileged over the mount namespace the tree is copied from. An unprivileged user just needs to create a user namespace first. The copy follows the rules of a detached bind mount. Without AT_RECURSIVE only the mount itself is cloned and its children are left out. With AT_RECURSIVE unbindable mounts are skipped. Both is fine when the caller has privileges over the source mount namespace because it could unmount those mounts anyway. Not so for an unprivileged user in that mount namespace. For them a mount namespace copy is what unshare() does. copy_mnt_ns() copies everything including unbindable mounts and lock_mnt_tree() makes sure nothing can be unmounted in the copy. Nothing that was covered gets revealed. create_new_namespace() only does the locking and so the covered content is right there in the new mount namespace: # mount -t tmpfs none /tmp/otn; mkdir /tmp/otn/covered # echo hidden > /tmp/otn/covered/under.txt # mount -t tmpfs none /tmp/otn/covered uid 1000, after unshare(CLONE_NEWUSER): fd = open_tree(AT_FDCWD, "/tmp/otn", OPEN_TREE_NAMESPACE); setns(fd, CLONE_NEWNS); open("/covered/under.txt", O_RDONLY) -> "hidden" Covering paths with mounts is how container runtimes mask parts of /proc and /sys and how admins hide things. When the caller's user namespace doesn't own the source mount namespace copy the way unshare() does and refuse a non-recursive copy of a mount that has anything mounted below the requested directory and copy unbindable mounts in a recursive copy. A caller that is privileged over the source mount namespace sees no change. | ||||
| CVE-2026-98989 | 1 Linux | 2 Linux, Linux Kernel | 2026-10-29 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: namespace: check a recursive bind mount for mount namespace loops do_loopback() refuses to bind mount the file of a mount namespace that is as old as the caller's or older because a mount namespace that holds a mount of its own file, or of an ancestor's, would cause a cycle. But it only checks the dentry the bind mount starts from. With MS_REC everything below it is copied and do_loopback() passes CL_COPY_MNT_NS_FILE so mount namespace files below the source are copied. That's fine for a source in the caller's own mount namespace. Every mount namespace file in there passed the same check when it was bind-mounted. It isn't fine for a source in another mount namespace. may_copy_tree() accepts a bind mount of any nsfs or pidfs file no matter what mount namespace it lives in so that /proc/<pid>/ns/<ns> and pidfds can be bind mounted. If we create a bind-mount stack of mount namespaces file descriptors the kernel will copy them irrespective of their ancestoral relationship to the mount namespace in question: 151 146 0:7 net:[4026531833] /tmp/nrc/y rw - nsfs nsfs rw 152 151 0:7 mnt:[4026532293] /tmp/nrc/y rw - nsfs nsfs rw Mount 152 is a mount of the mount namespace file of mount namespace 4026532293 inside mount namespace 4026532293. That namespace and every mount in it are leaked... All it takes is a process in an older mount namespace that stacks the file and repeating it leaks without limit: after control: Shmem: 380 kB child: mount(/proc/self/fd/6, MS_BIND|MS_REC): ok after cycle: Shmem: 65916 kB do_move_mount() runs check_for_nsfs_mounts() over a detached tree for exactly that reason. Do the same for the copy before it is grafted. | ||||
| CVE-2026-112484 | 1 Apple | 1 Macos | 2026-10-29 | 7.8 High |
| This issue was addressed with improved file handling. This issue is fixed in macOS Golden Gate 27.2, macOS Sequoia 15.8.2, macOS Tahoe 26.7.2. A malicious application may be able to execute arbitrary code with system privileges. | ||||
| CVE-2026-115795 | 1 Rt-labs | 1 P-net | 2026-10-29 | N/A |
| P-Net before 1.0.3 does not check that a complete block header is present in the received data before reading the next block in DCP Set and Identify requests. If the last block ends at the end of the receive buffer, the block length of the following block is read past the end of the buffer. In addition, a DCP Set block with a length smaller than the two-byte block qualifier makes the length underflow, so the block is processed with a length of 65534 bytes. This can cause a crash (denial of service) or disclose a small amount of memory content. Requires ADJACENT network access. | ||||
| CVE-2026-84296 | 2 Progress, Progress Software | 2 Ws Ftp Server, Ws Ftp Server | 2026-10-29 | 6.8 Medium |
| Multi-Factor Authentication Bypass vulnerability in SSH component in Progress Software WS_FTP Server versions prior to 2024.0.6, and 2025.0.3 on Windows allows authenticated users to bypass MFA requirements through improper association of authentication factors between accounts. | ||||
| CVE-2026-90861 | 2 Progress, Progress Software | 2 Ws Ftp Server, Ws Ftp Server | 2026-10-29 | 6.6 Medium |
| Progress Software WS_FTP Server versions prior to 2024.0.7 and 2025.0.4 on Windows may expose a user's password in clear text to another administrator, who could use it to gain broader administrative access to the server. | ||||
| CVE-2026-90862 | 2 Progress, Progress Software | 2 Ws Ftp Server, Ws Ftp Server | 2026-10-29 | 4.3 Medium |
| Improper authentication in the Web Transfer Module of Progress Software WS_FTP Server versions prior to 2024.0.7 and 2025.0.4 on Windows could allow an attacker with a user’s password to access certain files associated with that account without satisfying multi-factor authentication requirements. | ||||
| CVE-2026-90863 | 2 Progress, Progress Software | 2 Ws Ftp Server, Ws Ftp Server | 2026-10-29 | 9.1 Critical |
| Missing authorization in the administrative interface of Progress Software WS_FTP Server versions prior to 2024.0.7 and 2025.0.4 on Windows could allow a delegated Host Administrator to exceed their authorized scope, potentially enabling arbitrary command execution with elevated privileges and complete compromise of the underlying server. | ||||
| CVE-2026-90866 | 2 Progress, Progress Software | 2 Ws Ftp Server, Ws Ftp Server | 2026-10-29 | 9.1 Critical |
| A path traversal vulnerability in Progress Software WS_FTP Server versions prior to 2024.0.7 and 2025.0.4 on Windows could allow a delegated Host Administrator to access locations outside their authorized scope, potentially enabling remote code execution. | ||||
| CVE-2026-90867 | 2 Progress, Progress Software | 2 Ws Ftp Server, Ws Ftp Server | 2026-10-29 | 8.1 High |
| Improper access control in the Web Admin console of Progress Software WS_FTP Server versions prior to 2024.0.7 and 2025.0.4 on Windows could expose administrative functionality to remote authentication attempts. | ||||
| CVE-2026-90871 | 2 Progress, Progress Software | 2 Ws Ftp Server, Ws Ftp Server | 2026-10-29 | 5.3 Medium |
| Improper limitation of a pathname to a restricted directory in Progress Software WS_FTP Server versions prior to 2024.0.7 and 2025.0.4 on Windows could allow an unauthenticated attacker to affect files outside the intended directory. | ||||
| CVE-2026-90872 | 2 Progress, Progress Software | 2 Ws Ftp Server, Ws Ftp Server | 2026-10-29 | 6.6 Medium |
| Improper neutralization of directives in dynamically evaluated code in the Manager web console of Progress Software WS_FTP Server versions prior to 2024.0.7 and 2025.0.4 on Windows could allow an authenticated Manager administrator to execute arbitrary commands with the privileges of the WS_FTP Server IIS worker process. | ||||
| CVE-2026-119199 | 2026-10-29 | 5.9 Medium | ||
| Nuxt is an open-source web development framework for Vue.js. From 3.0.0 until 4.6.3, the Nuxt development server can expose the Nitro 2 development bundle at <buildDir>/dev/index.mjs through Vite file serving when the server is reachable over HTTP. Nitro inlines private runtimeConfig values resolved at build time into that bundle, including secrets configured in nuxt.config, and Nuxt 4.6.0 and later also inline the generated development appSecret. The default localhost binding limits remote exposure, production builds and Nitro 3 are not affected, and runtime configuration supplied only through NUXT_* environment variables at server startup is not inlined. This issue is fixed in version 4.6.3. | ||||
| CVE-2026-110076 | 1 Adobe | 2 Adobe Experience Manager, Experience Manager | 2026-10-29 | 5.4 Medium |
| Adobe Experience Manager is affected by a DOM-based Cross-Site Scripting (XSS) vulnerability. An attacker could exploit this issue by manipulating the DOM environment to execute malicious JavaScript within the context of the victim's browser. Exploitation of this issue requires user interaction in that a victim must visit a crafted webpage. Scope is changed. | ||||
| CVE-2026-119198 | 2026-10-29 | 5.9 Medium | ||
| Nuxt is an open-source web development framework for Vue.js. From 4.6.0 until 4.6.3, a client with TCP access to an exposed Nuxt development server can send a nuxt:dev:client-error event over the HMR socket with an absolute file path at the end of its message. The development server reads that file while building the client error report and returns its contents through the error overlay, development error channel, and terminal report, bypassing Vite's server.fs allow list. The default localhost binding limits remote exposure, cross-origin browser requests are rejected, production builds and Nuxt 3 are not affected, and no browser interaction is required. This issue is fixed in version 4.6.3. | ||||
| CVE-2026-110077 | 1 Adobe | 2 Adobe Experience Manager, Experience Manager | 2026-10-29 | 5.4 Medium |
| Adobe Experience Manager is affected by a DOM-based Cross-Site Scripting (XSS) vulnerability. An attacker could exploit this issue by manipulating the DOM environment to execute malicious JavaScript within the context of the victim's browser. Exploitation of this issue requires user interaction in that a victim must visit a crafted webpage. Scope is changed. | ||||