CWE-653

A security issue was discovered in Kubernetes where under certain conditions, an unauthenticated attacker with access to the pod network can achieve arbitrary code execution in the context of the ingress-nginx controller. This can lead to disclosure of Secrets accessible to the controller. (Note that in the default installation, the controller can access all Secrets cluster-wide.)

Apache Syncope offers the ability to extend / customize the base behavior on every deployment by allowing to provide custom implementations of a few Java interfaces; such implementations can be provided either as Java or Groovy classes, with the latter being particularly attractive as the machinery is set for runtime reload. Such a feature has been available for a while, but recently it was discovered that a malicious administrator can inject Groovy code that can be executed remotely by a running Apache Syncope Core instance. Users are recommended to upgrade to version 3.0.14 / 4.0.2, which fix this issue by forcing the Groovy code to run in a sandbox.

An Improper Isolation or Compartmentalization vulnerability in the kernel of Juniper Networks Junos OS allows a local attacker with high privileges to compromise the integrity of the device. A local attacker with access to the shell is able to inject arbitrary code which can compromise an affected device. This issue is not exploitable from the Junos CLI. This issue affects Junos OS:  * All versions before 21.2R3-S9, * 21.4 versions before 21.4R3-S10,  * 22.2 versions before 22.2R3-S6,  * 22.4 versions before 22.4R3-S6,  * 23.2 versions before 23.2R2-S3,  * 23.4 versions before 23.4R2-S4, * 24.2 versions before 24.2R1-S2, 24.2R2.

vm2 is an open source vm/sandbox for Node.js. Prior to version 3.11.0, VM2 suffers from a sandbox breakout vulnerability through the inspect function. This allows attackers to write code which can escape from the VM2 sandbox and execute arbitrary commands on the host system. This issue has been patched in version 3.11.0.

NVIDIA Container Toolkit contains an improper isolation vulnerability where a specially crafted container image could lead to modification of a host binary. A successful exploit of this vulnerability may lead to code execution, denial of service, escalation of privileges, information disclosure, and data tampering.

vm2 is an open source vm/sandbox for Node.js. Prior to 3.11.0, it is possible to obtain the host Object. There are various ways to use the host Object, to escape the sandbox, one example would be using HostObject.getOwnPropertySymbols to obtain Symbol(nodejs.util.inspect.custom). This vulnerability is fixed in 3.11.0.

vm2 is an open source vm/sandbox for Node.js. In version 3.10.4, vm2 is vulnerable to full sandbox escape with arbitrary code execution. Attacker code inside VM.run() obtains host process object and runs host commands with zero host cooperation. This issue has been patched in version 3.10.5.

lunasvg v2.3.9 was discovered to contain a segmentation violation via the component composition_solid_source_over.

vm2 is an open source vm/sandbox for Node.js. From 3.9.6 to 3.10.5, vm2's bridge exposes mutable proxies for real host-realm intrinsic prototypes and then forwards sandbox writes into the underlying host objects with otherReflectSet() and otherReflectDefineProperty(), which lets attacker-controlled JavaScript running in a default VM or inherited NodeVM mutate shared host Object.prototype, Array.prototype, and Function.prototype from inside the sandbox This vulnerability is fixed in 3.11.0.

vm2 is an open source vm/sandbox for Node.js. Prior to 3.11.2, This vulnerability is fixed in 3.11.2.

An authenticated attacker can leverage an exposed “box” object to read and write arbitrary files from disk, provided those files can be parsed as yaml or JSON. This issue was resolved in the Managed and SaaS deployments on February 1, 2023, and in version 23.2.1 of the Self-Managed version of InsightCloudSec.

vm2 is an open source vm/sandbox for Node.js. Prior to version 3.11.0, SuppressedError allows attackers to escape the sandbox and run arbitrary code. This issue has been patched in version 3.11.0.

Improper Isolation or Compartmentalization vulnerability in Apache Syncope. An administrator with adequate entitlements can achieve remote code execution through the connector subsystem by relying on scripted connectors' (REST and SQL) capability to run Groovy scripts. This issue affects Apache Syncope: from 3.0.0-M0 through 3.0.16, from 4.0.0-M0 Through 4.0.6, from 4.1.0-M0 through 4.1.1. Users are recommended to upgrade to version 4.0.7 / 4.1.2, which fix this issue by hardening the Groovy security sandbox.

