Monthly
Sandbox escape in the vm2 Node.js library (npm package patriksimek:vm2, all versions before 3.11.8) lets untrusted JavaScript executed inside a NodeVM instance reach the host process's __proto__ getter/setter through the sandboxed console._stdout and console._stderr objects, overwrite EventEmitter.prototype.emit, and trigger processes events so that attacker code runs with host process context. Per the vendor CVSS:4.0 vector the flaw is remotely reachable with PR:N and UI:N, so any application that feeds network-supplied JavaScript into a NodeVM gains no additional barrier beyond instantiating the sandbox; no authentication or user interaction is required once code reaches the evaluator. There is no KEV listing and no public exploit identified at time of analysis, but the assessed impact is a complete compromise of the hosting process (S:C/C:H/I:H/A:H), which is why this is treated as maximum severity within its threat model. Note that the AV:N rating reflects the common deployment where untrusted scripts arrive over the network - vm2 is not itself a standalone network service, and applications using it only for trusted code are unaffected.
Prototype pollution in the vm2 Node.js sandbox (versions 3.11.0 through 3.11.7) lets JavaScript running inside a VM/NodeVM instance walk the prototype chain into host-realm intrinsics and mutate Uint8Array.prototype, %TypedArray%.prototype, and ArrayBuffer.prototype, so the pollution survives after VM.run() returns and is observed by host-created typed arrays. Because the vm2 usage model is to execute untrusted code, the CVSS 4.0 vector (AV:N/AC:L/PR:N/UI:N, VI:H/VA:H plus SI:H/SA:H) yields a 9.3 Critical sandbox-escape-class rating: unauthenticated remote attackers who can supply the sandboxed script can reach the host realm, though the impact is only realized if the host application subsequently creates or operates on host-side TypedArray/ArrayBuffer instances. No public exploit code was identified at time of analysis and the issue is not listed as confirmed actively exploited (CISA KEV), so risk is driven by upstream supply-chain exposure of applications embedding vm2 as an untrusted-code boundary. The vulnerability was reported by VulnCheck and is tracked under CWE-913.
Sandbox escape leading to remote code execution affects the vm2 Node.js sandbox library before version 3.11.7 when the embedding application enables require.external without an explicit require.root that excludes node_modules. Under that configuration, attacker-supplied JavaScript running inside the sandbox can require vm2's own package, construct an unrestricted NodeVM instance, and then execute arbitrary host OS commands through child_process, yielding a complete escape from the sandbox to the underlying operating system. Exploitation requires two operator-chosen, non-default preconditions (running untrusted code in vm2 AND the permissive require configuration), so deployments that leave require.external disabled or pin require.root away from node_modules are not exposed; no public exploit code was identified at time of analysis, and the vendor-released fix is version 3.11.7.
Sandbox escape and remote code execution in vm2 versions 3.11.4 through 3.11.6 allow JavaScript executed inside a NodeVM to break out and run arbitrary commands with the privileges of the host Node.js process. The flaw is reachable only in a specific, non-default configuration where the NodeVM is created with a truthy `nesting` value and an array-shaped `require` option (for example `new NodeVM({nesting: true, require: []})`); in that case the array satisfies a guard intended to reject nesting without an explicit require configuration, and the resulting resolver falls back to a nesting override that permits the sandboxed code to require the host `vm2` module and construct an inner NodeVM with an attacker-chosen builtin allowlist such as `child_process`. Exploitation requires no authentication or user interaction (CVSS 4.0 vector reports PR:N/UI:N) beyond the ability to supply code the sandbox runs, which is vm2's intended threat model; there is no public exploit code or CISA KEV confirmation of active exploitation at time of analysis, but the impact is complete confidentiality, integrity, and availability loss on the host, and the vendor CVSS 4.0 score of 9.5 is consistent with that assessed impact.
Authenticated IBM MQ users can trigger arbitrary code execution on the application server through the Resource Adapter Installation Verification Test (IVT) application, which fails to properly validate JNDI names. The flaw affects a broad swath of IBM MQ releases: 9.1.0.0–9.1.0.37 LTS, 9.2.0.0–9.2.0.43 LTS, 9.3.0.0–9.3.0.41 LTS, 9.3.0.0–9.3.5.1 CD, 9.4.0.0–9.4.0.25 LTS, 9.4.0.0–9.4.5.1 CD, and 10.0.0.0. No public exploit code or CISA KEV entry has been identified at time of analysis, but a vendor patch is available and the CVSS 3.1 base score is 7.5 (AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H), indicating full confidentiality, integrity, and availability impact once the attack conditions are met.
Remote code execution in Apache Impala 2.7.0 through 4.5.1 allows an authorized user with table-creation and remote-storage upload privileges to load and execute arbitrary Java classes on Impala daemon nodes by exploiting insufficient authorization controls over External Data Source tables. The vulnerability abuses Impala's legitimate extensibility feature - Data Source tables - which permits custom Java class loading from remote storage; insufficient authorization checks mean any user holding those two combined privileges can weaponize the feature for server-side code execution. No public exploit code or active exploitation (CISA KEV) has been identified at time of analysis; upgrade to 4.5.2 is the vendor-confirmed fix.
Safety-guard bypass in the Spring Framework SpEL engine (VMware/Broadcom) lets attacker-controlled expression input escape the restricted SimpleEvaluationContext sandbox when the SpEL bytecode compiler is active, affecting Spring Framework 5.2.x through 7.0.8 across the 5.3, 6.0, 6.1, 6.2 and 7.0 lines. Because SimpleEvaluationContext is the API applications are told to use to safely evaluate untrusted expressions, this bypass can escalate a data-binding-only context into broader method invocation with high integrity and availability impact (CVSS 9.1, CWE-913). There is no public exploit identified at time of analysis, and EPSS is low (0.16%, 5th percentile), indicating no observed mass exploitation yet.
Sandbox escape in Google Chrome's Linux Toolkit Theming component (prior to 151.0.7922.173) allows a remote attacker who has already compromised the renderer process to execute arbitrary code outside the Chrome sandbox via a crafted HTML page. This is a two-stage attack: the renderer must be compromised first, then this CWE-913 flaw in the theming subsystem is leveraged to break out of the sandbox entirely, achieving host-level code execution. No public exploit code or CISA KEV listing has been identified at time of analysis; EPSS sits at 0.38% (32nd percentile), consistent with an absence of observed mass exploitation.
Privilege escalation in the search-v2-operator (Red Hat Advanced Cluster Management / OpenShift search component) allows a user with edit rights on the Search Custom Resource to abuse unvalidated CR fields (imageOverride, arguments, environment variables) to load an attacker-controlled container image or mount arbitrary secrets. Because the search ServiceAccount holds broad impersonation permissions, controlling that pod pivots into full cluster compromise. No public exploit is identified at time of analysis, and it is not listed in CISA KEV; the CVSS 9.1 rating reflects the scope change from a namespaced CR editor to the entire cluster.
Sandbox escape in the vm2 Node.js sandboxing library (npm, versions <= 3.11.5) lets code running inside the sandbox reach host prototype mutators and execute arbitrary OS commands on the host. It bypasses the earlier GHSA-v6mx-mf47-r5wg fix by stacking Function.prototype.call indirection so the dangerous __proto__ setter is no longer in the inspected position, then leaks a live host reference through a rejected WebAssembly.compileStreaming promise to pivot to child_process. A working proof-of-concept is published in the advisory, so publicly available exploit code exists; the flaw is not listed in CISA KEV.
Sandbox escape in the vm2 Node.js library (npm package patriksimek:vm2, all versions before 3.11.8) lets untrusted JavaScript executed inside a NodeVM instance reach the host process's __proto__ getter/setter through the sandboxed console._stdout and console._stderr objects, overwrite EventEmitter.prototype.emit, and trigger processes events so that attacker code runs with host process context. Per the vendor CVSS:4.0 vector the flaw is remotely reachable with PR:N and UI:N, so any application that feeds network-supplied JavaScript into a NodeVM gains no additional barrier beyond instantiating the sandbox; no authentication or user interaction is required once code reaches the evaluator. There is no KEV listing and no public exploit identified at time of analysis, but the assessed impact is a complete compromise of the hosting process (S:C/C:H/I:H/A:H), which is why this is treated as maximum severity within its threat model. Note that the AV:N rating reflects the common deployment where untrusted scripts arrive over the network - vm2 is not itself a standalone network service, and applications using it only for trusted code are unaffected.
Prototype pollution in the vm2 Node.js sandbox (versions 3.11.0 through 3.11.7) lets JavaScript running inside a VM/NodeVM instance walk the prototype chain into host-realm intrinsics and mutate Uint8Array.prototype, %TypedArray%.prototype, and ArrayBuffer.prototype, so the pollution survives after VM.run() returns and is observed by host-created typed arrays. Because the vm2 usage model is to execute untrusted code, the CVSS 4.0 vector (AV:N/AC:L/PR:N/UI:N, VI:H/VA:H plus SI:H/SA:H) yields a 9.3 Critical sandbox-escape-class rating: unauthenticated remote attackers who can supply the sandboxed script can reach the host realm, though the impact is only realized if the host application subsequently creates or operates on host-side TypedArray/ArrayBuffer instances. No public exploit code was identified at time of analysis and the issue is not listed as confirmed actively exploited (CISA KEV), so risk is driven by upstream supply-chain exposure of applications embedding vm2 as an untrusted-code boundary. The vulnerability was reported by VulnCheck and is tracked under CWE-913.
Sandbox escape leading to remote code execution affects the vm2 Node.js sandbox library before version 3.11.7 when the embedding application enables require.external without an explicit require.root that excludes node_modules. Under that configuration, attacker-supplied JavaScript running inside the sandbox can require vm2's own package, construct an unrestricted NodeVM instance, and then execute arbitrary host OS commands through child_process, yielding a complete escape from the sandbox to the underlying operating system. Exploitation requires two operator-chosen, non-default preconditions (running untrusted code in vm2 AND the permissive require configuration), so deployments that leave require.external disabled or pin require.root away from node_modules are not exposed; no public exploit code was identified at time of analysis, and the vendor-released fix is version 3.11.7.
Sandbox escape and remote code execution in vm2 versions 3.11.4 through 3.11.6 allow JavaScript executed inside a NodeVM to break out and run arbitrary commands with the privileges of the host Node.js process. The flaw is reachable only in a specific, non-default configuration where the NodeVM is created with a truthy `nesting` value and an array-shaped `require` option (for example `new NodeVM({nesting: true, require: []})`); in that case the array satisfies a guard intended to reject nesting without an explicit require configuration, and the resulting resolver falls back to a nesting override that permits the sandboxed code to require the host `vm2` module and construct an inner NodeVM with an attacker-chosen builtin allowlist such as `child_process`. Exploitation requires no authentication or user interaction (CVSS 4.0 vector reports PR:N/UI:N) beyond the ability to supply code the sandbox runs, which is vm2's intended threat model; there is no public exploit code or CISA KEV confirmation of active exploitation at time of analysis, but the impact is complete confidentiality, integrity, and availability loss on the host, and the vendor CVSS 4.0 score of 9.5 is consistent with that assessed impact.
Authenticated IBM MQ users can trigger arbitrary code execution on the application server through the Resource Adapter Installation Verification Test (IVT) application, which fails to properly validate JNDI names. The flaw affects a broad swath of IBM MQ releases: 9.1.0.0–9.1.0.37 LTS, 9.2.0.0–9.2.0.43 LTS, 9.3.0.0–9.3.0.41 LTS, 9.3.0.0–9.3.5.1 CD, 9.4.0.0–9.4.0.25 LTS, 9.4.0.0–9.4.5.1 CD, and 10.0.0.0. No public exploit code or CISA KEV entry has been identified at time of analysis, but a vendor patch is available and the CVSS 3.1 base score is 7.5 (AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H), indicating full confidentiality, integrity, and availability impact once the attack conditions are met.
Remote code execution in Apache Impala 2.7.0 through 4.5.1 allows an authorized user with table-creation and remote-storage upload privileges to load and execute arbitrary Java classes on Impala daemon nodes by exploiting insufficient authorization controls over External Data Source tables. The vulnerability abuses Impala's legitimate extensibility feature - Data Source tables - which permits custom Java class loading from remote storage; insufficient authorization checks mean any user holding those two combined privileges can weaponize the feature for server-side code execution. No public exploit code or active exploitation (CISA KEV) has been identified at time of analysis; upgrade to 4.5.2 is the vendor-confirmed fix.
Safety-guard bypass in the Spring Framework SpEL engine (VMware/Broadcom) lets attacker-controlled expression input escape the restricted SimpleEvaluationContext sandbox when the SpEL bytecode compiler is active, affecting Spring Framework 5.2.x through 7.0.8 across the 5.3, 6.0, 6.1, 6.2 and 7.0 lines. Because SimpleEvaluationContext is the API applications are told to use to safely evaluate untrusted expressions, this bypass can escalate a data-binding-only context into broader method invocation with high integrity and availability impact (CVSS 9.1, CWE-913). There is no public exploit identified at time of analysis, and EPSS is low (0.16%, 5th percentile), indicating no observed mass exploitation yet.
Sandbox escape in Google Chrome's Linux Toolkit Theming component (prior to 151.0.7922.173) allows a remote attacker who has already compromised the renderer process to execute arbitrary code outside the Chrome sandbox via a crafted HTML page. This is a two-stage attack: the renderer must be compromised first, then this CWE-913 flaw in the theming subsystem is leveraged to break out of the sandbox entirely, achieving host-level code execution. No public exploit code or CISA KEV listing has been identified at time of analysis; EPSS sits at 0.38% (32nd percentile), consistent with an absence of observed mass exploitation.
Privilege escalation in the search-v2-operator (Red Hat Advanced Cluster Management / OpenShift search component) allows a user with edit rights on the Search Custom Resource to abuse unvalidated CR fields (imageOverride, arguments, environment variables) to load an attacker-controlled container image or mount arbitrary secrets. Because the search ServiceAccount holds broad impersonation permissions, controlling that pod pivots into full cluster compromise. No public exploit is identified at time of analysis, and it is not listed in CISA KEV; the CVSS 9.1 rating reflects the scope change from a namespaced CR editor to the entire cluster.
Sandbox escape in the vm2 Node.js sandboxing library (npm, versions <= 3.11.5) lets code running inside the sandbox reach host prototype mutators and execute arbitrary OS commands on the host. It bypasses the earlier GHSA-v6mx-mf47-r5wg fix by stacking Function.prototype.call indirection so the dangerous __proto__ setter is no longer in the inspected position, then leaks a live host reference through a rejected WebAssembly.compileStreaming promise to pivot to child_process. A working proof-of-concept is published in the advisory, so publicly available exploit code exists; the flaw is not listed in CISA KEV.