Total
395079 CVE
| CVE | Vendors | Products | Updated | CVSS v2 | CVSS v3 |
|---|---|---|---|---|---|
| CVE-2026-69572 | 1 Microsoft | 13 Windows 10 1607, Windows 10 1809, Windows 10 21h2 and 10 more | 2026-09-17 | N/A | 5.7 MEDIUM |
| Out-of-bounds read in Windows SMB Client allows an authorized attacker to disclose information over a network. | |||||
| CVE-2026-76797 | 1 Mongodb | 1 Mongosql Transition Readiness Tool | 2026-09-17 | N/A | 6.3 MEDIUM |
| The MongoSQL Transition Readiness Tool writes database and collection names into its generated CSV reports without neutralizing leading characters that spreadsheet applications treat as formulas. A user with write privileges on the cluster can choose a namespace name that is later evaluated as a formula when an operator opens the generated report in a spreadsheet application, which may result in unintended disclosure of report contents or execution of external content on the operator's workstation. Generating a report for the affected namespace and opening it in a spreadsheet application is required. | |||||
| CVE-2026-76798 | 1 Mongodb | 1 Mongosql Transition Readiness Tool | 2026-09-17 | N/A | 6.3 MEDIUM |
| The MongoSQL Transition Readiness Tool writes query text and user names read from BI Connector log files into its generated HTML report without encoding them for that output context. A user able to issue queries through the BI Connector can influence log content so that markup supplied in a query is interpreted by the browser when an operator later generates and opens the report, which may disclose other users' logged query text and user names to an external party or present misleading content to the operator. Generating a report over logs containing the affected entries and opening that report in a browser is required. | |||||
| CVE-2026-76794 | 1 Mongodb | 1 Mongosql Transition Readiness Tool | 2026-09-17 | N/A | 4.6 MEDIUM |
| MongoSQL Transition Readiness Tool does not sufficiently encode database metadata before including it in generated HTML. A MongoDB user with write access can introduce crafted metadata that may cause script code to run when another user generates and opens the report, potentially exposing report contents or altering its display. | |||||
| CVE-2026-69267 | 1 Microsoft | 10 Windows 10 1809, Windows 10 21h2, Windows 10 22h2 and 7 more | 2026-09-17 | N/A | 6.5 MEDIUM |
| Insufficient granularity of access control in Windows Connected User Experiences and Telemetry allows an authorized attacker to disclose information locally. | |||||
| CVE-2026-20683 | 1 Apple | 4 Ipados, Iphone Os, Macos and 1 more | 2026-09-17 | N/A | 7.1 HIGH |
| An authentication issue was addressed with improved state management. This issue is fixed in iOS 27 and iPadOS 27, macOS Golden Gate 27, macOS Sequoia 15.8, macOS Tahoe 26.7, visionOS 27. An app may be able to use the Sign In With Apple authentication flow to access the user's Apple Account. | |||||
| CVE-2026-84559 | 1 Apple | 1 Macos | 2026-09-17 | N/A | 5.5 MEDIUM |
| A permissions issue was addressed with improved validation. This issue is fixed in macOS Golden Gate 27, macOS Sequoia 15.8, macOS Tahoe 26.7. A malicious application may be able to access restricted files. | |||||
| CVE-2012-5825 | 1 Tweepy | 1 Tweepy | 2026-09-17 | 5.8 MEDIUM | 7.4 HIGH |
| Tweepy does not verify that the server hostname matches a domain name in the subject's Common Name (CN) or subjectAltName field of the X.509 certificate, which allows man-in-the-middle attackers to spoof SSL servers via an arbitrary valid certificate, related to use of the Python httplib library. | |||||
| CVE-2026-92970 | 2026-09-17 | N/A | 8.8 HIGH | ||
| HUBzero CMS through 2.2.32 contains a path traversal vulnerability in project file upload handlers that allows authenticated project members to write arbitrary files outside the project repository. Attackers can supply traversal sequences in upload parameters to write files to attacker-chosen paths with web server privileges, potentially enabling code execution. | |||||
| CVE-2026-92963 | 2026-09-17 | N/A | 5.3 MEDIUM | ||
| vm2 versions before 3.11.2 fail to properly restrict access to the VM2_INTERNAL_STATE_DO_NOT_USE_OR_PROGRAM_WILL_FAIL global variable. Attackers can access this internal state object through globalThis to retrieve sensitive sandbox internals. | |||||
| CVE-2026-92961 | 2026-09-17 | N/A | 7.5 HIGH | ||
| vm2 before 3.11.6 fails to enforce bufferAllocLimit on ArrayBuffer, SharedArrayBuffer, and TypedArray constructors, allowing attackers to allocate arbitrary host memory. Attackers can bypass the buffer allocation cap by using these V8 intrinsics to exhaust host process memory and trigger out-of-memory conditions. | |||||
| CVE-2026-92959 | 2026-09-17 | N/A | 7.1 HIGH | ||
| vm2 before 3.11.8 does not fully enforce the allowAsync: false option in VM and NodeVM. While localPromise.prototype.then is replaced with a handler that throws 'Async not available', the sandbox's Promise static methods (Promise.resolve, Promise.all, Promise.race, Promise.any, and Promise.allSettled) still assimilate attacker-supplied thenables: native promise resolution performs PromiseResolveThenableJob and invokes the sandboxed code's then method in a microtask without passing through the patched then, so the async restriction is never applied. As a result, sandboxed script can schedule work that runs after VM.run() or NodeVM.run() has returned and outside the configured timeout, continuing to execute after the host believes execution is complete. | |||||
| CVE-2026-92958 | 2026-09-17 | N/A | 8.5 HIGH | ||
| vm2 through 3.11.6 contains a builtin-module denylist bypass in NodeVM. When the embedder uses the builtin wildcard together with negative entries (e.g. require: { builtin: ['*', '-fs', '-child_process'] }), negative entries are matched by exact module name in lib/builtin.js, so -fs removes only the builtin named fs and does not remove builtin subpaths such as fs/promises. Sandboxed code can therefore call require('fs/promises') or require('node:fs/promises') and reach the promise-based filesystem API despite fs being denied; node: prefix handling is likewise inconsistent (a -node:fs/promises entry does not block require('fs/promises')). Host file creation and writing were confirmed via fsp.writeFile(), and other fs/promises operations (cp, mkdir, rename, rm, rmdir, truncate, read operations, etc.) are also reachable. This issue is fixed in vm2 3.11.7. | |||||
| CVE-2026-92954 | 2026-09-17 | N/A | 8.6 HIGH | ||
| vm2 is a sandbox library for running untrusted JavaScript in Node.js. In versions >= 3.10.0 and <= 3.11.7, Promises returned from the host realm into the sandbox are not marked as handled at the bridge boundary; only Promises created inside the sandbox are wrapped with a rejection-swallowing handler (lib/setup-sandbox.js), and the bridge only installs host-side rejection sanitizers when sandbox code calls .then/.catch/.finally. As a result, code running in the sandbox can invoke a host function that returns a rejected Promise (for example events.once() exposed via the NodeVM events builtin, or any embedder-provided Promise-returning API) and simply ignore the return value, leaving the host Promise unhandled so that Node.js's default unhandled-rejection behavior terminates the host process. This is an incomplete fix of GHSA-hw58-p9xv-2mjh. The issue is fixed in version 3.11.8. | |||||
| CVE-2026-92953 | 2026-09-17 | N/A | 10.0 CRITICAL | ||
| vm2 versions from 3.11.0 before 3.11.8 fail to protect host TypedArray and ArrayBuffer prototypes from sandbox mutation. Attackers can use prototype-walking primitives to reach and modify host Uint8Array.prototype, %TypedArray%.prototype, and ArrayBuffer.prototype, causing host-created typed arrays to observe attacker-controlled properties after VM.run() returns. | |||||
| CVE-2026-92949 | 2026-09-17 | N/A | 4.0 MEDIUM | ||
| vm2 versions from 3.9.6 before 3.11.7 fail to properly restrict access to accessor properties on frozen objects, allowing sandboxed scripts to bypass vm.freeze() and vm.readonly() protections. Attackers can use Object.getOwnPropertyDescriptor() or __lookupSetter__() to extract and invoke host object setters directly, mutating properties the embedder explicitly marked read-only. | |||||
| CVE-2026-92948 | 2026-09-17 | N/A | 9.9 CRITICAL | ||
| vm2 versions >= 3.9.6 and <= 3.11.6 are affected by a NodeVM builtin allowlist bypass that permits a sandbox escape on Node.js 24 and newer when the embedder explicitly allows the node:test builtin (e.g. require: { builtin: ['node:test'] }). On Node.js 24+, module.builtinModules exposes the scheme-only key node:test, which is not covered by vm2's family-based DANGEROUS_BUILTINS protection, so it is stored in the generic host-passthrough loader. Because requireImpl() in lib/setup-node-sandbox.js strips a single 'node:' prefix before the builtin lookup, sandbox code calling require('node:node:test') resolves to the stored node:test key and receives a readonly proxy to the host module. Calls to node:test.run() are forwarded to the host implementation, which spawns a separate Node process for process-isolated test execution and passes through attacker-controlled execArgv values; supplying --eval=<JavaScript> therefore executes arbitrary JavaScript in an unrestricted host Node process outside the NodeVM sandbox. Fixed in vm2 3.11.7. | |||||
| CVE-2026-92944 | 2026-09-17 | N/A | 9.8 CRITICAL | ||
| vm2 versions 3.10.2 through 3.11.6 contain a sandbox escape vulnerability on Node.js 26 where Promise.prototype.finally() bypasses vm2's wrapper protections due to a stale PromiseThenLookupChain protector in V8 14.6. Attackers can exploit this by creating an async function that returns a Promise with an attacker-controlled constructor Symbol.species, allowing them to reach the host Function constructor and process object for arbitrary code execution. | |||||
| CVE-2026-92942 | 2026-09-17 | N/A | 7.5 HIGH | ||
| vm2 before 3.11.7 (affected versions <= 3.11.6) does not enforce the VM({ timeout }) option on code executed outside the synchronous VM#run() call. The timeout only wraps the single call to _runScript() via doWithTimeout() in lib/vm.js, and FinalizationRegistry and WeakRef are exposed to sandboxed code unmodified (they are not among the hardened globals in lib/setup-sandbox.js). Sandboxed code can register a FinalizationRegistry cleanup callback against an object and then drop the only strong reference to it; vm.run() returns within the configured timeout, but when the V8 garbage collector later reclaims the object it invokes the sandboxed cleanup callback outside any vm2 timeout accounting. A busy loop in that callback blocks the host event loop for an unbounded period, resulting in denial of service. The time of invocation depends on the garbage collector (e.g. under memory pressure or with --expose-gc). | |||||
| CVE-2026-92938 | 2026-09-17 | N/A | 9.9 CRITICAL | ||
| vm2 versions 3.11.3 through 3.11.6 expose Node.js's host node:sqlite module to code running in NodeVM when that builtin is permitted, either explicitly or through builtin: ['*']. The module is wrapped with vm.readonly(), which prevents property assignment but leaves host-authority callables reachable; in addition, the resolver treats any request starting with 'node:' as a core-module request and the runtime strips only one 'node:' prefix, so a sandbox request for 'node:node:sqlite' resolves to the configured node:sqlite entry. Sandboxed code can therefore create an in-memory DatabaseSync with extension loading enabled and call DatabaseSync.loadExtension() on a native library bundled in the untrusted plugin package (path derived from __dirname). SQLite loads the library into the Node.js host process and invokes its native entry point, giving the sandboxed plugin arbitrary native code execution outside the sandbox with the host process's privileges. The issue is fixed in vm2 3.11.7. | |||||