Vulnerability Report for March 2026

The vulnerability lies in the SandboxJS execution engine, specifically in the handler for function calls made from within the sandboxed environment. The root cause was a failure to sanitize the return values of these function calls. When sandboxed code executed a native JavaScript function (e.g., Object.values(this)), the raw return value was passed back into the sandbox. The vulnerability could be triggered by calling a function that returns an array containing a reference to the host's Function constructor. With access to the Function constructor, an attacker could create and execute arbitrary code, escaping the sandbox and leading to Remote Code Execution (RCE). The patch addresses this by introducing a sanitizeArray function, which is now invoked on the return value of every function call. This new function recursively inspects arrays and replaces any references to sensitive objects like the Function constructor with their sandboxed, safe counterparts, effectively preventing the leak.

The vulnerability exists in the SQL injection validation logic within the internal/utils/inject.go file. The security advisory explicitly identifies the validateNode function as the source of the vulnerability. The function fails to recursively validate all nodes in the PostgreSQL abstract syntax tree (AST), specifically ArrayExpr and RowExpr. This allows an attacker to craft a malicious SQL query with dangerous functions hidden inside these expressions. When the validateNode function encounters these expression types, it does not inspect their child nodes, effectively bypassing the security checks. The exploit PoC demonstrates how to use this flaw to upload and execute a malicious shared library on the database server, resulting in remote code execution. Since no patch is available, the evidence is taken directly from the vulnerability description which includes a snippet of the vulnerable code.

The vulnerability allows for role escalation by permitting unauthenticated users to directly write to internal _Join tables, which manage relationships like role memberships. The analysis of the provided patches shows that the root cause was a missing access control check in the enforceRoleSecurity function located in src/SharedRest.js. This function is a central point for security enforcement for REST API operations. The patch introduces a new block of code that explicitly checks if an operation is targeting a class with a _Join: prefix. If so, it verifies that the request is made with a master or maintenance key, throwing an OPERATION_FORBIDDEN error otherwise. The test cases added in spec/rest.spec.js confirm that this vulnerability affected create, find, get, update, and delete operations on these internal tables. Therefore, the enforceRoleSecurity function is identified as the vulnerable function, as it failed to properly secure a critical internal data structure.

The vulnerability allows an unauthenticated user to gain administrative privileges by creating a new account through the signup form. This is possible when the application is configured to allow signups and the default user permissions have been set to include administrator rights. The root cause is in the signupHandler function in http/auth.go. This handler applies default settings to a new user without sanitizing the permissions to prevent privilege escalation. The settings.UserDefaults.Apply function in settings/defaults.go is also involved as it's the function that copies the permissions, including the admin flag, to the new user. The fix, found in commit a63573b67eb302167b4c4f218361a2d0c138deab, adds a line to the signupHandler to explicitly set the new user's admin permission to false, thus preventing the privilege escalation.

The vulnerability described is a path traversal within the FileStateSessionBackend. The advisory points to the _make_file_path function in mesop/server/state_session.py as the source of the vulnerability. To confirm this and identify the exact function signature, I first identified the patched version (1.2.3) and the last vulnerable version (1.2.2) from the advisory. By comparing the git tags for these versions in the mesop-dev/mesop repository, I located the commit that introduced the fix: c6b382f363b73ac32c402a2db3aadc7784f66a5b. The diff in this commit clearly shows changes to the _make_file_path function in mesop/server/state_session.py. The original code return self.base_dir / (self.prefix + token) was removed. This line is the vulnerability, as it combines a base path with an unsanitized user-provided token. The patch adds validation to the token using a regular expression and resolves the path to ensure it remains within the base directory, thus mitigating the path traversal risk. Therefore, the FileStateSessionBackend._make_file_path function is the precise location of the vulnerability.

The core of the vulnerability lies in the zeptoclaw::security::shell::ShellSecurityConfig::validate_command function, which inadequately validated shell commands. The analysis of the patch 68916c3e4f3af107f11940b27854fc7ef517058b reveals several critical flaws that were addressed.

1. Allowlist Bypass via Command Chaining: The original code only validated the first token (the command executable) against the allowlist. This allowed an attacker to append malicious commands using shell metacharacters like ;, |, or $(). For instance, a command like git status; rm -rf / would pass if git was allowlisted, leading to arbitrary command execution. The patch mitigates this by explicitly detecting and blocking these command-chaining metacharacters.

2. Blocklist Bypass via Argument Injection: The regular expressions designed to block dangerous commands (e.g., inline Python execution with -c) were too specific. An attacker could bypass them by inserting other command-line flags, such as python3 -P -c '...'. The patch strengthens these regexes to correctly identify such patterns regardless of intervening flags.

