Natan Nehorai

An issue exists where a tenant with a workspace token can attach a volume when deploying a function, endpoint, or task queue. The gateway constructs the host path by joining the shared volumes root, the workspace name, and the volume identifier from the stub configuration without verifying if the workspace owns the specified volume. By using parent-directory segments in the volume identifier, a path traversal occurs, collapsing the joined path to the worker's filesystem root. This allows the worker to bind-mount the path into the sandbox with read-write access, unless explicitly marked read-only, enabling a tenant to read and write the worker's files and access volumes belonging to other tenants stored on the same machine.

The Beta9 worker serves the sandbox file API from outside the container. The `getHostPathFromContainerPath` function converts a tenant's container path into a worker path. If the unresolved path starts with a mount destination, such as the default upload mount at `/tmp/.beta9`, the remainder is joined using `filepath.Join`, which cleans parent-directory segments after the prefix check. A sufficient sequence of these segments allows access to any absolute path on the worker. Additionally, paths that do not match a mount are joined to the container root and opened in the worker's filesystem, meaning absolute symbolic links are followed against the worker root. This issue affects the upload, download, stat, list, find-in-files, replace-in-files, and delete-file operations. A tenant with a workspace token and a running sandbox can read, write, list, and delete files on the hosting worker as root, including files belonging to other tenants. A proof of concept demonstrated the ability to download the worker pod's Kubernetes service account token, which in shipped remote-node manifests is bound to cluster-admin.

A sandbox escape exists in the image build process where shell commands in a tenant image definition are executed using Buildah with `BUILDAH ISOLATION=chroot`. Because the process retains the worker pod's PID, network, IPC, and user namespaces while running as uid 0 with `CAP DAC OVERRIDE` (a capability that allows bypassing file read, write, and execute permission checks), an attacker can access the worker container's filesystem via `/proc/1/root`. This allows a tenant with a workspace token to take over the build worker and read its Kubernetes service account token, as well as access the `runc`, `buildah`, and `runsc` binaries and host directories mounted into the pod.

The software implements Server-Side Request Forgery (SSRF) hardening using a static hostname and IP-literal denylist within the `assertSafeFetchTarget()` function. However, it fails to resolve DNS or re-validate hosts following HTTP redirects. An attacker capable of influencing a FetchURL call, such as through prompt injection, can provide a crafted public hostname that resolves to a loopback or internal address, or a public URL that redirects to such a target. This allows access to internal network services that the denylist is intended to block. Because FetchURL is part of the default auto-approve tool set, these calls do not require interactive user confirmation in manual mode.

The Pydantic-AI MCP Run Python tool is configured with an overly permissive Deno sandbox configuration. This allows Python code executed within the sandbox to access the localhost interface of the host system, potentially enabling Server-Side Request Forgery (SSRF) attacks. The project is archived and unlikely to receive a fix. The tool allows the underlying Python code to access the host's localhost interface. This access can be exploited to perform SSRF attacks.

n8n is affected by a critical Remote Code Execution (RCE) issue within its workflow Expression evaluation system. An authenticated attacker can leverage this to execute arbitrary code with the privileges of the n8n process. This is possible because expressions provided by authenticated users during workflow configuration are evaluated in an execution context that lacks sufficient isolation from the underlying runtime. Successful exploitation could lead to a full compromise of the affected instance, potentially granting unauthorized access to sensitive data, modification of workflows, and execution of system-level operations. Approximately 981,000 services are estimated to be exposed yearly. The issue involves bypassing the Expression sandbox, allowing for the execution of arbitrary JavaScript code.

An issue exists in n8n that allows an attacker to bypass the python-task-executor sandbox restrictions. This bypass is achieved through the use of string formatting and exception handling, enabling the execution of arbitrary unrestricted Python code in the underlying operating system. The vulnerability can be exploited by an authenticated user with basic permissions via the Code block. In instances operating under "Internal" execution mode, a full n8n instance takeover is possible. If the instance operates under "External" execution mode, arbitrary code execution occurs within a Sidecar container, reducing the impact. The vulnerability is related to a Python 3.10 error-handling feature that bypasses static analysis. The vulnerability is exploitable through the use of f-strings and the ` traceback ` object.

The `cleanIptables` mutation is susceptible to OS command injection. This allows unauthenticated in-cluster attackers to potentially execute remote code across the cluster. Attackers may gain root access on Kubernetes nodes through exploitation of this issue.

The Chaos Controller Manager in Chaos Mesh exposes a GraphQL debugging server without authentication to the entire Kubernetes cluster. This server provides an API that allows attackers to kill arbitrary processes in any Kubernetes pod, potentially leading to a cluster-wide denial of service. The vulnerability stems from a missing authentication check for a critical function within the Chaos Controller Manager.

A command injection flaw exists in Chaos Mesh’s `cleanTcs` mutation. This flaw allows unauthenticated in-cluster attackers to perform remote code execution across the cluster. The vulnerability is related to OS command injection.

The Weave server API allows remote users to fetch files from a specific directory, but due to a lack of input validation, it is possible to traverse and leak arbitrary files remotely. In various common scenarios, this allows a low-privileged user to assume the role of the server admin. The issue is being actively exploited.

The issue concerns RAIL documents, an XML-based format used by Guardrails AI for enforcing formatting checks on LLM outputs. Users who consume RAIL documents from external sources are at risk of XML External Entity (XXE) attacks, which could lead to the leakage of internal file data through the SYSTEM entity.

The issue is related to command injection when ingesting a remote Kaggle dataset due to a lack of input sanitization in the `ingest kaggle()` API. This allows for potential command injection attacks. The `ingest kaggle()` API endpoint is vulnerable due to insufficient input validation.

The Vanna library is affected by a remote code execution issue due to prompt injection. This allows an attacker to alter the prompt function used for visualized results and run arbitrary Python code. The issue arises when external input is allowed to the library's `ask` method with `visualize` set to True, which is the default behavior. This vulnerability has been reportedly exploited in the wild.

The issue allows a user to register to a vector-admin server while “domain restriction” is active, even when not owning an authorized email address. This is an authentication bypass in vector-admin.

Design document functions that receive a user HTTP request object may expose authorization or session cookie headers of the user who accesses the document. These design document functions include `list`, `show`, `rewrite`, and `update`. An attacker can leak the session component using an HTML-like output, insert the session as an external resource, or store the credential in a local document with an `update` function. For the attack to succeed, the attacker must be able to insert the design documents into the database and then manipulate a user to access a function from that design document.