Vulnerability Report for May 2026

The vulnerability exists in the get_data function within litellm/proxy/utils.py. The security advisory and the provided patch clearly indicate a SQL injection vulnerability. The patch replaces a formatted string in the SQL query with a parameterized query, which is the standard mitigation for SQL injection. The vulnerable line WHERE v.token = '{token}' directly uses the user-controlled token variable in the SQL query. The fix changes this to WHERE v.token = $1 and passes the token as a parameter to the database driver, preventing the injection. The vulnerability is triggered when the proxy handles an error, and an unauthenticated attacker can exploit it by sending a specially crafted Authorization header.

The vulnerability exists in the WriteMetadata function within pkg/modules/exiftool/exiftool.go. The root cause is improper input validation, specifically the failure to sanitize metadata values before passing them to the exiftool command-line utility. The vulnerability description explicitly points out that while metadata keys were sanitized, the values were not. An attacker could craft a metadata value with a newline character (\n) to inject arbitrary command-line arguments into the exiftool process. This could lead to arbitrary file operations on the server, such as moving, renaming, or creating symlinks, as demonstrated in the vulnerability report. The provided patch confirms this analysis by introducing a new function, validateMetadataValue, to sanitize these values by checking for control characters. This new validation is applied directly within the WriteMetadata function, confirming it as the location of the vulnerability.

The vulnerability lies in the incorrect handling of authentication denial within the openvpn-auth-oauth2 plugin's experimental mode. The root cause was identified in the handleAuthUserPassVerify function located in lib/openvpn-auth-oauth2/openvpn/handle.go. When a client that does not support web authentication attempts to connect, the plugin's logic correctly determines that the client should be denied. However, instead of returning an error code to the OpenVPN server, it returned OPENVPN_PLUGIN_FUNC_SUCCESS. The OpenVPN server treats this success code as an approval for connection, thus bypassing the authentication mechanism entirely. The patch in commit 36f69a6c67c1054da7cbfa04ced3f0555127c8f2 rectifies this by changing the return value to OPENVPN_PLUGIN_FUNC_ERROR in the case of a client denial, ensuring that the OpenVPN server correctly terminates the connection attempt. This makes handleAuthUserPassVerify the direct location of the vulnerability.

The vulnerability allows a sandbox escape by accessing Function.caller on a sandboxed function. This leaks an internal callback that can be used to execute arbitrary code. The provided patch in commit 826865251232611ec94078bab5a18ec875dad4a5 directly addresses this issue. The analysis of the patch reveals that the file src/executor/ops/prop.ts was modified to prevent access to caller, callee, and arguments properties of a function. The change is within an anonymous function passed to addOps which is responsible for handling property access in the sandbox. The lack of this check in vulnerable versions is the root cause of the vulnerability. The other modified files in the commit are related to versioning and testing and do not contain vulnerable code.

The vulnerability, identified as GHSA-qcp4-v2jj-fjx8, is a sandbox escape in vm2. The root cause is the ability to leak a BaseHandler proxy handler instance from the sandbox environment, primarily through util.inspect({showProxy:true}). Once leaked, the trap methods on this handler (e.g., getPrototypeOf, get, set) could be called directly with a forged target argument. These traps lacked validation to ensure that the target they were operating on was the legitimate, intended target of the proxy.

An attacker could exploit this by providing an arbitrary host object as the target. The PoC demonstrates this by using handler.getPrototypeOf to walk the prototype chain of host objects, eventually gaining access to the host's Function constructor and achieving remote code execution.

The patch addresses this by introducing a validateHandlerTarget function. This function is called at the entry point of every proxy trap within BaseHandler and its subclasses (ProtectedHandler, ReadOnlyHandler, ReadOnlyMockHandler). It maintains a WeakMap to pair each handler with its legitimate target at creation time. Any subsequent trap invocation with a mismatched or unregistered target results in an error, effectively closing the vulnerability. All the patched trap methods were vulnerable to this same fundamental flaw.

