Export limit exceeded: 412659 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (412659 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2026-113057 | 2026-10-20 | N/A | ||
| Improper access control in ComputePressure in Google Chrome prior to 156.0.8078.47 allowed a remote attacker to bypass web origin policy via a crafted HTML page. (Chromium security severity: Medium) | ||||
| CVE-2026-113264 | 2026-10-20 | N/A | ||
| Improper input validation in Extensions in Google Chrome prior to 156.0.8078.47 allowed a remote attacker to potentially execute arbitrary code inside the sandbox via a crafted HTML page. (Chromium security severity: Medium) | ||||
| CVE-2026-113129 | 2026-10-20 | N/A | ||
| Improper access control in Extensions in Google Chrome prior to 156.0.8078.47 allowed a remote attacker to potentially leak sensitive information via a crafted HTML page. (Chromium security severity: Medium) | ||||
| CVE-2026-113026 | 2026-10-20 | N/A | ||
| Memory corruption in PDF in Google Chrome on on Android prior to 156.0.8078.47 allowed a remote attacker to potentially read memory inside the sandbox via a crafted HTML page. (Chromium security severity: Medium) | ||||
| CVE-2026-113070 | 2026-10-20 | N/A | ||
| Out of bounds read in GetUserMedia in Google Chrome prior to 156.0.8078.47 allowed a remote attacker to read memory inside the sandbox via a crafted HTML page. (Chromium security severity: Medium) | ||||
| CVE-2026-113212 | 2026-10-20 | N/A | ||
| Memory corruption in PDF in Google Chrome prior to 156.0.8078.47 allowed a remote attacker to potentially via a crafted HTML page. (Chromium security severity: High) | ||||
| CVE-2026-113295 | 2026-10-20 | N/A | ||
| Out of bounds read in ANGLE in Google Chrome on on Windows prior to 156.0.8078.47 allowed a remote attacker to read memory inside the sandbox via a crafted HTML page. (Chromium security severity: High) | ||||
| CVE-2026-113309 | 2026-10-20 | N/A | ||
| Out of bounds read in Media in Google Chrome prior to 156.0.8078.47 allowed a remote attacker to read memory inside the sandbox via a crafted HTML page. (Chromium security severity: High) | ||||
| CVE-2026-113225 | 2026-10-20 | N/A | ||
| Memory corruption in Browser in Google Chrome on on Android prior to 156.0.8078.47 allowed a remote attacker to potentially read memory inside the sandbox via a crafted HTML page. (Chromium security severity: High) | ||||
| CVE-2026-113193 | 2026-10-20 | N/A | ||
| Memory corruption in V8 in Google Chrome prior to 156.0.8078.47 allowed a remote attacker to potentially read memory inside the sandbox via a crafted HTML page. (Chromium security severity: High) | ||||
| CVE-2026-113716 | 1 Pypa | 1 Virtualenv | 2026-10-20 | 4.5 Medium |
| virtualenv is a tool for creating isolated virtual python environments. Prior to 21.14.9, the builtin creator calls ensure_dir() for executable, library, and package directories, and ensure_dir() accepts an existing symlink to a directory because exists() follows it. Interpreter creation, seed installation, and activation generation then write through the linked parent outside the requested destination when another local account prepared the tree and the invoking user can access the target. The --clear option removes the planted tree first, while ordinary creation reaches it; arbitrary attacker-selected output bytes are not established. This issue is fixed in version 21.14.9. | ||||
| CVE-2026-113717 | 1 Pypa | 1 Virtualenv | 2026-10-20 | 5.0 Medium |
| virtualenv is a tool for creating isolated virtual python environments. Prior to 21.14.9, PipInvoke.get_pip_install_cmd() handles --seeder pip --download by calling get_wheel(download=False) and then allowing pip to consult the configured index, bypassing virtualenv's download_wheel() and verify_wheel_digest() path. When virtualenv's default-index PyPI digest comparison remains enabled, an index candidate matching the bundled package and version can therefore be selected without comparison to PyPI SHA-256 metadata. Explicit custom-index settings already opt out of that comparison and remain outside this verification-bypass claim; the demonstrated configuration used a non-PyPI index while leaving the index environment variables unset so the comparison policy remained active. This condition does not independently defeat TLS or establish control of the index response. This issue is fixed in version 21.14.9. | ||||
| CVE-2026-113719 | 1 Pypa | 1 Virtualenv | 2026-10-20 | 4.5 Medium |
| virtualenv is a tool for creating isolated virtual python environments. Prior to 21.14.9, PipInstall._uninstall_previous_version() accepts existing seed-package metadata and _uninstall_dist() joins entries from top_level.txt and RECORD to site-packages without checking containment. When a reused destination contains distribution metadata influenced by another account, relative traversal, absolute entries, or linked parents can cause app-data reseeding to delete files outside the environment or the environment root with the invoking user's permissions, provided that user has deletion rights over the named paths. The deletion occurs during environment creation before any later use of the environment. Fresh environments without existing package metadata and creation with --clear do not enter this cleanup path. This issue is fixed in version 21.14.9. | ||||
| CVE-2026-113720 | 1 Pypa | 1 Virtualenv | 2026-10-20 | 6.7 Medium |
| virtualenv is a tool for creating isolated virtual python environments. Prior to 21.14.9, the app-data copy seeder uses shutil.copy() to copy cached package files into later environments, causing cached source modes to override the current run's umask. A cache populated under a permissive umask can therefore produce files writable by another local account in a later traversable environment, allowing package code such as pip/__init__.py to be modified and executed by the environment owner. The attacker cannot force the earlier umask, and a private destination parent prevents access. This issue is fixed in version 21.14.9. | ||||
| CVE-2026-97763 | 1 Microsoft | 12 365 Apps, Microsoft 365, Microsoft Office Ltsc 2021 and 9 more | 2026-10-20 | 8.8 High |
| Heap-based buffer overflow in Microsoft Office Excel allows an unauthorized attacker to execute code over a network. | ||||
| CVE-2026-97793 | 1 Microsoft | 20 Windows 10 1809, Windows 10 21h2, Windows 10 21h2 and 17 more | 2026-10-20 | 7 High |
| Missing authentication for critical function in Windows Setup and Deployment allows an authorized attacker to elevate privileges locally. | ||||
| CVE-2026-112836 | 2 E4jvikwp, Wordpress-extensions | 2 Vikrentcar, Vikrentcar | 2026-10-20 | 8.8 High |
| Cross-Site Request Forgery (CSRF) vulnerability in e4jvikwp VikRentCar vikrentcar allows Cross Site Request Forgery.This issue affects VikRentCar: from n/a through 1.4.8. | ||||
| CVE-2026-112177 | 2 Ghostscript, Redhat | 2 Ghostscript, Enterprise Linux | 2026-10-20 | 7.3 High |
| A flaw was found in Ghostscript as shipped with Red Hat Enterprise Linux 8. The correction for CVE-2019-14869 was omitted during the rebase from version 9.25 to 9.27, leaving privileged .forceput operations in the .charkeys procedure insufficiently protected. Processing a specially crafted PostScript file may allow an attacker to bypass -dSAFER restrictions and access files outside the permitted paths or execute commands with the permissions of the Ghostscript process. | ||||
| CVE-2026-107805 | 2 0xjacky, Nginxui | 2 Nginx-ui, Nginx Ui | 2026-10-20 | 7.5 High |
| Nginx UI is a web user interface for the Nginx web server. From 2.5.0 until 2.6.0, the node-signature authentication path performs temporary file staging of an attacker-controlled request body and synchronizes it before validating the body digest and cryptographic signature. An unauthenticated remote client that can reach the API and provide syntactically valid signature metadata can consume temporary filesystem capacity, disk input and output, and request-processing resources before rejection. The issue affects availability and does not bypass authentication or provide confidentiality or integrity impact. This issue is fixed in version 2.6.0. | ||||
| CVE-2026-98539 | 1 Linux | 1 Linux Kernel | 2026-10-20 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: use d_instantiate_new() in ntfs_create_inode() and murder syzbot's "WARNING in do_new_mount" saga ntfs_create_inode() creates a new inode via ntfs_new_inode(). It hashes it with insert_inode_locked() and so it's marked as I_NEW until unlock_new_inode(). ntfs 3 calls d_instantiate() in between though... Since the dentry was already hashed by the lookup before the create any path walk finds it without touching the parent's i_rwsem and so can lock the inode. If the inode is a directory unlock_new_inode() calls lockdep_annotate_inode_mutex_key() and marks i_rwsem with the i_mutex_dir_key class. That resets the count and the owner of a lock somebody else may already hold by now... syzbot has been spamming us with the same godforsaken bug "WARNING in do_new_mount" since 2023. I can't take it anymore so I went looking. Afaict, syzbot's executor chdirs into a freshly mounted ntfs3 image, creates a directory and then mounts some pseudofs on it. Everytime the mkdir() takes longer than syzbot waits mount() runs concurrently: mkdir("./sys") mount(NULL, "./sys", "sysfs") ntfs_create_inode() d_instantiate() user_path_at() finds the dentry do_lock_mount() inode_lock(inode) namespace_lock() unlock_new_inode() lockdep_annotate_inode_mutex_key() init_rwsem(&inode->i_rwsem) unlock_mount() inode_unlock(inode) The mount side then releases a lock that according to the rwsem nobody holds: DEBUG_RWSEMS_WARN_ON((rwsem_owner(sem) != current) && ...): count = 0x0, magic = 0xffff888043a854e8, owner = 0x0, curr 0xffff888000244880, list empty WARNING: CPU: 0 PID: 5346 at kernel/locking/rwsem.c:1368 __up_write Call Trace: inode_unlock include/linux/fs.h:877 [inline] unlock_mount fs/namespace.c:2892 [inline] do_new_mount_fc fs/namespace.c:3828 [inline] do_new_mount+0x777/0xa40 fs/namespace.c:3887 On PREEMPT_RT the same thing shows up as DEBUG_LOCKS_WARN_ON(rt_mutex_owner(lock) != current) WARNING: kernel/locking/rtmutex_common.h:193 at rt_mutex_slowunlock The up_write() underflows the reset count. A following inode_lock() on that directory then never returns. A path walk into the new directory racing with the mkdir() corrupts the lock the same way via inode_lock_shared() in lookup_slow(). Switch to d_instantiate_new() and drop the trailing unlock_new_inode(). All error paths bail out before that point with I_NEW still set and keep using discard_new_inode(). May we never see this fscking bug report again. | ||||