Export limit exceeded: 416903 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Export limit exceeded: 416903 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (416903 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2026-86981 | 1 Apple | 1 Macos | 2026-10-29 | 5.5 Medium |
| An out-of-bounds write issue was addressed with improved bounds checking. This issue is fixed in macOS Sequoia 15.8, macOS Tahoe 26.7. An app may be able to cause unexpected system termination. | ||||
| CVE-2026-99117 | 1 Linux | 2 Linux, Linux Kernel | 2026-10-29 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: net: bridge: mcast: don't truncate the port group walk on teardown __br_multicast_disable_port_ctx() and br_multicast_del_port() walk port->mglist with hlist_for_each_entry_safe(). However, br_multicast_find_del_pg() can also delete other entries from the same list through br_multicast_fwd_src_remove() or __fwd_del_star_excl(). If such an entry is the iterator's saved next node, hlist_del_init() clears its ->next and terminates the walk early. The reproducer triggers this in both teardown walks, leaving port groups in the bridge mdb with a dangling ->key.port after del_nbp() frees the port: BUG: KASAN: slab-use-after-free in __mdb_fill_info+0x1191/0x1320 __mdb_fill_info+0x1191/0x1320 br_mdb_dump+0x594/0xe40 rtnl_mdb_dump+0x1cf/0x5d0 Use hlist_del_init_rcu() to unlink the group while preserving ->next. br_multicast_del_pg() and the teardown walks run under br->multicast_lock. The GC worker must acquire the same lock before detaching the group for destruction, so the node remains alive while the walk uses the preserved pointer. Preserving ->next means a walk can now reach a group that an earlier iteration already deleted as a side effect. That group is off mp->ports, so br_multicast_find_del_pg() would fall through its port scan and hit the trailing WARN_ON(1). Skip such groups at the top of that helper: a port group is put on port->mglist when it is created and only unlinked when it is deleted, so hlist_unhashed() identifies exactly this case. | ||||
| CVE-2026-99170 | 1 Linux | 2 Linux, Linux Kernel | 2026-10-29 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: namespace: a mount that copy_tree() leaves out can't take over a lock Since commit c62a4766937e ("move_mount: transfer MNT_LOCKED") a mount can be moved beneath a locked mount. The lock moves from the old cover to the new mount which takes over the job of hiding what's under it and the old cover can be unmounted. That works as long as the new mount stays. But the caller picks the new mount and copy_tree() leaves a mount of a mount namespace file out of every copy made without CL_COPY_MNT_NS_FILE, together with everything mounted on it, and never looks at MNT_LOCKED. unshare(CLONE_NEWNS) and mount propagation make such copies. So a task that is root in its own user namespace gets rid of a locked cover on a file without a race and without touching the filesystem below it. It makes a child with a mount namespace of its own, binds the child's /proc/<pid>/ns/mnt beneath the cover with MOVE_MOUNT_BENEATH, which hands the lock to that bind, and calls unshare(CLONE_NEWNS). The new mount namespace has nothing on the file. That's the usual way to mask a single file, a bind of /dev/null or of an empty file. With a bind of an ordinary file the file stays covered. copy_tree() already refuses to leave out a locked unbindable mount with -EPERM since commit df7342b24018 ("mount: Don't allow copying MNT_UNBINDABLE|MNT_LOCKED mounts"). Do the same for a locked mount of a mount namespace file. That also covers a tree copied with CL_COPY_MNT_NS_FILE and attached into a mount namespace of another user namespace where lock_mnt_tree() locks it. Note that unshare(CLONE_NEWNS) and clone(CLONE_NEWNS) fail with EPERM from such a mount namespace from then on. The mount can't be left out and it can't be unmounted. And refuse to move a mount of a mount namespace file beneath a locked mount in the first place. Otherwise the task ends up with a mount it can't unmount and an unshare() that fails for good. Chris also found a second mount that goes away by itself, a clone of an automounted mount that shrink_submounts() took along with its parent. Commit f78ddcc87224 ("namespace: never expire a locked mount") took care of that one. Chris's reproducer is appended. Mode nsfile reads SECRET after the unshare() on 7.3-rc7, with this patch the move_mount() fails with EINVAL and the file stays covered. nsfile-control uses an ordinary file and reads MASK both ways. // SPDX-License-Identifier: GPL-2.0 /* * Get rid of a locked cover with MOVE_MOUNT_BENEATH. * * The "admin" (root) makes a tmpfs W: * W/D file, holds SECRET, covered by a bind of a file with MASK * W/Dd/inner file, holds SECRET, Dd is covered by a bind of a directory * whose "inner" holds MASK * W/own directory of uid 1000 with the file "mine" and the * directory "minedir", whose "inner" holds MINE * W/dbg debugfs, mode 755. dbg/tracing is an automount point * The "attacker" is uid 1000. It enters a new user namespace with a new mount * namespace, so W and both covers are locked there. * * usage: prog MODE * plain put a bind of own/mine beneath the cover of D, unmount the cover * nsfile put a bind of the mount namespace file of a child beneath the * cover of D, then unshare(CLONE_NEWNS) * nsfile-control the same with a bind of own/mine * shrink put a bind of the automounted tracefs beneath the cover of Dd, * unmount the cover, put a tmpfs beneath W, call umount(W), which fails * shrink-control the same with a bind of own/minedir * The environment variable AUTOMOUNT_DIR names another automount point for "shrink". */ #define _GNU_SOURCE #include <errno.h> #include <fcntl.h> #include <grp.h> #include <sched.h> #include <signal.h> #include <stdio.h> #include <stdlib.h> #include <string.h> #include <unistd.h> ---truncated--- | ||||
| CVE-2026-99206 | 1 Linux | 2 Linux, Linux Kernel | 2026-10-29 | 4.4 Medium |
| In the Linux kernel, the following vulnerability has been resolved: scsi: target: iscsi: Fix race in discovery auth updates Separate configfs opens can concurrently update the discovery AuthMethod parameter. Both callers may free the same value in iscsi_update_param_value(), causing a double-free. Protect the lookup and replacement with the discovery TPG access lock, as used by the other TPG configfs parameter updates. | ||||
| CVE-2026-99212 | 1 Linux | 2 Linux, Linux Kernel | 2026-10-29 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: net/rds: don't let the rdma_cm destroy an id RDS still owns on route failure rds_rdma_cm_event_handler_cmn() hands the return value of rdma_resolve_route() straight back to the rdma_cm on RDMA_CM_EVENT_ADDR_RESOLVED. A synchronous failure there - -ENOMEM from the route work allocation, an SA query that cannot be set up, a RoCE route with no usable device - makes addr_handler() destroy the id the event was delivered on. That id is ic->i_cm_id, and nothing clears the pointer: the connection sits in RDS_CONN_CONNECTING with a freed id until its shutdown calls rdma_disconnect() and rdma_destroy_id() on it. The ROUTE_RESOLVED case already avoids this: rds_ib_cm_initiate_connect() forces a zero return while ic->i_cm_id == cm_id, as the comment there explains. Do the same here - drop the connection and return 0 - so the id stays RDS's to destroy from the shutdown, and the reconnect gets a fresh one. | ||||
| CVE-2026-99214 | 1 Linux | 2 Linux, Linux Kernel | 2026-10-29 | 2.5 Low |
| In the Linux kernel, the following vulnerability has been resolved: drm/vc4: hdmi: Move packet RAM enable to PM runtime Audio can be triggered by the HPD handler and start up before video has been restored, calling vc4_hdmi_write_infoframe() for the audio infoframe. vc4_hdmi_write_infoframe() needs Packet RAM to be on to store the infoframe, however, if the video hasn't been enabled, vc4_hdmi_encoder_post_crtc_enable() hasn't been called and therefore, the Packet RAM can be disabled by the time vc4_hdmi_write_infoframe() executes, causing the following splat: [ 201.570266] ------------[ cut here ]------------ [ 201.570293] Packet RAM has to be on to store the packet. [ 201.570367] WARNING: drivers/gpu/drm/vc4/vc4_hdmi.c:683 at vc4_hdmi_write_infoframe+0x404/0x494 [vc4], CPU#0: wireplumber/1606 [...] [ 201.658650] Hardware name: Raspberry Pi 4 Model B Rev 1.5 (DT) [...] [ 201.758499] Call trace: [ 201.760967] vc4_hdmi_write_infoframe+0x404/0x494 [vc4] (P) [ 201.766607] vc4_hdmi_write_audio_infoframe+0x1c/0x28 [vc4] [ 201.772247] write_infoframe+0xbc/0x140 [drm_display_helper] [ 201.777975] drm_atomic_helper_connector_hdmi_update_audio_infoframe+0x80/0xdc [drm_display_helper] [ 201.787140] vc4_hdmi_audio_prepare+0x4ac/0x570 [vc4] [ 201.792252] drm_connector_hdmi_audio_prepare+0x24/0x30 [drm_display_helper] [ 201.799390] hdmi_codec_prepare+0x100/0x160 [snd_soc_hdmi_codec] [ 201.805471] snd_soc_pcm_dai_prepare+0xd4/0x100 [snd_soc_core] [ 201.811375] __soc_pcm_prepare+0x60/0x12c [snd_soc_core] [ 201.816752] soc_pcm_prepare+0x34/0x58 [snd_soc_core] [ 201.821863] snd_pcm_do_prepare+0x70/0x8c [snd_pcm] [ 201.826798] snd_pcm_action_nonatomic+0xe4/0x174 [snd_pcm] [ 201.832350] snd_pcm_prepare+0xc8/0xd8 [snd_pcm] [ 201.837021] snd_pcm_common_ioctl+0x458/0x614 [snd_pcm] [ 201.842308] snd_pcm_ioctl+0x30/0x48 [snd_pcm] [ 201.846802] __arm64_sys_ioctl+0x88/0xd8 [ 201.850769] invoke_syscall+0x48/0xf4 [ 201.854470] el0_svc_common+0x80/0xd8 [ 201.858171] do_el0_svc+0x1c/0x28 [ 201.861520] el0_svc+0x3c/0xb0 [ 201.864605] el0t_64_sync_handler+0x68/0xdc [ 201.868834] el0t_64_sync+0x198/0x19c [ 201.872536] ---[ end trace 0000000000000000 ]--- Considering that Packet RAM enable is essentially a power management configuration, move its enabling/disabling to the Runtime PM hooks. Note that post_crtc_disable() still stops all infoframes, but keeps Packet RAM enabled, leaving it to be disabled by runtime suspend. | ||||
| CVE-2026-107016 | 2026-10-29 | N/A | ||
| Insecure permissions in Fossify v1.3.0 allows unauthorized attackers to access and read another user's stored contacts. | ||||
| CVE-2026-107017 | 2026-10-29 | N/A | ||
| Insecure permissions in the ShortcutDispatchActivity component of canvoki versionCode 14 allows unauthorized attackers to arbitrarily trigger another user's configured automated actions. | ||||
| CVE-2026-79589 | 2026-10-29 | N/A | ||
| The WIFI4 N300 router (Model: T1 Pro) v1.0.0 by U-speed contains an insecure access control flaw that allows an attacker to gain unauthenticated root shell. The vulnerability is caused by the exposure of the UART debugging interface having a lack of authentication, authorization and access control functionality. Once the interface is soldered and connected to the attacker, they gain root privilege to the system. | ||||
| CVE-2026-115713 | 1 Elastic | 1 Elastic Cloud Enterprise | 2026-10-29 | 7.5 High |
| Improper Link Resolution Before File Access ('Link Following') (CWE-59) in Elastic Cloud Enterprise (ECE) can lead to unauthorized read and write access to data of other deployments on the same host via Symlink Attack (CAPEC-132). | ||||
| CVE-2026-115708 | 1 Elastic | 1 Elastic Cloud Enterprise | 2026-10-29 | 7.2 High |
| Improper Link Resolution Before File Access ('Link Following') (CWE-59) in Elastic Cloud Enterprise (ECE) can lead to authentication bypass and unauthorized changes to the configuration of other deployments on the same host via Symlink Attack (CAPEC-132). | ||||
| CVE-2026-115709 | 1 Elastic | 1 Elastic Cloud Enterprise | 2026-10-29 | 8.2 High |
| Improper Link Resolution Before File Access ('Link Following') (CWE-59) in Elastic Cloud Enterprise (ECE) can lead to unauthorized disclosure and loss of data belonging to other deployments on the same host via Symlink Attack (CAPEC-132). | ||||
| CVE-2026-115711 | 1 Elastic | 1 Elastic Cloud Enterprise | 2026-10-29 | 6.4 Medium |
| Insertion of Sensitive Information into Externally-Accessible File or Directory (CWE-538) in Elastic Cloud Enterprise (ECE) can lead to credential disclosure via Retrieve Embedded Sensitive Data (CAPEC-37). ECE stores runtime information about platform service containers in a location that lower-privileged platform components can read, and this information includes secrets from the container configuration. An attacker with access to the internal ECE platform services can obtain these secrets, which include role tokens. A role token can let the attacker add an unauthorized host to the installation with the roles of that token. | ||||
| CVE-2026-115712 | 1 Elastic | 1 Elastic Cloud Enterprise | 2026-10-29 | 4.3 Medium |
| Incorrect Authorization (CWE-863) in Elastic Cloud Enterprise (ECE) can lead to unauthorized modification of platform-level settings via Accessing Functionality Not Properly Constrained by ACLs (CAPEC-1). An authenticated user with read-only access to the platform can change an installation-wide account setting that only platform administrators are permitted to change. | ||||
| CVE-2026-62374 | 2026-10-29 | N/A | ||
| SD JWT JS is a JavaScript implementation of the Selective Disclosure JWT (SD-JWT) specification. In version 0.19.0 and earlier, `@sd-jwt/decode`, also used by `@sd-jwt/core`, silently drops a tampered Disclosure whose digest no longer matches the Issuer-signed `_sd` array and returns a reduced claim set, reporting success while the Issuer signature remains valid. Both a tampered Disclosure that remains valid JSON and a Disclosure containing invalid UTF-8 bytes reach this silent-drop behavior. In the latter case, the `TextDecoder / Buffer` decoding path substitutes U+FFFD replacement characters, recovering syntactically valid disclosure data instead of rejecting the malformed input. This violates RFC 9901 section 7.1 step 5, which requires rejection of unreferenced Disclosures, and section 7.1 step 3 / section 4.2.1, which require rejection of invalid Disclosures. A malicious holder can exploit this omission primitive, including through `SDJwtInstance.verify()` when key binding is required. An on-path attacker can also tamper with a Disclosure when the relying party does not enforce key binding; enforced key binding rejects on-path tampering because it invalidates the KB-JWT `sd_hash` binding. If the relying party defaults to allowing access when a constraining age, role, or restriction claim is absent, the silent claim reduction can change an authorization decision without an error. This issue is fixed in `@sd-jwt/core` version 0.20.0; no patched version of the standalone `@sd-jwt/decode` package is identified. | ||||
| CVE-2026-93851 | 1 Mattermost | 1 Mattermost | 2026-10-29 | 8 High |
| Mattermost versions 11.9.x <= 11.9.1, 11.8.x <= 11.8.5, 11.7.x <= 11.7.10 fail to validate the target post ID in the Agents plugin's mention reminder component, which allows an authenticated user who can post in a channel visible to a system administrator to cause the administrator's browser to send an unintended API request, resulting in replacement of an installed plugin and code execution on the server, via a crafted post containing a forged mention reminder that the administrator clicks. Mattermost Advisory ID: MMSA-2026-00742 | ||||
| CVE-2026-59837 | 1 Fortinet | 4 Fortios, Fortipam, Fortiproxy and 1 more | 2026-10-29 | 5.9 Medium |
| A stack-based buffer overflow vulnerability in Fortinet FortiOS 7.4.0 through 7.4.1, FortiOS 7.2 all versions, FortiOS 7.0 all versions, FortiOS 6.4 all versions, FortiPAM 1.8.0 through 1.8.2, FortiPAM 1.7 all versions, FortiPAM 1.6 all versions, FortiPAM 1.5 all versions, FortiPAM 1.4 all versions, FortiPAM 1.3 all versions, FortiPAM 1.2 all versions, FortiPAM 1.1 all versions, FortiPAM 1.0 all versions, FortiProxy 7.4.0 through 7.4.13, FortiProxy 7.2 all versions may allow a privileged authenticated attacker who can bypass stack protection and ASLR to execute arbitrary code or commands via crafted HTTP requests. | ||||
| CVE-2026-61572 | 1 Wwbn | 1 Avideo-encoder | 2026-10-29 | 8.6 High |
| AVideo is a video-sharing Platform. Before the initial remediation attempt in 8.1.0, `url_get_contents` in `objects/functions.php` accepts caller-controlled destinations after only `FILTER_VALIDATE_URL` syntax validation, without rejecting private, loopback, or link-local addresses, and disables TLS peer verification. `Login::isLogged` reauthenticates using the attacker-settable `encoder_aVideoURL` cookie together with arbitrary nonempty `encoder_user` and `encoder_pass` cookies, and `Login::run` stores the raw fetched body in `result`. The unauthenticated `objects/login.json.php` endpoint returns that session object, enabling full-response exfiltration through a supplied `siteURL`; its `Streamer::isURLAllowed` gate allows all sites when the operator allowlist is empty, the default. An unauthenticated remote attacker can read internal HTTP and HTTPS responses, including cloud instance-metadata credentials, and reach internal TCP services. A further pre-authentication FTP variant in `view/youtubeDl.json.php` routes an ftp `videoURL` into `FTPDownloader`; `parseFtpUrl` in `objects/FTPDownloader.php` accepts its host and port for `ftp_connect`. This also enables requests to internal FTP services. Untrusted self-signed HTTPS certificates are accepted, and no account or operator interaction is required. Version 8.1.0 contains an initial remediation attempt that removes raw-response reflection and adds destination checks, but private-network exemptions and login TLS-verification defaults leave complete remediation of the described internal-network and TLS variants unresolved. | ||||
| CVE-2026-61569 | 1 Wwbn | 1 Avideo-encoder | 2026-10-29 | 7.5 High |
| AVideo is a video-sharing Platform. Prior to 8.1.0, the unauthenticated streamer login at `objects/login.json.php` passes the `user` parameter to `Streamer::get` in `objects/Streamer.php`, where it is interpolated into a single-quoted MariaDB SELECT without parameterization or escaping. Although `objects/security.php` strips literal single quotes, `html_entity_decode` in `objects/Login.php` restores entity-encoded quotes before the query. The supplied `siteURL` must pass the streamer allowlist, which allows all sites when empty by default, and an attacker-hosted login response must set `canUpload` or `isAdmin` to reach `Streamer::createIfNotExists`. That function calls `Streamer::get` before its additional allowlist check. UNION results are exposed through `streamers_id`, while failures return the rendered query and MariaDB error. An attacker can read arbitrary encoder database data, including stored upstream streamer credentials, allowlist configuration, and queue records, without encoder credentials. Stacked statements are not permitted by the mysqli driver and the tested database account lacks global FILE privilege, so the demonstrated vector is bounded to reads rather than server-side file writes. Stolen streamer credentials can provide continued upstream access until rotated. This issue is fixed in version 8.1.0. | ||||
| CVE-2026-71408 | 1 Fortinet | 1 Fortios | 2026-10-29 | 5 Medium |
| A allocation of resources without limits or throttling vulnerability in Fortinet FortiOS 7.6.0 through 7.6.6, FortiOS 7.4 all versions, FortiOS 7.2 all versions, FortiOS 7.0 all versions, FortiOS 6.4 all versions may allow an unauthenticated attacker to perform a slow HTTP DoS attack on the web interface via crafted HTTP requests. | ||||