NVIDIA Container Toolkit contains an improper isolation vulnerability where a specially crafted container image could lead to untrusted code obtaining read and write access to host devices. This vulnerability is present only when the NVIDIA Container Toolkit is configured in a nondefault way. A successful exploit of this vulnerability may lead to code execution, denial of service, escalation of privileges, information disclosure, and data tampering.

Improper Isolation or Compartmentalization vulnerability in Apache Syncope. An administrator with adequate entitlements for Implementations can create a malicious Groovy class containing untrusted code reaching a non-sandboxed execution path via the class static initializer. This issue affects Apache Syncope: 3.0 through 3.0.16, 4.0 through 4.0.5, 4.1.0. Users are recommended to upgrade to version 4.0.6 / 4.1.1, which fix this issue by forcing even the static initializer in Groovy code to run in a sandbox.

A high privileged remote attacker can execute arbitrary OS commands using an undocumented method allowing to escape the implemented LUA sandbox.

ServiceNow has addressed a remote code execution vulnerability that was identified in the ServiceNow AI platform. This vulnerability could enable an unauthenticated user, in certain circumstances, to execute code within the ServiceNow Sandbox.    ServiceNow addressed this vulnerability by deploying a security update to hosted instances. Relevant security updates also have been provided to ServiceNow self-hosted customers and partners. Further, the vulnerability is addressed in the listed patches and hot fixes. While we are not currently aware of exploitation against customer instances, we recommend customers promptly apply appropriate updates or upgrade if they have not already done so.

In Grafana, the wrong permission is applied to the alert rule write API endpoint, allowing users with permission to write external alert instances to also write alert rules.

The Bare Metal Operator (BMO) implements a Kubernetes API for managing bare metal hosts in Metal3. The `BareMetalHost` (BMH) CRD allows the `userData`, `metaData`, and `networkData` for the provisioned host to be specified as links to Kubernetes Secrets. There are fields for both the `Name` and `Namespace` of the Secret, meaning that versions of the baremetal-operator prior to 0.8.0, 0.6.2, and 0.5.2 will read a `Secret` from any namespace. A user with access to create or edit a `BareMetalHost` can thus exfiltrate a `Secret` from another namespace by using it as e.g. the `userData` for provisioning some host (note that this need not be a real host, it could be a VM somewhere). BMO will only read a key with the name `value` (or `userData`, `metaData`, or `networkData`), so that limits the exposure somewhat. `value` is probably a pretty common key though. Secrets used by _other_ `BareMetalHost`s in different namespaces are always vulnerable. It is probably relatively unusual for anyone other than cluster administrators to have RBAC access to create/edit a `BareMetalHost`. This vulnerability is only meaningful, if the cluster has users other than administrators and users' privileges are limited to their respective namespaces. The patch prevents BMO from accepting links to Secrets from other namespaces as BMH input. Any BMH configuration is only read from the same namespace only. The problem is patched in BMO releases v0.7.0, v0.6.2 and v0.5.2 and users should upgrade to those versions. Prior upgrading, duplicate the BMC Secrets to the namespace where the corresponding BMH is. After upgrade, remove the old Secrets. As a workaround, an operator can configure BMO RBAC to be namespace scoped for Secrets, instead of cluster scoped, to prevent BMO from accessing Secrets from other namespaces.

Sandbox escape in the Responsive Design Mode component. This vulnerability was fixed in Firefox 149, Firefox ESR 115.34, Firefox ESR 140.9, Thunderbird 149, and Thunderbird 140.9.

Improper isolation or compartmentalization in Azure PromptFlow allows an unauthorized attacker to execute code over a network.

A vulnerability was found in OpenStack Barbican containers. This vulnerability is only applicable to deployments that utilize an all-in-one configuration. Barbican containers share the same CGROUP, USER, and NET namespace with the host system and other OpenStack services. If any service is compromised, it could gain access to the data transmitted to and from Barbican.

Improper Isolation or Compartmentalization vulnerability in Apache Syncope. An administrator with adequate entitlements can import arbitrary BPMN process definitions via the REST API and then start the process. When a BPMN process containing a Groovy scriptTask is imported and started, the Groovy script is executed directly on the server, with no sandbox. This issue affects Apache Syncope: from 3.0.0-M0 through 3.0.16, from 4.0.0-M0 Through 4.0.6, from 4.1.0-M0 through 4.1.1. Users are recommended to upgrade to version 4.0.7 / 4.1.2, which fix this issue by wrapping Flowable's Groovy scriptTasks with security sandbox.

