Export limit exceeded: 425870 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (425870 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2026-129352 | 1 Trendnet | 2 Tew-657brm, Tew-657brm Firmware | 2026-11-15 | 9.1 Critical |
| A vulnerability was detected in TRENDnet TEW-657BRM 1.00.1. This issue affects some unknown processing of the file /usr/sbin/upgrade_flash.cgi. Performing a manipulation of the argument boundary results in stack-based buffer overflow. The attack is possible to be carried out remotely. The exploit is now public and may be used. The vendor explains: ""I am not able to confirm if such vulnerability exists as the product has been EOL for more than 15 years. We will send out an announcement letting customers know." | ||||
| CVE-2026-96117 | 1 Microsoft | 23 Windows 10 1607, Windows 10 1809, Windows 10 21h2 and 20 more | 2026-11-15 | 7.8 High |
| Heap-based buffer overflow in Windows LUAFV allows an authorized attacker to elevate privileges locally. | ||||
| CVE-2026-115559 | 2 Python, Python Software Foundation | 2 Cpython, Cpython | 2026-11-15 | N/A |
| IMAP4.starttls() wraps the socket in TLS but leaves self._readbuf, imaplib's own read-ahead buffer, untouched. Any plaintext bytes that arrived in the same recv() as the tagged OK to STARTTLS are returned by readline() after the handshake, so the client treats them as the first responses on the protected channel. A network attacker who cannot break TLS can append forged lines after the server's OK, let the handshake complete with the real server and a valid certificate, and have the client accept the forged CAPABILITY and the forged tagged completion of the next command. This is the STARTTLS command/response injection class of CVE-2011-0411. | ||||
| CVE-2026-0175 | 1 Google | 1 Android | 2026-11-15 | 8.4 High |
| In multiple locations, there is a possible way to bypass key authorization policies during wrapped key import due to a logic error. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is not needed for exploitation. | ||||
| CVE-2026-105589 | 1 Microsoft | 23 Windows 10 1607, Windows 10 1809, Windows 10 21h2 and 20 more | 2026-11-15 | 7 High |
| Use after free in Windows Wireless Networking allows an authorized attacker to elevate privileges locally. | ||||
| CVE-2026-95975 | 1 Microsoft | 23 Windows 10 1607, Windows 10 1809, Windows 10 21h2 and 20 more | 2026-11-15 | 8.8 High |
| Heap-based buffer overflow in Windows Performance Counters allows an unauthorized attacker to execute code over a network. | ||||
| CVE-2026-96043 | 1 Microsoft | 23 Windows 10 1607, Windows 10 1809, Windows 10 21h2 and 20 more | 2026-11-15 | 7 High |
| Use after free in Windows Connection Manager Service allows an authorized attacker to elevate privileges locally. | ||||
| CVE-2026-96047 | 1 Microsoft | 28 Windows 10 1607, Windows 10 1809, Windows 10 21h2 and 25 more | 2026-11-15 | 7 High |
| Use after free in Windows Installer allows an authorized attacker to elevate privileges locally. | ||||
| CVE-2026-0178 | 1 Google | 1 Android | 2026-11-15 | 6.7 Medium |
| In multiple functions of arm-smmu-v3.c, there is a possible way to bypass direct memory access isolation via stale stream table entries due to a logic error. This could lead to local escalation of privilege with System execution privileges needed. User interaction is not needed for exploitation. | ||||
| CVE-2026-55309 | 1 Google | 1 Android | 2026-11-15 | 8.4 High |
| In multiple functions of verifier.rs, there is a possible way to bypass secure boot signature verification via fault injection due to a logic error. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is not needed for exploitation. | ||||
| CVE-2026-55311 | 1 Google | 1 Android | 2026-11-15 | 8.4 High |
| In N/A of gdmc/gsp/project/gdmc.mk, there is a possible Logic error due to a logic error in the code. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is not needed for exploitation. | ||||
| CVE-2026-55319 | 1 Google | 1 Android | 2026-11-15 | 8.4 High |
| In thread_free of thread.c, there is a possible way to corrupt kernel heap metadata on thread creation failure due to memory corruption. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is not needed for exploitation. | ||||
| CVE-2026-55335 | 1 Google | 1 Android | 2026-11-15 | 9.8 Critical |
| In multiple locations, there is a possible use-after-free due to a logic error in the code. This could lead to remote code execution with no additional execution privileges needed. User interaction is not needed for exploitation. | ||||
| CVE-2026-56916 | 1 Google | 1 Android | 2026-11-15 | 7.8 High |
| In _vqueue_get_avail_buf_locked of trusty/kernel/lib/trusty/vqueue.c, there is a possible Double-read / TOCTOU due to a race condition. This could lead to local escalation of privilege with execution privileges needed. User interaction is for exploitation. | ||||
| CVE-2026-56919 | 1 Google | 1 Android | 2026-11-15 | 8.8 High |
| In PackageSignatureChecker of SystemUIGoogleModule.java, there is a possible background activity launch due to a confused deputy. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is needed for exploitation. | ||||
| CVE-2026-59580 | 1 Google | 1 Android | 2026-11-15 | 3.3 Low |
| In trusty_context_switch of services/spd/trusty/trusty.c, there is a possible Secure world register state leak due to a logic error in the code. This could lead to local information disclosure with execution privileges needed. User interaction is for exploitation. | ||||
| CVE-2026-59586 | 1 Google | 1 Android | 2026-11-15 | 4.0 Medium |
| In multiple locations, there is a possible way to recover cryptographic keys and forge authentication tags due to improperly used crypto. This could lead to local information disclosure with no additional execution privileges needed. User interaction is not needed for exploitation. | ||||
| CVE-2026-97040 | 2026-11-15 | N/A | ||
| Building a package containing a crafted ".syso" file could bypass cgo flag validation and inject arbitrary linker flags when linking. When loading ".syso" entries from a package archive, the linker only checked for recognized host object headers (ELF, Mach-O, PE, and XCOFF) before falling through to Go object parsing. A ".syso" file beginning with a "go object" header was parsed as a Go compiler object, allowing untrusted cgo metadata directives (such as "cgo_ldflag" or "cgo_dynamic_linker") embedded in the ".syso" file to be passed to the external linker without validation. Additionally, ".syso" filenames longer than 16 bytes lost their ".syso" extension when truncated in archive headers, and unrecognized ".syso" formats forced external linking in pure-Go builds. The linker now rejects ".syso" files that are not recognized host object formats, and "cmd/go" and "cmd/pack" preserve the ".syso" suffix when truncating long archive member names. | ||||
| CVE-2026-97035 | 2026-11-15 | N/A | ||
| When using Clang or GCC, building a malicious package that uses cgo could cause unexpected code execution at build time or write files to arbitrary directories via "-gen-*" or "-gnat*" flags in "#cgo" directives. The "-g*" wildcard in the compiler and linker flag allowlists previously matched Clang's two-argument "-gen-cdb-fragment-path <dir>" flag and GCC's two-argument "-gnatO <file>" flag, permitting compilation database fragments and sidecar output files to be written to arbitrary directories and desynchronizing flag argument parsing between the go command and the compiler driver so that subsequent arguments could be passed as unvalidated positional inputs to the linker. "-gen-*" and "-gnat*" flags are now disallowed in "#cgo" compiler and linker flags. | ||||
| CVE-2026-97034 | 2026-11-15 | N/A | ||
| When using GCC, building a malicious package that uses cgo could cause arbitrary command execution at link time via untrusted GCC spec files ("specs" or "*.spec"). When linking with "-fopenmp", "-fopenacc", or "-fsanitize=" in "#cgo LDFLAGS", GCC's built-in link spec evaluates "%:include(libgomp.spec)" or "%:include(libsanitizer.spec)" and searches for spec files in "-L" and sysroot directories (including subdirectories and multilib sibling directories such as "../lib64"), as well as the working directory when "-fopenmp" or "-fopenacc" is used or when "-fsanitize=" is combined with "-static" or "-static-lib*". The go command now rejects "-L", "-isysroot", and "-Wl,-syslibroot" directories (and the working and package directories when applicable) that contain GCC spec files, and disallows "@" and "-" prefixes in "-fsanitize=" compiler flag values. | ||||