Dellalibera

**Name of the Vulnerable Software and Affected Versions** Serverless Framework versions 4.29.0 through 4.29.2 **Description** The Serverless Framework is a framework used for building applications with AWS Lambda and other managed cloud services. A command injection issue exists in the Serverless Framework's built-in MCP server package (@serverless/mcp). This affects users of the experimental MCP server feature, representing less than 0.1% of Serverless Framework users. The core Serverless Framework CLI and deployment functionality are not affected. The issue stems from the unsanitized use of input parameters within a call to `child process.exec`, allowing an attacker to inject arbitrary system commands. Successful exploitation can lead to remote code execution with the privileges of the server process. The server constructs and executes shell commands using unvalidated user input, creating a potential for shell metacharacter injection such as `|`, `>`, and `&&`. **Recommendations** Update to Serverless Framework version 4.29.3 or later.

**Name of the Vulnerable Software and Affected Versions** Deno versions prior to 2.5.3 Deno versions prior to 2.2.15 **Description** Deno is a JavaScript, TypeScript, and WebAssembly runtime. The `Deno.FsFile.prototype.stat` and `Deno.FsFile.prototype.statSync` functions do not enforce the `--deny-read=./` permission restriction. This allows retrieval of file statistics from files that a user does not have explicit read access to, even when the script is executed with the `--deny-read=./` flag. While functions like `Deno.stat` and `Deno.statSync` require `allow-read` permission, opening a file with write-only flags and deny-read permission does not prevent the retrieval of file statistics, bypassing the permission model. **Recommendations** Update to Deno version 2.5.3 or later. Update to Deno version 2.2.15 or later.

**Name of the Vulnerable Software and Affected Versions** Deno versions prior to 2.5.3 Deno versions prior to 2.2.15 **Description** Deno is a JavaScript, TypeScript, and WebAssembly runtime. The `Deno.FsFile.prototype.utime` and `Deno.FsFile.prototype.utimeSync` functions are not limited by the `--deny-write=./` permission model check in versions prior to 2.5.3 and 2.2.15. This allows modification of file access (`atime`) and modification (`mtime`) times even when the file is opened with read-only permissions and write operations are disallowed. While APIs like `Deno.utime` and `Deno.utimeSync` require `allow-write` permission, this bypass is possible when a file is opened with read-only flags and `deny-write` permission is set. **Recommendations** Update to Deno version 2.5.3 or later. Update to Deno version 2.2.15 or later.

**Name of the Vulnerable Software and Affected Versions** oak versions 17.1.5 and below **Description** oak is a middleware framework for Deno's native HTTP server, Deno Deploy, Node.js 16.5 and later, Cloudflare Workers and Bun. Specially crafted values in the `x-forwarded-proto` or `x-forwarded-for` headers can significantly slow down an oak server. **Recommendations** Update oak to a version later than 17.1.5.

**Name of the Vulnerable Software and Affected Versions** tmp versions 0.2.3 and below **Description** The `tmp` node.js module versions 0.2.3 and below is susceptible to an arbitrary temporary file/directory write vulnerability due to improper handling of symbolic links when resolving paths. Specifically, the ` resolvePath` function does not adequately address symbolic links, allowing a malicious actor to bypass the intended restrictions on temporary file creation locations. By providing a `dir` parameter that points to a symbolic link resolving to a directory outside the designated temporary directory, an attacker can write temporary files to arbitrary locations on the system. **Recommendations** Update to version 0.2.4 or later to address this vulnerability.

**Name of the Vulnerable Software and Affected Versions** IPX versions 1.3.1 and below IPX versions 2.0.0-0 through 2.1.0 IPX versions 3.0.0 through 3.1.0 **Description** IPX, an image optimizer powered by sharp and svgo, is susceptible to a path prefix bypass when verifying if a path is within allowed directories. This occurs when the allowed directories do not end with a path separator, as the check relies on a raw string prefix comparison. This allows access to files outside of the intended directories. **Recommendations** IPX version 1.3.2 or later IPX version 2.1.1 or later IPX version 3.1.1 or later

**Name of the Vulnerable Software and Affected Versions** `@translated/lara-mcp` versions 0.0.11 and below **Description** A command injection vulnerability exists in the `@translated/lara-mcp` MCP Server due to the unsanitized use of input parameters within a call to `child process.exec`. Successful exploitation can lead to remote code execution under the server process's privileges. The server constructs and executes shell commands using unvalidated user input, introducing the possibility of shell metacharacter injection. An attacker can leverage this vulnerability through indirect prompt injection by crafting malicious input within files or remote data sources processed by the server. This allows for arbitrary command execution on the host machine. **Recommendations** `@translated/lara-mcp` versions prior to 0.0.12: Avoid using `child process.exec` with untrusted input. Instead, use a safer API such as `child process.execFile`, which allows you to pass arguments as a separate array, avoiding shell interpretation entirely. As an example, replace `execAsync(`curl -L "${tmx url}" -o "${tempFilePath}"`);` with `execAsync("curl", "-L", tmx url, "-o", tempFilePath);`.

Name of the Vulnerable Software and Affected Versions: node-code-sandbox-mcp versions prior to 1.3.0 Description: The issue is caused by the unsanitized use of input parameters within a call to `child process.execSync`, enabling an attacker to inject arbitrary system commands. Successful exploitation can lead to remote code execution under the server process's privileges on the host machine, bypassing the sandbox protection of running code inside Docker. Recommendations: For versions prior to 1.3.0, update to version 1.3.0 to resolve the issue. As a temporary workaround, consider restricting the use of the `child process.execSync` function to minimize the risk of exploitation.