The vulnerability exists because the application fails to enforce a minimum length on the JWT signing secret, allowing for weak secrets (less than 32 bytes for HS256) that are vulnerable to offline brute-force attacks. The analysis of the patch and source code identified a two-stage issue.

First, during application startup, the configuration is loaded. The function config.Base64Decoded.UnmarshalText decodes the JWT_SECRET from the environment but does not validate its length. This is orchestrated by config.AppConfig.ParseConfig, which, prior to the patch, lacked the logic to reject secrets shorter than 32 bytes.

Second, the weak secret is then used in core authentication routines. core.CreateAuthenticationToken uses the secret to sign new JWTs, and core.ParseAuthenticationToken uses it to verify incoming tokens. An attacker can capture a token created by the server, crack the weak secret offline, and then forge a new token for any user. The core.ParseAuthenticationToken function would then validate this forged token as legitimate, leading to a full account takeover.

The patch addresses the root cause by adding a validate:"gte=32" struct tag to the JWTSecret field in backend/config/config.go, which is enforced by the ParseConfig function. This ensures the application will not start with a weak secret.

The vulnerability lies in the Dalfox server's handling of scan options provided via the REST API. The postScanHandler function in pkg/server/server.go receives scan options from the user, including FoundAction and FoundActionShell. These options are intended for CLI use but were not disabled for the API. The unsanitized options are passed down to the scanning engine. When a vulnerability is found, the foundAction function in pkg/scanning/foundaction.go is triggered, which executes the command specified in the FoundAction and FoundActionShell options. This allows an unauthenticated attacker to achieve remote code execution on the machine running the Dalfox server. The patch mitigates this by introducing a sanitizeAPIScanOptions function that clears these dangerous options at the API boundary in postScanHandler.

The vulnerability is a classic path traversal issue within the file upload functionality of the Eclipse BaSyx Java Server SDK. An unauthenticated attacker could craft a malicious 'fileName' parameter in a file upload request to write a file to an arbitrary location on the host filesystem. The root cause was twofold: first, at a high level in 'SubmodelFileOperations.setFileValue', the 'fileName' was not validated for traversal sequences. Second, at a lower level in 'InMemoryFileRepository.save', the file path was constructed by unsafely concatenating a directory path and the user-provided filename. The patch addresses both issues by adding explicit validation and safe path handling logic, throwing a 'SecurityException' upon detecting a traversal attempt. During exploitation, a profiler would show calls to these vulnerable functions, originating from the Submodel HTTP API endpoint that handles file uploads.

The vulnerability stems from a hard-coded JWT signing key, WEBUI_SK, which was defined in astrbot/core/__init__.py. This static, publicly known key was used to both sign and verify authentication tokens. The function Auth.generate_jwt used this key to create tokens, while the DashboardServer.auth_middleware function used the same key to validate tokens for protected routes. An attacker could leverage this knowledge to generate their own valid token, bypassing authentication entirely. Once authenticated, they could access sensitive functionality, such as the plugin installation endpoint mentioned in the vulnerability description, to achieve remote code execution. The patch remediates this by removing the hard-coded key and implementing a system where a unique, random JWT secret is generated and stored in the application's configuration upon first run.

The vulnerability exists in the query-string-parser package, version 1.0.0. The root cause is the lack of sanitization of keys parsed from the query string, which leads to a prototype pollution vulnerability. The analysis of the source code in index.js reveals two key functions involved in the vulnerability.

The queryStringToObject function is the main function that takes the raw query string as input. It splits the query string into key-value pairs and then calls the _fillValue function to construct a nested object. However, it does not validate the keys before passing them on.

The _fillValue function is a recursive function that builds the result object. It uses the keys from the query string to create or modify properties on the object. The vulnerability is triggered when a key is __proto__. In this case, the function modifies the Object.prototype instead of the intended object, retval. Any subsequent object creation in the application will inherit the polluted properties, which can lead to denial of service, remote code execution, or other security impacts.

Since there is no patch available for this vulnerability, any usage of query-string-parser@1.0.0 is considered vulnerable.