Export limit exceeded: 413912 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (413912 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2026-85930 | 1 Microsoft | 17 Windows 10 21h2, Windows 10 21h2, Windows 10 22h2 and 14 more | 2026-10-23 | 7 High |
| Use after free in Windows Image Acquisition allows an authorized attacker to elevate privileges locally. | ||||
| CVE-2026-85933 | 1 Microsoft | 28 Windows 10 1607, Windows 10 1809, Windows 10 21h2 and 25 more | 2026-10-23 | 7.8 High |
| Use after free in Windows Print Spooler Components allows an authorized attacker to elevate privileges locally. | ||||
| CVE-2026-87713 | 1 Microsoft | 23 Windows 10 1607, Windows 10 1809, Windows 10 21h2 and 20 more | 2026-10-23 | 7.5 High |
| Use after free in Windows Bluetooth Port Driver allows an unauthorized attacker to elevate privileges over an adjacent network. | ||||
| CVE-2026-88071 | 1 Microsoft | 11 Windows 11 23h2, Windows 11 23h2, Windows 11 24h2 and 8 more | 2026-10-23 | 7.8 High |
| Double free in Windows Hyper-V allows an authorized attacker to elevate privileges locally. | ||||
| CVE-2026-98976 | 1 Linux | 2 Linux, Linux Kernel | 2026-10-23 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: namespace: keep the lock on a mount that a propagated copy is moved beneath attach_recursive_mnt() transfers MNT_LOCKED from the top mount to the mount that is moved beneath it with MOVE_MOUNT_BENEATH. This allows the owner of a user namespace to replace its locked /proc or its root. The mount beneath takes on the job of covering the underlying mountpoint allowing the top mount to be unmounted. Consider two mount namespaces: (H) The host H has a shared mount P with a secret in P/d (Z) Z is a user namespace made from M. Its copy of P receives propagation from the host's P and its copy of M's cover on P/d is locked Z's owner must not get to see P/d. Now (H) mounts X on P/d. This propagates into (Z). The copy of X lands beneath (Z)'s locked cover. The locked property is transfered from (Z)'s cover to the copy of X propagated beneath it. The cover is now unlocked. Now (H) unmounts X again. The copy of X in (Z) gets unmounted and the covering mount is left unlocked on top of P/d. (Z) can now unmount it: Z: umount2(P/d) = EINVAL /* the cover is locked */ H: mount X on P/d, umount X /* both propagate into Z /* Z: umount2(P/d) = 0 /* the cover is now unlocked */ Z: read P/d/secret = "covered-by-root" /* secret revealed */ So only transfer the locked property to the mount beneath for mounts the caller has placed. A propagated copy that lands beneath a locked mount is locked as well so that the mount at the bottom of the stack carries a lock the way every check expects. The mount on top of it remains locked to ensure that it keeps covering even if the propagated mount is unmounted again. | ||||
| CVE-2026-98978 | 1 Linux | 2 Linux, Linux Kernel | 2026-10-23 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: namespace: never expire a locked mount Locked mounts are special. They protect the underlying files and directories from being revealed. do_umount() refuses to unmount locked mounts but shrink_submounts() doesn't. A shrinkable mount can become locked once the owner of a user namespace puts it beneath a locked mount with MOVE_MOUNT_BENEATH. The locked property now moves to the mount at the bottom making it possible to unmount the top mount. So umount() of an unlocked ancestor now expires the bottom mount first and the covered directory is revealed: move_mount(c -> x/hidden, MOVE_MOUNT_BENEATH) = 0 the cover after the lock moved: umount2(x/hidden) = 0 the holder of the lock: umount2(x/hidden) = EINVAL the root of the copy, busy: umount2(x) = EBUSY reads x/hidden/secret: "covered-by-root" So leave a locked mount alone as it dies together with its parent. A plain umount() of an unlocked mount with a locked one below it is EBUSY from now on. It's the same for any other locked child. A lazy umount still takes the whole tree. mark_mounts_for_expiry() never sees a locked mount. lock_mnt_tree() leaves a mount on an expiry list alone and nothing else puts a locked one on such a list. Add an assert for this. | ||||
| CVE-2026-12343 | 1 Ibm | 3 Mq Advanced Container Images, Mq Operator, Supplied Mq Advanced Container Images | 2026-10-23 | 6.5 Medium |
| IBM MQ could allow an authenticated attacker to cause a denial of service due to improper validation of RFH2 message header fields in queued publish/subscribe operations. | ||||
| CVE-2026-12350 | 1 Ibm | 3 Mq Advanced Container Images, Mq Operator, Supplied Mq Advanced Container Images | 2026-10-23 | 6.5 Medium |
| IBM MQ could allow an authenticated attacker to cause a denial of service by sending a specially crafted asynchronous consume request that crashes the queue manager agent process. | ||||
| CVE-2026-12660 | 1 Ibm | 3 Mq Advanced Container Images, Mq Operator, Supplied Mq Advanced Container Images | 2026-10-23 | 2.7 Low |
| IBM MQ Web Console could allow an authenticated administrator to write files outside the intended directory due to improper path validation. | ||||
| CVE-2026-12665 | 1 Ibm | 3 Mq Advanced Container Images, Mq Operator, Supplied Mq Advanced Container Images | 2026-10-23 | 8.1 High |
| IBM MQ could allow a remote attacker to execute arbitrary code due to a stack buffer overflow when processing TLS certificates with malformed distinguished names during channel connection establishment. | ||||
| CVE-2026-12669 | 1 Ibm | 3 Mq Advanced Container Images, Mq Operator, Supplied Mq Advanced Container Images | 2026-10-23 | 3.1 Low |
| IBM MQ could allow an authenticated attacker to trigger a minor out-of-bounds read when sending malformed compressed data, though the data is not disclosed and the request is rejected. | ||||
| CVE-2026-91636 | 1 Oracle | 1 Essbase | 2026-10-23 | 7.7 High |
| Vulnerability in Oracle Essbase (component: Security). The supported version that is affected is 21.8.3.0.0. Easily exploitable vulnerability allows low privileged attacker with network access via HTTP to compromise Oracle Essbase. While the vulnerability is in Oracle Essbase, attacks may significantly impact additional products (scope change). Successful attacks of this vulnerability can result in unauthorized access to critical data or complete access to all Oracle Essbase accessible data. CVSS 3.1 Base Score 7.7 (Confidentiality impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:N/A:N). | ||||
| CVE-2026-12670 | 1 Ibm | 3 Mq Advanced Container Images, Mq Operator, Supplied Mq Advanced Container Images | 2026-10-23 | 5.3 Medium |
| IBM MQ could allow an authenticated attacker to cause a denial of service through a specially crafted message that triggers excessive memory operations during character set conversion. | ||||
| CVE-2026-111648 | 2026-10-23 | 2.7 Low | ||
| BuildAdmin through 2.3.9 contains an insecure direct object reference vulnerability that allows authenticated backend administrators to modify other administrators' profiles via the id parameter. Attackers holding the routine/adminInfo/edit permission can overwrite avatar, nickname, email, mobile and motto fields, including a super administrator's email and mobile. | ||||
| CVE-2026-111643 | 2026-10-23 | 9.8 Critical | ||
| Misaka Danmu Server through 2.8.9 contains an authentication bypass vulnerability that allows unauthenticated attackers to write arbitrary configuration keys via the unprotected POST /api/ui/config-history/rollback endpoint. Attackers can set the ipWhitelist key to their own /32 address, or alter trustedProxies and webhookApiKey, to access every protected endpoint as the administrator. | ||||
| CVE-2026-111638 | 2026-10-23 | 7.7 High | ||
| sshportal through 1.19.5 contains a missing authorization vulnerability in the management shell 'key show' command that allows authenticated non-admin users to obtain decrypted backend private SSH keys. Attackers can request predictable key names like 'default' or 'host' to retrieve private keys and connect directly to backend hosts, bypassing ACLs and session recording. | ||||
| CVE-2026-99025 | 1 Linux | 1 Linux Kernel | 2026-10-23 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: openvswitch: fix soft lockup in the netlink flow dump A production compute node carrying a few thousand datapath flows hit a soft lockup inside a single netlink flow dump and panicked. ovs_flow_cmd_dump() calls ovs_flow_stats_get() for every flow it emits, and that releases stats->lock with spin_unlock_bh() once per CPU that has touched the flow. Every release is a local_bh_enable(), and each one runs the pending softirq backlog in the dumping thread's own context. The skb bounds the flows one callback emits, but not the softirq work it absorbs. On a CPU that carries the box's packet load the backlog refills as fast as it drains, so the dumping thread becomes that CPU's softirq engine. It never sleeps and it has no reschedule point, so under voluntary preemption nothing can take the CPU away from it: neither the ksoftirqd the kernel woke to take the work over, nor the stopper thread the softlockup detector dispatches to refresh its timestamp. Hold BH off across the whole callback instead, the way ctnetlink_dump_table() does, so the nested spin_unlock_bh() stop draining softirqs. The loop already runs under rcu_read_lock() and cannot sleep. What it gives up is preemption under CONFIG_PREEMPT, since a BH-off region is not preemptible outside PREEMPT_RT. The region stays short: the skb caps the flows one callback emits, and empty buckets cost no skb space but are each visited once per dump, as the cursor only moves forward. The table grows on insert and shrinks only on flush, so the walk is bounded by the largest flow count the datapath has held. The softirq backlog the callback used to absorb has no bound at all. | ||||
| CVE-2026-99026 | 1 Linux | 1 Linux Kernel | 2026-10-23 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: net: team: free skb when broadcast has no txable port bc_transmit() sends the original skb through the last txable port. When no port is txable, it returns false without consuming the skb, but team_xmit() still returns NETDEV_TX_OK. AF_PACKET sends then retain the skb and its socket write-memory charge. A TX-enabled, link-down port keeps the broadcast transmit op installed. Carrier can stay up through a second link-up, TX-disabled port or be forced on by userspace. Free the original skb on the no-port path while leaving the existing drop accounting intact. Discovered by Sashiko during review of previous commit. | ||||
| CVE-2026-99076 | 1 Linux | 1 Linux Kernel | 2026-10-23 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: ipv6: udp: Create exceptions before socket matching Currently, when ICMPv6 Packet Too Big and Redirect Message packets are locally delivered and quote a UDP packet, an exception is only created in the IPv6 exception cache if the kernel can match the UDP packet to an existing socket. This behavior allows off-path attackers to conduct a side-channel attack on the exception cache in order to discover the ephemeral port used by a connected UDP socket. Commit 4785305c05b2 ("ipv6: use siphash in rt6_exception_hash()") and commit a00df2caffed ("ipv6: make exception cache less predictible") tried to mitigate such attacks by making it harder for attackers to discover hash collisions in the exception cache and by randomizing the number of exceptions a hash bucket can hold, respectively. Unfortunately, both of the mitigations can be bypassed. Instead, mitigate such attacks by always creating an exception, even before trying to find a matching socket. Do that by calling ip6_update_pmtu() and ip6_redirect(), the helpers used when the quoted packet did not originate from a socket. This means that guesses (right or wrong) from an off-path attacker will always result in an exception being created or updated in the cache that the attacker can observe. Pass the ifindex of the ingress device and the default uid, in a similar fashion to icmpv6_err(). Unlike IPv4, an oif of 0 would not match any nexthop in ip6_redirect_nh_match() and no exception would be created in response to a Redirect Message. Note that this does not allow attackers to create exceptions that they could not create before, as both helpers can already be reached with little to no validation. For example, by sending an ICMPv6 error that quotes an ICMPv6 Echo Reply or one that quotes a UDP source port that matches a wildcard socket. Also note that in the good case (matched socket) the above scheme comes at the cost of an extra route lookup, as the no socket helpers perform their own lookup before the one performed by ip6_sk_update_pmtu() / ip6_sk_redirect(). When the two resolve to different nexthops, it also results in two exceptions being created for the same destination IP. One in the exception cache of the nexthop resolved by the no socket helpers and another in the exception cache of the nexthop used by the socket. | ||||
| CVE-2026-99084 | 1 Linux | 1 Linux Kernel | 2026-10-23 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: readdir: take no inode lock on an immutable directory iterate_dir() takes the directory's i_rwsem shared and holds it across ->iterate_shared(). For a directory that never has an entry and is never removed the lock keeps nothing still, it only orders every reader and every writer of that inode behind each other. For the directory of a nullfs instance that matters. The instance of the initial mount namespace is the root of every empty mount namespace and the private instance is the root of every kernel thread, so one inode is shared across users who have nothing else in common. And a reader can hold the lock for as long as it likes: back the getdents() buffer with a mapping of a file on a FUSE mount of your own, let the copy of "." and ".." fault and let the server wait. Queue an exclusive taker behind it, a mkdir() in that directory goes through start_dirop() before the read-only mount is reported, and from then on every lookup that misses the dcache in that directory, every create and every mount on it waits until the server answers. One user of an empty mount namespace stalls all the others. Add FOP_IMMUTABLE for the file operations of a directory that never changes and is never removed and let iterate_dir() skip the lock for it. The flag never changes for a file, ->f_pos is protected by f_pos_lock since directories are FMODE_ATOMIC_POS, IS_DEADDIR can't be set on such a directory and neither touch_atime() nor fsnotify take i_rwsem. Set it on the nullfs directory. The placeholder directories of libfs never have an entry either but their owners remove them, so they keep the lock. | ||||