Search
Search Results (9 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2026-12032 | 1 Google | 2 Android, Chrome | 2026-06-22 | 3.1 Low |
| Inappropriate implementation in Passwords in Google Chrome on Android prior to 149.0.7827.115 allowed a remote attacker who had compromised the renderer process to bypass site isolation via a crafted HTML page. (Chromium security severity: High) | ||||
| CVE-2026-8568 | 1 Google | 1 Chrome | 2026-06-16 | 6.2 Medium |
| Determined not a vulnerability | ||||
| CVE-2026-47135 | 1 Patriksimek | 1 Vm2 | 2026-06-13 | 8.7 High |
| vm2 is an open source vm/sandbox for Node.js. Prior to version 3.11.4, Symbol.for override in setup-sandbox.js only intercepts 2 of 9 dangerous Node.js cross-realm symbols. Combined with the bridge's set/defineProperty/deleteProperty traps having no isDangerousCrossRealmSymbol key check, sandbox code can obtain real cross-realm symbols, write them to host objects, and control host-side behavior — verified with a full util.promisify hijack chain. This issue has been patched in version 3.11.4. | ||||
| CVE-2026-47139 | 1 Patriksimek | 1 Vm2 | 2026-06-12 | 8.6 High |
| vm2 is an open source vm/sandbox for Node.js. Prior to version 3.11.4, NodeVM supports excluding public network builtins from the wildcard builtin option. With this configuration direct access to http, https, http2, net, dgram, tls, dns, and dns/promises is blocked. However, Node.js also exposes underscored internal HTTP builtins such as _http_client and _http_server. These are not blocked when the public modules are excluded. Sandboxed code can use these internal builtins to make outbound HTTP requests and open listening HTTP sockets even though the public network modules are denied. This issue has been patched in version 3.11.4. | ||||
| CVE-2026-11689 | 4 Apple, Google, Linux and 1 more | 4 Macos, Chrome, Linux Kernel and 1 more | 2026-06-10 | 8.1 High |
| Insufficient policy enforcement in Passwords in Google Chrome prior to 149.0.7827.103 allowed a remote attacker who had compromised the renderer process to bypass site isolation via a crafted HTML page. (Chromium security severity: High) | ||||
| CVE-2026-44007 | 2 Patriksimek, Vm2 Project | 2 Vm2, Vm2 | 2026-05-15 | 9.1 Critical |
| vm2 is an open source vm/sandbox for Node.js. Prior to 3.11.1, when a NodeVM is created with nesting: true, sandbox code can unconditionally require('vm2') regardless of the outer VM's require configuration — including require: false. With access to vm2, the sandbox constructs a new inner NodeVM with its own unrestricted require settings and executes arbitrary OS commands on the host. Any application that runs untrusted code inside a NodeVM with nesting: true is fully compromised. This vulnerability is fixed in 3.11.1. | ||||
| CVE-2026-44008 | 2 Patriksimek, Vm2 Project | 2 Vm2, Vm2 | 2026-05-14 | 9.8 Critical |
| vm2 is an open source vm/sandbox for Node.js. Prior to 3.11.2, the new method neutralizeArraySpeciesBatch works with objects from the other side but can call into this side via getter on the array prototype exposing objects of the wrong side into the sandbox. This can be used to get host objects and get the host Function object. This allows attackers to write code which can escape from the VM2 sandbox and execute arbitrary commands on the host system. This vulnerability is fixed in 3.11.2. | ||||
| CVE-2025-3466 | 1 Langgenius | 1 Dify | 2025-07-13 | 7.2 High |
| langgenius/dify versions 1.1.0 to 1.1.2 are vulnerable to unsanitized input in the code node, allowing execution of arbitrary code with full root permissions. The vulnerability arises from the ability to override global functions in JavaScript, such as parseInt, before sandbox security restrictions are imposed. This can lead to unauthorized access to secret keys, internal network servers, and lateral movement within dify.ai. The issue is resolved in version 1.1.3. | ||||
| CVE-2024-9612 | 1 Onyx | 1 Onyx | 2025-04-03 | 6.5 Medium |
| In danswer-ai/danswer v0.3.94, administrators can set the visibility of pages within a workspace, including the search page. When the search page is set to be invisible, regular users cannot view the search page or access its functionalities from the front-end interface. However, the back-end does not verify the visibility status of the search page. Consequently, attackers can directly call the API to access the functionalities provided by the search page, bypassing the visibility restriction set by the administrator. | ||||
Page 1 of 1.