Improper Isolation or Compartmentalization vulnerability in Apache Syncope. An administrator with adequate entitlements for Implementations can create a malicious Groovy class containing untrusted code bypassing the Groovy security sandbox. This issue affects Apache Syncope: from 3.0.0-M0 through 3.0.16, from 4.0.0-M0 through 4.0.6, from 4.1.0-M0 through 4.1.1. Users are recommended to upgrade to version 4.0.7 / 4.1.2, which fix this issue by tightening the Groovy security sandbox.

A flaw was found in Keycloak. The SingleUseObjectProvider, a global key-value store, lacks proper type and namespace isolation. This vulnerability allows an unauthenticated attacker to forge authorization codes. Successful exploitation can lead to the creation of admin-capable access tokens, resulting in privilege escalation.

A process isolation vulnerability in Thunderbird stemmed from improper handling of javascript: URIs, which could allow content to execute in the top-level document's process instead of the intended frame, potentially enabling a sandbox escape. This vulnerability was fixed in Firefox 138, Firefox ESR 128.10, Firefox ESR 115.23, Thunderbird 138, and Thunderbird 128.10.

Centurion ERP (Enterprise Rescource Planning) is a simple application developed to provide open source IT management with a large emphasis on the IT Service Management (ITSM) modules. A user who is authenticated and has view permissions for a ticket, can view the tickets of another organization they are not apart of. Users with following permissions are applicable: 1. `view_ticket_change` permission can view change tickets from organizations they are not apart of. 2. `view_ticket_incident` permission can view incident tickets from organizations they are not apart of. 3. `view_ticket_request` permission can view request tickets from organizations they are not apart of. 4. `view_ticket_problem` permission can view problem tickets from organizations they are not apart of. The access to view the tickets from different organizations is only applicable when browsing the API endpoints for the tickets in question. The Centurion UI is not affected. Project Tasks, although a "ticket type" are also **Not** affected. This issue has been addressed in release version 1.3.1 and users are advised to upgrade. Users unable to upgrade may remove the ticket view permissions from users which would alleviate this vulnerability, if this is deemed not-viable, Upgrading is recommended.

A user with advanced report application access rights can perform actions for which they are not authorized

lunasvg v3.0.1 was discovered to contain a segmentation violation via the component gray_find_cell

Sandbox escape due to incorrect boundary conditions in the Networking component. This vulnerability was fixed in Firefox 152, Firefox ESR 140.12, Firefox ESR 115.37, Thunderbird 152, and Thunderbird 140.12.

Sandbox escape in the DOM: Navigation component. This vulnerability was fixed in Firefox 152, Firefox ESR 140.12, Firefox ESR 115.37, Thunderbird 152, and Thunderbird 140.12.

Improper isolation of users in M-Files Server version before 25.3.14549 allows anonymous user to affect other anonymous users views and possibly cause a denial of service

A flaw was found in Red Hat OpenShift AI (RHOAI) llama-stack-operator. This vulnerability allows unauthorized access to Llama Stack services deployed in other namespaces via direct network requests, because no NetworkPolicy restricts access to the llama-stack service endpoint. As a result, a user in one namespace can access another user’s Llama Stack instance and potentially view or manipulate sensitive data.

Incorrect behavior order in the Gateway API listener-rule generation in Amazon AWS Load Balancer Controller before 3.4.2 might allow an authenticated remote user to intercept, spoof, or deny another namespace's gRPC traffic on a shared Gateway via a crafted HTTPRoute resource. To mitigate this issue, users should upgrade to version 3.4.2.

Sandbox escape in Firefox and Firefox Focus for Android. This vulnerability was fixed in Firefox 151.

No Fuss Computing Centurion ERP is open source enterprise resource planning (ERP) software. Prior to version 1.2.1, an authenticated user can view projects within organizations they are not apart of. Version 1.2.1 fixes the problem.

Artemis Java Test Sandbox versions less than 1.7.6 are vulnerable to a sandbox escape when an attacker crafts a special subclass of InvocationTargetException. An attacker can abuse this issue to execute arbitrary Java when a victim executes the supposedly sandboxed code.

