VAITP

PraisonAI is a multi-agent teams system. Versions 4.5.138 and below are vulnerable to arbitrary code execution through automatic, unsanitized import of a tools.py file from the current working directory. Components including call.py (import_tools_from_file()), tool_resolver.py (_load_local_tools()), and CLI tool-loading paths blindly import ./tools.py at startup without any validation, sandboxing, or user confirmation. An attacker who can place a malicious tools.py in the directory where PraisonAI is launched (such as through a shared project, cloned repository, or writable workspace) achieves immediate arbitrary Python code execution in the host environment. This compromises the full PraisonAI process, the host system, and any connected data or credentials. This issue has been fixed in version 4.5.139.

MaxKB is an open-source AI assistant for enterprise. In versions 2.7.1 and below, an authenticated user can bypass sandbox result validation and spoof tool execution results by exploiting Python frame introspection to read the wrapper's UUID from its bytecode constants, then writing a forged result directly to file descriptor 1 (bypassing stdout redirection). By calling sys.exit(0), the attacker terminates the wrapper before it prints the legitimate output, causing the MaxKB service to parse and trust the spoofed response as the genuine tool result. This issue has been fixed in version 2.8.0.

MaxKB is an open-source AI assistant for enterprise. Versions 2.7.1 and below contain a sandbox escape vulnerability in the ToolExecutor component. By leveraging Python's ctypes library to execute raw system calls, an authenticated attacker with workspace privileges can bypass the LD_PRELOAD-based sandbox.so module to achieve arbitrary code execution via direct kernel system calls, enabling full network exfiltration and container compromise. The library intercepts critical standard system functions such as execve, system, connect, and open. It also intercepts mprotect to prevent PROT_EXEC (executable memory) allocations within the sandboxed Python processes, but pkey_mprotect is not blocked. This issue has been fixed in version 2.8.0.

MaxKB is an open-source AI assistant for enterprise. In versions 2.7.1 and below, an incomplete sandbox protection mechanism allows an authenticated user with tool execution privileges to escape the LD_PRELOAD-based sandbox. By env command the attacker can clear the environment variables and drop the sandbox.so hook, leading to unrestricted Remote Code Execution (RCE) and network access. MaxKB restricts untrusted Python code execution via the Tool Debug API by injecting sandbox.so through the LD_PRELOAD environment variable. This intercepts sensitive C library functions (like execve, socket, open) to restrict network and file access. However, a patch allowed the /usr/bin/env utility to be executed by the sandboxed user. When an attacker is permitted to create subprocesses, they can execute the env -i python command. The -i flag instructs env to completely clear all environment variables before running the target program. This effectively drops the LD_PRELOAD environment variable. The newly spawned Python process will therefore execute natively without any sandbox hooks, bypassing all network and file system restrictions. This issue has been fixed in version 2.8.0.

A Code Injection and Missing Authentication vulnerability in Google Agent Development Kit (ADK) versions 1.7.0 (and 2.0.0a1) through 1.28.1 (and 2.0.0a2) on Python (OSS), Cloud Run, and GKE allows an unauthenticated remote attacker to execute arbitrary code on the server hosting the ADK instance. This vulnerability was patched in versions 1.28.1 and 2.0.0a2. Customers need to redeploy the upgraded ADK to their production environments. In addition, if they are running ADK Web locally, they also need to upgrade their local instance.

PraisonAI is a multi-agent teams system. Prior to 4.5.128, PraisonAI’s MCP (Model Context Protocol) integration allows spawning background servers via stdio using user-supplied command strings (e.g., MCP("npx -y @smithery/cli ...")). These commands are executed through Python’s subprocess module. By default, the implementation forwards the entire parent process environment to the spawned subprocess. As a result, any MCP command executed in this manner inherits all environment variables from the host process, including sensitive data such as API keys, authentication tokens, and database credentials. This behavior introduces a security risk when untrusted or third-party commands are used. In common scenarios where MCP tools are invoked via package runners such as npx -y, arbitrary code from external or potentially compromised packages may execute with access to these inherited environment variables. This creates a risk of unintended credential exposure and enables potential supply chain attacks through silent exfiltration of secrets. This vulnerability is fixed in 4.5.128.

PraisonAI is a multi-agent teams system. Prior to 4.5.128, PraisonAI's AST-based Python sandbox can be bypassed using type.__getattribute__ trampoline, allowing arbitrary code execution when running untrusted agent code. The _execute_code_direct function in praisonaiagents/tools/python_tools.py uses AST filtering to block dangerous Python attributes like __subclasses__, __globals__, and __bases__. However, the filter only checks ast.Attribute nodes, allowing a bypass. The sandbox relies on AST-based filtering of attribute access but fails to account for dynamic attribute resolution via built-in methods such as type.getattribute, resulting in incomplete enforcement of security restrictions. The string '__subclasses__' is an ast.Constant, not an ast.Attribute, so it is never checked against the blocked list. This vulnerability is fixed in 4.5.128.

PraisonAIAgents is a multi-agent teams system. Prior to 1.5.128, he list_files() tool in FileTools validates the directory parameter against workspace boundaries via _validate_path(), but passes the pattern parameter directly to Path.glob() without any validation. Since Python's Path.glob() supports .. path segments, an attacker can use relative path traversal in the glob pattern to enumerate arbitrary files outside the workspace, obtaining file metadata (existence, name, size, timestamps) for any path on the filesystem. This vulnerability is fixed in 1.5.128.

An Execution with Unnecessary Privileges vulnerability in the User Interface (UI) of Juniper Networks Junos OS and Junos OS Evolved allows a local, low-privileged attacker to gain root privileges, thus compromising the system. When a configuration that allows unsigned Python op scripts is present on the device, a non-root user is able to execute malicious op scripts as a root-equivalent user, leading to privilege escalation.  This issue affects Junos OS:  * All versions before 22.4R3-S7,  * from 23.2 before 23.2R2-S4,  * from 23.4 before 23.4R2-S6, * from 24.2 before 24.2R1-S2, 24.2R2,  * from 24.4 before 24.4R1-S2, 24.4R2;  Junos OS Evolved:  * All versions before 22.4R3-S7-EVO,  * from 23.2 before 23.2R2-S4-EVO,  * from 23.4 before 23.4R2-S6-EVO, * from 24.2 before 24.2R2-EVO,  * from 24.4 before 24.4R1-S1-EVO, 24.4R2-EVO.

LangChain is a framework for building agents and LLM-powered applications. Prior to 0.3.84 and 1.2.28, LangChain's f-string prompt-template validation was incomplete in two respects. First, some prompt template classes accepted f-string templates and formatted them without enforcing the same attribute-access validation as PromptTemplate. In particular, DictPromptTemplate and ImagePromptTemplate could accept templates containing attribute access or indexing expressions and subsequently evaluate those expressions during formatting. Second, f-string validation based on parsed top-level field names did not reject nested replacement fields inside format specifiers. In this pattern, the nested replacement field appears in the format specifier rather than in the top-level field name. As a result, earlier validation based on parsed field names did not reject the template even though Python formatting would still attempt to resolve the nested expression at runtime. This vulnerability is fixed in 0.3.84 and 1.2.28.