**Name of the Vulnerable Software and Affected Versions** mcp-package-docs versions prior to 0.1.28 node-code-sandbox-mcp versions prior to 0.1.28 mcp-server-kubernetes versions prior to 0.1.28 git-mcp-server versions prior to 0.1.28 **Description** A command injection vulnerability exists in multiple MCP (Model Context Protocol) servers. The vulnerability is caused by the unsanitized use of input parameters within calls to `child process.exec` or `child process.execSync`, enabling an attacker to inject arbitrary system commands. Successful exploitation can lead to remote code execution under the server process's privileges, potentially bypassing sandboxing mechanisms in some cases. The servers construct and execute shell commands using unvalidated user input directly within command-line strings, introducing the possibility of shell metacharacter injection (`|`, `>`, `&&`, etc.). Exploitation can occur through direct command execution or indirect prompt injection via file content or log messages. **Recommendations** mcp-package-docs versions prior to 0.1.28: Upgrade to version 0.1.28 or later. node-code-sandbox-mcp versions prior to 0.1.28: Upgrade to version 0.1.28 or later. mcp-server-kubernetes versions prior to 0.1.28: Upgrade to version 0.1.28 or later. git-mcp-server versions prior to 0.1.28: Upgrade to version 0.1.28 or later. To mitigate this vulnerability, avoid using `child process.exec` or `child process.execSync` with untrusted input. Instead, use a safer API such as `child process.execFile`, which allows you to pass arguments as a separate array, avoiding shell interpretation entirely.

**Name of the Vulnerable Software and Affected Versions:** MCP Server Kubernetes versions prior to 2.5.0 **Description:** MCP Server Kubernetes is vulnerable to a command injection issue due to the unsanitized use of input parameters within a call to `child process.execSync`. This allows an attacker to inject arbitrary system commands, potentially leading to remote code execution with the privileges of the server process. The vulnerability exists because the server constructs and executes shell commands using unvalidated user input directly within command-line strings, introducing the possibility of shell metacharacter injection. The vulnerability can be exploited through indirect prompt injection via pod logs or by directly crafting malicious input to the `kubectl scale` tool. **Recommendations:** MCP Server Kubernetes versions prior to 2.5.0: Upgrade to version 2.5.0 or later to resolve this vulnerability. As a temporary workaround, avoid using `child process.execSync` with untrusted input. Consider using `child process.execFileSync` instead, which allows passing arguments as a separate array, avoiding shell interpretation.

Name of the Vulnerable Software and Affected Versions: git-mcp-server versions prior to 2.1.5 Description: A command injection vulnerability exists in the git-mcp-server MCP Server. The vulnerability is caused by the unsanitized use of input parameters within a call to child process.exec, enabling an attacker to inject arbitrary system commands. Successful exploitation can lead to remote code execution under the server process's privileges. The server constructs and executes shell commands using unvalidated user input directly within command-line strings, introducing the possibility of shell metacharacter injection (|, >, &&, etc.). An MCP Client can be instructed to execute additional actions for example via indirect prompt injection when asked to read git logs. Recommendations: To resolve the issue, update to version 2.1.5 or later. As a temporary workaround, consider avoiding the use of child process.exec with untrusted input and instead use a safer API such as child process.execFile, which allows passing arguments as a separate array, avoiding shell interpretation entirely. Restrict access to the vulnerable tools (e.g., git add, git init, git logs) to minimize the risk of exploitation. Avoid using the `path` and `initialBranch` parameters in the affected API endpoints until the issue is resolved.

**Name of the Vulnerable Software and Affected Versions** Saltcorn versions prior to 1.0.0-beta16 **Description** A logged-in user with any role can delete arbitrary files on the filesystem by calling the `/sync/clean sync dir` endpoint. The `dir name` POST parameter is not validated/sanitized and is used to construct the `syncDir` that is deleted by calling `fs.rm`. This issue allows for arbitrary file deletion. **Recommendations** For versions prior to 1.0.0-beta16, upgrade to release version 1.0.0-beta16 or later to address the issue. As a temporary workaround, consider implementing input validation for the `dir name` parameter to ensure it does not contain malicious paths. Restrict access to the `/sync/clean sync dir` endpoint to minimize the risk of exploitation.

**Name of the Vulnerable Software and Affected Versions** Async HTTP Client versions prior to 1.13.2 **Description** The issue is related to insufficient validation of HTTP header field values before sending them to the network, allowing attackers to inject new HTTP header fields or entirely new requests into the data stream. This can cause requests to be understood differently by the remote server than intended, potentially resulting in logical errors and other misbehaviors. Users are vulnerable if they pass untrusted data into HTTP header field values without prior sanitization, such as placing usernames from a database into HTTP header fields. **Recommendations** For versions prior to 1.13.2, update to version 1.13.2 or later to resolve the issue. As a temporary workaround, consider sanitizing all untrusted data before passing it into HTTP header field values to minimize the risk of exploitation. Restrict access to sensitive data and functions that may be affected by the injection of new HTTP header fields or requests. Avoid using untrusted data in HTTP header fields until the issue is resolved.