Artemis Java Test Sandbox versions before 1.8.0 are vulnerable to a sandbox escape when an attacker includes class files in a package that Ares trusts. An attacker can abuse this issue to execute arbitrary Java when a victim executes the supposedly sandboxed code.

lunasvg v3.0.0 was discovered to contain a segmentation violation via the component plutovg_path_add_path.

lunasvg v3.0.0 was discovered to contain a segmentation violation via the component composition_source_over.

lunasvg v3.0.0 was discovered to contain a segmentation violation via the component plutovg_blend.

The overly permissive sandbox configuration in DSPy allows attackers to steal sensitive files in cases when users build an AI agent which consumes user input and uses the “PythonInterpreter” class.

NVIDIA Container Toolkit contains an improper isolation vulnerability where a specially crafted container image could lead to untrusted code running in the host’s network namespace. This vulnerability is present only when the NVIDIA Container Toolkit is configured in a nondefault way. A successful exploit of this vulnerability may lead to denial of service and escalation of privileges.

Sandbox escape in the Profile Backup component. This vulnerability was fixed in Firefox 150.0.3, Firefox ESR 115.36, Firefox ESR 140.11, and Thunderbird 140.11.

An Improper Isolation or Compartmentalization vulnerability [CWE-653] in Fortinet FortiSandbox 5.0.0 through 5.0.1, FortiSandbox 4.4.0 through 4.4.7, FortiSandbox 4.2 all versions, FortiSandbox 4.0 all versions may allow an unauthenticated attacker to evade the sandboxing scan via a crafted file.

Sony XAV-AX8500 Bluetooth Improper Isolation Authentication Bypass Vulnerability. This vulnerability allows network-adjacent attackers to bypass authentication on affected Sony XAV-AX8500 devices. Authentication is not required to exploit this vulnerability. The specific flaw exists within the implementation of ACL-U links. The issue results from the lack of L2CAP channel isolation. An attacker can leverage this vulnerability to bypass authentication on the system. Was ZDI-CAN-26284.

SolarWinds Service Desk is affected by a broken access control vulnerability. The issue allows authenticated users to escalate privileges, leading to unauthorized data manipulation.

yasm 1.3.0.55.g101bc was discovered to contain a segmentation violation via the component yasm_expr_create at /libyasm/expr.c.

Improper Isolation or Compartmentalization vulnerability in malach-it boruta (Elixir.Boruta.Openid module) allows attackers to register OpenID Connect clients with administrative privileges through the dynamic client registration entry point. Boruta.Openid.register_client/3 forwards caller-supplied registration parameters to the administrative client creation path without a public/admin field-level allowlist, so an unauthenticated registrant can set security-sensitive attributes including supported grant types, authorized scopes, PKCE enforcement, public refresh and revocation behavior, token lifetimes, and signing settings. The library does not distinguish between metadata a public registrant is allowed to set and administrative controls that should require operator approval. This vulnerability is associated with program files lib/boruta/openid.ex and program routines 'Elixir.Boruta.Openid':register_client/3, 'Elixir.Boruta.Openid':parse_registration_params/2. This issue affects boruta from 2.3.0 before 2.3.7.

Electron is a framework for writing cross-platform desktop applications using JavaScript, HTML and CSS. Prior to versions 38.8.6, 39.8.4, 40.8.4, and 41.0.0, the nodeIntegrationInWorker webPreference was not correctly scoped in all configurations. In certain process-sharing scenarios, workers spawned in frames configured with nodeIntegrationInWorker: false could still receive Node.js integration. Apps are only affected if they enable nodeIntegrationInWorker. Apps that do not use nodeIntegrationInWorker are not affected. This issue has been patched in versions 38.8.6, 39.8.4, 40.8.4, and 41.0.0.

