Akshatgit

**Name of the Vulnerable Software and Affected Versions** vm2 versions prior to 3.11.1 **Description** When a `NodeVM` is created with the `nesting` variable set to `true`, sandbox code can unconditionally use `require('vm2')` regardless of the outer VM's `require` configuration, including when `require` is set to `false`. This occurs because the `nesting: true` option interacts with the legacy module resolver in a way that silently overrides restrictions. An attacker can use access to `vm2` to construct a new inner `NodeVM` with unrestricted `require` settings to execute arbitrary OS commands on the host. This issue affects applications running untrusted code inside a `NodeVM` with `nesting: true`, such as multi-tenant code execution platforms, notebook/REPL services, plugin systems, and CI sandboxing tools. **Recommendations** Update to version 3.11.1. As a temporary workaround, avoid setting the `nesting` variable to `true` when running untrusted code.

**Name of the Vulnerable Software and Affected Versions** Open WebUI versions prior to 0.8.6 **Description** Open WebUI is a self-hosted artificial intelligence platform designed for offline operation. A flaw exists in the speech-to-text transcription endpoint where an unsanitized filename field allows any authenticated, non-admin user to trigger a `FileNotFoundError`. The error message, including the server's absolute `DATA DIR` path, is then returned in the HTTP 400 response body, leading to information disclosure on default deployments. The issue stems from a lack of path sanitization when extracting the file extension from the filename and constructing the file path. Specifically, the `file.filename.split(".")[-1]` function is used without any sanitization, and the resulting value is concatenated into a filesystem path. This allows an attacker to craft a filename containing directory traversal sequences (e.g., `audio./etc/passwd`) to reveal the server's absolute path. The vulnerability is present in the `backend/open webui/routers/audio.py` file, at line 1197, and is triggered when attempting to open a file with a malicious filename. The MIME-type guard does not prevent this issue. **Recommendations** Versions prior to 0.8.6 should be updated to version 0.8.6 or later to address the issue. As a temporary workaround, consider sanitizing the file extension using `Path(file.filename).name` and suppressing the internal path in error responses. Restrict access to the audio transcription endpoint to minimize the risk of exploitation.

**Name of the Vulnerable Software and Affected Versions** Langflow versions 1.0.0 through 1.8.1 **Description** Langflow versions 1.0.0 through 1.8.1 have an issue where the `/api/v1/files/images/{flow id}/{file name}` API endpoint serves image files without authentication or ownership verification. An unauthenticated request with a known `flow id` and `file name` will successfully retrieve the image, returning an HTTP 200 response. In a multi-tenant environment, an attacker who can discover or guess a `flow id` can download images uploaded by any user without authorization. The `flow id` is a UUID that may be exposed through other API responses. The vulnerable function is `download image` located in `src/backend/base/langflow/api/v1/files.py:138-164`. **Recommendations** Versions prior to 1.9.0 are affected. Update to version 1.9.0 or later to resolve this issue.

**Name of the Vulnerable Software and Affected Versions** Langflow versions 1.2.0 through 1.8.1 **Description** Langflow, a tool for building and deploying AI-powered agents and workflows, contains a security flaw that allows authenticated attackers to write files anywhere on the host system, potentially leading to Remote Code Execution (RCE). The root architectural issue within `LocalStorageService` remains unresolved due to a lack of boundary containment checks in the underlying storage layer. The system relies entirely on the HTTP-layer `ValidatedFileName` dependency, which fails to protect against this issue. Specifically, the `POST /api/v2/files/` endpoint is vulnerable because the multipart upload filename bypasses the path-parameter guard. The vulnerability exists in two layers: the API layer (`src/backend/base/langflow/api/v2/files.py:162`) and the storage layer (`src/backend/base/langflow/services/storage/local.py:114-116`). The filename is extracted directly from the multipart `Content-Disposition` header and used in naive path concatenation without proper validation. A proof-of-concept demonstrates the ability to write a file outside the user's storage directory using directory traversal techniques. Successful exploitation could allow attackers to overwrite critical system files, inject malicious Python components, or compromise the system's security. **Recommendations** Langflow versions prior to 1.9.0 are affected. Update to version 1.9.0 to resolve the vulnerability.