3. Blocklist Bypass via Glob Wildcards: The blocklist for sensitive file paths (like /etc/passwd) used a simple substring match. This was easily circumvented by using shell globbing wildcards (e.g., cat /etc/pass[w]d). The patch introduces logic to interpret these wildcards, effectively preventing the bypass.

4. Logic Flaw in Strict Mode: A significant logic error caused the validation to be skipped entirely if the allowlist was empty in Strict mode, thereby allowing any command. The fix ensures that an empty allowlist in Strict mode correctly blocks all commands as intended.

The ShellSecurityConfig::validate_command function is the central point where these flawed controls were implemented. A secondary related issue was fixed in the device_shell function in src/tools/android/actions.rs, which had a naive blocklist for rm -rf that could be bypassed by altering the flags. Both functions were processing user-controlled commands in an unsafe manner.

The vulnerability is a classic sandbox escape within the Node.js vm module, which is explicitly not a security boundary. The advisory points to Common/Server/Utils/VM/VMRunner.ts as the location of the vulnerable code. Analysis of the commits between the last vulnerable version (10.0.17) and the first patched version (10.0.18) revealed commit 2a5a0f972a3ee295194db6e0f26df8f49a923546. This commit's message, "fix: Implement sandbox proxy creation and unwrapping for secure code execution," directly addresses the described vulnerability. The changes are concentrated in the VMRunner.runCodeInNodeVM function. Before the patch, this function passed host-realm objects directly into the VM's context, allowing for prototype chain attacks to break out of the sandbox. The patch mitigates this by creating a null-prototype object for the sandbox and wrapping all exposed host objects in a Proxy that blocks access to sensitive properties like constructor and __proto__, effectively preventing the sandbox escape.

The vulnerability, identified as GHSA-vvpj-8cmc-gx39, represents a complete bypass of the picklescan library's security model. The root cause is the failure to include the Python standard library function pkgutil.resolve_name in its internal blocklist of dangerous functions (_unsafe_globals).

My analysis of the patch commit bf26452ae2e3204429762c2bb1aa9eacd40436bb, which upgrades picklescan to version 1.0.4, confirms this. The patch explicitly adds "pkgutil": {"resolve_name"} to the _unsafe_globals dictionary within src/picklescan/scanner.py.

The vulnerability is not a flaw within a specific function's implementation (like a buffer overflow), but rather a critical omission in the security data used by the scanner functions. The primary functions responsible for scanning, scan_pickle_bytes and scan_pickle_file, would consume this incomplete blocklist. As a result, when scanning a pickle crafted by an attacker, these functions would not recognize the use of pkgutil.resolve_name as a threat. The attacker's pickle could then use resolve_name('os:system') to dynamically load the os.system function and execute arbitrary commands, while picklescan would report the file as safe. Therefore, the scanning functions are identified as the vulnerable components because they provide a false sense of security.

The vulnerability stems from the application's backend improperly trusting a client-controlled HTTP header, is-multi-tenant-query. When this header was set to true, a flag was enabled that caused critical authorization and tenant isolation checks to be skipped. The core of the issue was in the TenantPermission.addTenantScopeToQuery and ModelPermission.addTenantScopeToQuery functions, where the logic to enforce tenant-scoping on database queries was bypassed. This allowed any authenticated user, regardless of their privilege level, to read and modify data belonging to any other tenant on the platform.

The severity of this authorization bypass was significantly amplified by a secondary weakness: password reset tokens were stored in plaintext. An attacker could exploit the tenant isolation bypass to query the Project model of a victim. By including the createdByUser relation in the query, they could access sensitive fields on the User model, including the plaintext resetPasswordToken. The exploitation chain involved triggering a password reset for a victim and then immediately using the tenant bypass to read the newly generated token from the database, allowing for a complete account takeover. The patches address both issues: first, by correcting the faulty logic in the permission-checking functions to properly handle the is-multi-tenant-query case, and second, by implementing hashing for all password reset tokens to prevent them from being useful even if leaked.

The vulnerability allows an authenticated user to read arbitrary files on the server. This is a two-stage attack. First, the attacker uses the /api/lute/html2BlockDOM endpoint to trigger the server to copy a sensitive file from a file:// URI into the web-accessible assets directory. The vulnerability exists because the html2BlockDOM function in kernel/api/lute.go did not validate the file path to prevent access to sensitive directories. The patch addresses this by adding a check using util.IsSensitivePath(). The second stage of the attack involves accessing the copied file via the /assets/ endpoint. The primary vulnerability lies in the html2BlockDOM function, which is the entry point for the malicious action.