An Improper Isolation or Compartmentalization vulnerability in the Packet Forwarding Engine (pfe) of Juniper Networks Junos OS on QFX5000 Series and EX Series allows an unauthenticated, adjacent attacker to cause a Denial of Service (DoS). If a specific malformed LACP packet is received by a QFX5000 Series, or an EX4400, EX4100 or EX4650 Series device, an LACP flap will occur resulting in traffic loss. This issue affects Junos OS on QFX5000 Series, and on EX4400, EX4100 or EX4650 Series: * 20.4 versions from 20.4R3-S4 before 20.4R3-S8, * 21.2 versions from 21.2R3-S2 before 21.2R3-S6, * 21.4 versions from 21.4R2 before 21.4R3-S4, * 22.1 versions from 22.1R2 before 22.1R3-S3, * 22.2 versions before 22.2R3-S1, * 22.3 versions before 22.3R2-S2, 22.3R3, * 22.4 versions before 22.4R2-S1, 22.4R3.

Kamaji is the Hosted Control Plane Manager for Kubernetes. Prior to 26.7.4-edge, Kamaji derives a TenantControlPlane datastore schema, database user, and etcd key prefix from a lossy namespace-and-name normalization in GetDefaultDatastoreSchema() and GetDefaultDatastoreUsername(), allowing distinct tenants with colliding normalized identifiers to share control-plane state and read, modify, or destroy another tenant's Kubernetes data. This issue is fixed in version 26.7.4-edge.

Vasion Print (formerly PrinterLogic) Virtual Appliance Host and Application (VA and SaaS deployments) run many Docker containers on shared internal networks without firewalling or segmentation between instances. A compromise of any single container allows direct access to internal services (HTTP, Redis, MySQL, etc.) on the overlay network. From a compromised container, an attacker can reach and exploit other services, enabling lateral movement, data theft, and system-wide compromise.

A new API endpoint introduced in pretix 2025 that is supposed to return all check-in events of a specific event in fact returns all check-in events belonging to the respective organizer. This allows an API consumer to access information for all other events under the same organizer, even those they should not have access to. These records contain information on the time and result of every ticket scan as well as the ID of the matched ticket. Example: { "id": 123, "successful": true, "error_reason": null, "error_explanation": null, "position": 321, "datetime": "2020-08-23T09:00:00+02:00", "list": 456, "created": "2020-08-23T09:00:00+02:00", "auto_checked_in": false, "gate": null, "device": 1, "device_id": 1, "type": "entry" } An unauthorized user usually has no way to match these IDs (position) back to individual people.

When using the Grafana Databricks Datasource Plugin, if Oauth passthrough is enabled on the datasource, and multiple users are using the same datasource at the same time on a single Grafana instance, it  could result in  the wrong user identifier being used, and information for which the viewer is not authorized being returned.  This issue affects Grafana Databricks Datasource Plugin: from 1.6.0 before 1.12.0

When using the Grafana Snowflake Datasource Plugin, if Oauth passthrough is enabled on the datasource, and multiple users are using the same datasource at the same time on a single Grafana instance, it  could result in  the wrong user identifier being used, and information for which the viewer is not authorized being returned.  This issue affects Grafana Snowflake Datasource Plugin: from 1.5.0 before 1.14.1.

Traefik is an HTTP reverse proxy and load balancer. Prior to versions 2.11.43, 3.6.14, and 3.7.0-rc.2, there is a potential vulnerability in Traefik's Kubernetes CRD provider cross-namespace isolation enforcement. When providers.kubernetesCRD.allowCrossNamespace=false, Traefik correctly rejects direct cross-namespace middleware references from IngressRoute objects, but fails to apply the same restriction to middleware references nested inside a Chain middleware's spec.chain.middlewares[]. An actor with permission to create or update Traefik CRDs in their own namespace can exploit this to cause Traefik to resolve and apply middleware objects from another namespace, bypassing the documented isolation boundary. This issue has been patched in versions 2.11.43, 3.6.14, and 3.7.0-rc.2.

A user with API access and "manage users" permission in any venueless world is able to trigger deletion of user accounts in other worlds.

A flaw was found in Keycloak. The SingleUseObjectProvider, a global key-value store, lacks proper type and namespace isolation. This vulnerability allows an attacker to delete arbitrary single-use entries, which can enable the replay of consumed action tokens, such as password reset links. This could lead to unauthorized access or account compromise.

A user with vpuser credentials that opens an SSH connection to the device, gets a restricted shell rbash that allows only a small list of allowed commands. This vulnerability enables the user to get a full-featured Linux shell, bypassing the rbash restrictions.

Enabled IP Forwarding feature in B&R Automation Runtime versions before 6.0.2 may allow remote attack-ers to compromise network security by routing IP-based packets through the host, potentially by-passing firewall, router, or NAC filtering.

Due to a product misconfiguration in certain deployment types, it was possible from different pods in the same namespace to communicate with each other. This issue resulted in bypass of access control due to the presence of a vulnerable endpoint in Foundry Container Service that executed user-controlled commands locally.

A vulnerability in the Eclipse Open VSX Registry’s automated publishing system could have allowed unauthorized uploads of extensions. Specifically, the system’s build scripts were executed without proper isolation, potentially exposing a privileged token. This token enabled the publishing of new extension versions under any namespace, including those not controlled by an attacker. However, it did not permit deletion of existing extensions, overwriting of published versions, or access to administrative features of the registry. The issue was reported on May 4, 2025, fully resolved by June 24, and followed by a comprehensive audit. No evidence of compromise was found, though 81 extensions were proactively deactivated as a precaution. The standard publishing process remained unaffected. Recommendations have been issued to mitigate similar risks in the future.

vmir e8117 was discovered to contain a segmentation violation via the function_prepare_parse function at /src/vmir_function.c.

A vulnerability in the Python interpreter of Cisco NX-OS Software could allow an authenticated, low-privileged, local attacker to escape the Python sandbox and gain unauthorized access to the underlying operating system of the device. The vulnerability is due to insufficient validation of user-supplied input. An attacker could exploit this vulnerability by manipulating specific functions within the Python interpreter. A successful exploit could allow an attacker to escape the Python sandbox and execute arbitrary commands on the underlying operating system with the privileges of the authenticated user.  Note: An attacker must be authenticated with Python execution privileges to exploit these vulnerabilities. For more information regarding Python execution privileges, see product-specific documentation, such as the section of the Cisco Nexus 9000 Series NX-OS Programmability Guide.

The Python code being run by 'runPython' or 'runPythonAsync' is not isolated from the rest of the JS code, allowing any Python code to use the Pyodide APIs to modify the JS environment. This may result in an attacker hijacking the MCP server - for malicious purposes including MCP tool shadowing. Note - the "mcp-run-python" project is archived and unlikely to receive a fix.

When an authenticated user is denied access to a gRPC method, their authenticated identity remains bound to the gRPC worker thread and can be inherited by a subsequent unauthenticated request on the same thread. This may allow the subsequent user to gain escalated permissions. Affected versions: Spring gRPC: 1.0.0 - 1.0.2 (fixed in 1.0.3). Older, unsupported versions are also affected.

The Bare Metal Operator (BMO) implements a Kubernetes API for managing bare metal hosts in Metal3. Baremetal Operator enables users to load Secret from arbitrary namespaces upon deployment of the namespace scoped Custom Resource `BMCEventSubscription`. Prior to versions 0.8.1 and 0.9.1, an adversary Kubernetes account with only namespace level roles (e.g. a tenant controlling a namespace) may create a `BMCEventSubscription` in his authorized namespace and then load Secrets from his unauthorized namespaces to his authorized namespace via the Baremetal Operator, causing Secret Leakage. The patch makes BMO refuse to read Secrets from other namespace than where the corresponding BMH resource is. The patch does not change the `BMCEventSubscription` API in BMO, but stricter validation will fail the request at admission time. It will also prevent the controller reading such Secrets, in case the BMCES CR has already been deployed. The issue exists for all versions of BMO, and is patched in BMO releases v0.9.1 and v0.8.1. Prior upgrading to patched BMO version, duplicate any existing Secret pointed to by `BMCEventSubscription`'s `httpHeadersRef` to the same namespace where the corresponding BMH exists. After upgrade, remove the old Secrets. As a workaround, the operator can configure BMO RBAC to be namespace scoped, instead of cluster scoped, to prevent BMO from accessing Secrets from other namespaces, and/or use `WATCH_NAMESPACE` configuration option to limit BMO to single namespace.

Improper Isolation or Compartmentalization in the stream cache mechanism for some Intel(R) Processors may allow an authenticated user to potentially enable escalation of privilege via local access.

An improper isolation or compartmentalization vulnerability [CWE-653] in FortiClientMac version 7.4.2 and below, version 7.2.8 and below, 7.0 all versions and FortiVoiceUCDesktop 3.0 all versions desktop application may allow an authenticated attacker to inject code via Electron environment variables.

An attacker could cooperatively pass data from one secure GPU process to another secure GPU process through shared secure memory allocations in the kernel module. Additionally, an attacker could disrupt the operation of another secure GPU process leading to image corruption / GPU hardware recovery. Sharing secure memory allocations among various GPU secure processes allows an attacker to corrupt shared resource affecting other users.

## Summary The published npm package `praisonai` exports a TypeScript `SandboxExecutor` with a `network-isolated` mode. The CLI lists that mode as: ```text network-isolated No network access (proxy blocked) ``` The implementation does not create a network namespace, firewall rule, socket filter, or proxy-enforced execution boundary. It only injects proxy environment variables into the child process: ```ts http_proxy: 'http://localhost:0', https_proxy: 'http://localhost:0', HTTP_PROXY: 'http://localhost:0', HTTPS_PROXY: 'http://localhost:0', no_proxy: '', NO_PROXY: '' ``` Clients that do not explicitly honor those proxy variables continue to use the host network stack. A local-only PoV shows that, inside `mode: "network-isolated"`, a proxy-aware Node invocation is stopped, while a plain Node HTTP client reaches a loopback HTTP server from the same sandboxed command environment. This is a network-isolation protection failure in an exported npm API and CLI mode. It is not a generic claim that every PraisonAI sandbox backend is affected. ## Technical Details `src/praisonai-ts/src/cli/features/sandbox-executor.ts` declares the mode: ```ts export type SandboxMode = 'disabled' | 'basic' | 'strict' | 'network-isolated'; ``` `SandboxExecutor.spawn()` starts the command through the host shell and passes only the environment returned by `buildEnv()`: ```ts const proc = spawn('sh', ['-c', command], { cwd: this.config.cwd, env, timeout: this.config.timeout, stdio: ['pipe', 'pipe', 'pipe'] }); ``` For `network-isolated`, `buildEnv()` does not apply an OS-level network restriction. It only sets proxy variables: ```ts case 'network-isolated': // No network access (requires additional OS-level setup) return { ...baseEnv, http_proxy: 'http://localhost:0', https_proxy: 'http://localhost:0', HTTP_PROXY: 'http://localhost:0', HTTPS_PROXY: 'http://localhost:0', no_proxy: '', NO_PROXY: '' }; ``` The CLI mode listing presents this as no network access: ```ts 'network-isolated': 'No network access (proxy blocked)' ``` That creates a false boundary. Proxy variables affect only clients that choose to read and honor them. Other clients can still open sockets directly from the child process. ### Why This Is Not Intended Behavior The vulnerable behavior is not "commands can run." The issue is that a mode named `network-isolated` and displayed to users as "No network access" still allows direct socket access. The source comment says `network-isolated` requires additional OS-level setup, which is consistent with the finding: proxy variables alone are not a network isolation mechanism. The exported npm API and CLI mode do not provide such setup or warn callers that this mode is only a best-effort proxy hint. If the intended behavior is merely "set proxy variables for cooperative clients," the mode name and CLI description should be changed so users do not rely on it as a security boundary. ## PoV Run from a local reproduction checkout: ```bash node poc/pov_poc.js 1.7.1 ``` The PoV: 1. Installs `npm:[email protected]` into a temporary project. 2. Starts a harmless HTTP server bound to `127.0.0.1` on a random local port. 3. Creates `new SandboxExecutor({ mode: "network-isolated" })`. 4. Confirms the child environment contains the proxy variables. 5. Runs `node --use-env-proxy client.js` as a proxy-aware control. It fails and does not reach the server. 6. Runs `node client.js` without proxy opt-in. It reaches the server and prints the marker. Observed output summary from `evidence/pov-npm-1.7.1.json`: ```json { "version": "1.7.1", "mode": "network-isolated", "control": { "localServerBoundToLoopback": true, "proxyVariablesSet": true, "proxyAwareClientStopped": true, "requestReachedLoopbackServer": true }, "observed": { "proxyAwareRun": { "success": false, "stdout": "", "exitCode": 2 }, "netRun": { "success": true, "stdout": "BODY=poc\n", "exitCode": 0 }, "loopbackHitCount": 1 }, "vulnerable": true } ``` The PoV is local-only. It does not contact any external host after npm package installation, and it does not use cloud metadata or destructive commands. ## PoC The PoV section above contains the local reproduction command, input, and decisive output. ## Impact Applications often use sandbox network controls to prevent prompt-injected, user-supplied, or model-generated commands from exfiltrating secrets or reaching internal services. A caller who relies on `network-isolated` mode for that boundary can still get network egress by using any client that ignores proxy environment variables or by using direct socket APIs. Depending on the hosting environment, this can allow: - exfiltration from commands that can read local files, process output, or inherited environment variables; - access to localhost or internal network services reachable from the PraisonAI host; - requests to cloud metadata or service endpoints if the host network permits them; and - bypass of application policy that allows command execution only under a no-network assumption. This report does not claim that npm PraisonAI exposes this as an unauthenticated network service by default. It is a library-level isolation bypass in an exported TypeScript API and CLI mode. ### Severity Suggested severity: High. Rationale: - `AV`: common use is a network-facing application or agent service that accepts user or prompt-controlled work and executes it through the sandbox. - `AC`: a single command using a non-proxy-aware network client is sufficient. - `PR`: conservative scoring assumes the attacker can submit prompts or work items to the application using PraisonAI. - `UN`: no additional operator interaction is required once the command is executed. - `S`: impact is scored against the PraisonAI-hosting process and its network privileges. - `C`: network egress can allow data exfiltration from the sandboxed command context. - `I/A`: reachable internal services can receive attacker-controlled requests, with impact depending on deployment. If maintainers score only local CLI use, `AV:L` may be appropriate. If a deployment exposes this through unauthenticated agent endpoints, `PR:N` may be appropriate. ## Suggested Fix Do not represent proxy environment variables as network isolation. Recommended: 1. For a true `network-isolated` mode, run commands inside an execution boundary with OS-enforced network denial, such as a network namespace, firewall rule, sandbox profile, container, VM, or platform-specific socket filter. 2. Add regression tests that start a loopback server and verify that direct socket clients, Node `http.get`, Python sockets, `curl`, and other common clients cannot connect under `network-isolated`. 3. If only proxy hints are intended, rename the mode to something like `proxy-blocked`, document that it is not a security boundary, and keep "network-isolated" unavailable until OS-level enforcement exists. 4. Consider default-deny egress with explicit allowlists for destinations that must remain reachable from sandboxed commands. ## Affected Package/Versions - Repository: `MervinPraison/PraisonAI` - Ecosystem: `npm` - Package: `praisonai` - Component: TypeScript CLI feature `SandboxExecutor` - Latest npm package validated: `1.7.1` - Current `origin/main` validated: `1ad58ca02975ff1398efeda694ea2ab78f20cf3e` - `src/praisonai-ts/package.json` at `origin/main`: `praisonai` `1.7.1` Suggested affected range: ```text npm:praisonai >= 1.2.3, <= 1.7.1 ``` Selected version sweep: - `1.0.0`: package main cannot be required in the selected test environment. - `1.0.19`, `1.1.0`, `1.2.0`, `1.2.1`, `1.2.2`: `SandboxExecutor` is not exported. - `1.2.3`: vulnerable. - `1.2.4`: vulnerable. - `1.3.0`: vulnerable. - `1.3.6`: vulnerable. - `1.4.0`: vulnerable. - `1.5.0`: vulnerable. - `1.5.4`: vulnerable. - `1.6.0`: vulnerable. - `1.7.0`: vulnerable. - `1.7.1`: vulnerable. ## Advisory History Visible PraisonAI advisories and prior submissions were checked. The closest related findings are distinct: - `GHSA-r4f2-3m54-pp7q` covers PyPI `SubprocessSandbox` `shell=True` and blocklist bypass. - `GHSA-6jcq-6546-qrrw` covers Python Sandlock fallback to unrestricted subprocess execution when native Landlock is unavailable. - `GHSA-vmmj-pfw7-fjwp` covers npm `codeMode` host-process `new Function` sandbox escape. - `GHSA-vjv9-7m7j-h833` covers npm `SandboxExecutor` `allowedCommands` bypass through shell chaining. This report is narrower and distinct: npm TypeScript `SandboxExecutor` `network-isolated` mode advertises no network access but enforces only proxy environment variables, so non-proxy-aware clients keep network access without needing shell chaining or a disallowed executable.