Vulnerability Report for April 2026

The function get_data within the ProxyUtils class constructs a raw SQL query to validate an API token. The original code used an f-string to embed the hashed_token directly into the query string, which is a classic SQL injection vulnerability. An attacker could craft a malicious token that, when inserted into the query, could alter the query's logic to bypass authentication or exfiltrate data from the database.

This function was modified to accept and pass query parameters (*args) to the underlying database driver. While not the source of the vulnerability itself, it was a necessary change to allow the get_data function to use parameterized queries, which is the fix for the SQL injection. This function is part of the vulnerable execution path.

This is the GraphQL resolver for the restoreTenant mutation. It was vulnerable because it was missing from the adminMutationMWConfig map in graphql/admin/admin.go, which meant it had no authentication or authorization middleware. This allowed any unauthenticated user to call it and access powerful features like restoring backups from arbitrary locations.

This function is called by the unauthenticated RestoreTenant resolver. It takes attacker-controlled parameters, including the backup location (S3, file URI), credentials, and other sensitive information. This allows for database overwrites, Server-Side Request Forgery (SSRF) by pointing to internal endpoints, and local file system access.

When the restoreTenant mutation is called with a file:// URI, this function is used to list the contents of directories on the server's local filesystem. This allows an unauthenticated attacker to probe the filesystem structure and identify interesting files.

When the restoreTenant mutation is called with a file:// URI pointing to a file, this function is used to read the contents of that file. This allows an unauthenticated attacker to read arbitrary files on the server, limited only by file system permissions.

This function is called as part of the restore process and reads a file from the path provided in the encryptionKeyFile parameter of the restoreTenant mutation. An unauthenticated attacker can abuse this to read arbitrary files from the server's filesystem.

The function handleAuthUserPassVerify incorrectly returned OPENVPN_PLUGIN_FUNC_SUCCESS when client authentication was denied for clients not supporting web authentication. The OpenVPN server interprets this status as a successful authentication, granting the client network access despite the intended denial. The fix changes the return value to OPENVPN_PLUGIN_FUNC_ERROR, ensuring the OpenVPN server correctly rejects the unauthenticated client.

This function handles GET requests to /agents/:id/keys. It is vulnerable because it only checks if the user has a "board" type session (assertBoard(req)) but does not verify if the user has access to the company associated with the agent ID provided in the URL. This allows an attacker from one company to list the API keys of an agent in another company.

This function handles POST requests to /agents/:id/keys. It is vulnerable because it only checks if the user has a "board" type session (assertBoard(req)) but does not verify if the user has access to the company associated with the agent ID provided in the URL. This allows an attacker from one company to create a new API key for an agent in another company and receive the key in cleartext, leading to a full cross-tenant compromise.

This function handles DELETE requests to /agents/:id/keys/:keyId. It is vulnerable because it only checks if the user has a "board" type session (assertBoard(req)) but does not verify if the user has access to the company associated with the key ID. This allows an attacker from one company to revoke an API key of an agent in another company, causing a denial of service.

This service layer function is responsible for creating an API key. It is vulnerable because it does not perform any authorization checks and blindly trusts the provided agent ID. It copies the companyId from the victim agent, which is then used to create a new API key associated with the victim's company.

This service layer function is responsible for listing API keys for a given agent ID. It is vulnerable because it does not perform any authorization checks and directly queries the database based on the provided agent ID, allowing an attacker to list keys of any agent.

This service layer function is responsible for revoking an API key. It is vulnerable because it does not perform any authorization checks and directly updates the database based on the provided key ID, allowing an attacker to revoke any key.

This function, which handles GET requests to /api/agents/:id/keys, only checked if a user was authenticated (assertBoard) but failed to verify if the user belonged to the company that owned the agent. This allowed any authenticated user on the platform to list the API keys of any agent in any company, leading to a cross-tenant information disclosure vulnerability.

This function, which handles POST requests to /api/agents/:id/keys, was the most critical part of the vulnerability. It allowed any authenticated user to mint a new API token for any agent in any company. The function only performed an authentication check (assertBoard) without an authorization check (assertCompanyAccess), enabling a complete bypass of the tenancy model.

This function, which handles DELETE requests to /api/agents/:id/keys/:keyId, only checked for user authentication (assertBoard) and not for company membership. This allowed any authenticated user to revoke/delete the API keys of any agent in any company, potentially causing a denial of service.

This function, handling agent pausing, was vulnerable due to a missing assertCompanyAccess check. It allowed any authenticated user to pause any agent in any company, leading to a cross-tenant denial of service.

This function, handling agent resuming, was vulnerable due to a missing assertCompanyAccess check. It allowed any authenticated user to resume any agent in any company, enabling unauthorized cross-tenant actions.

This function, handling agent termination, was vulnerable due to a missing assertCompanyAccess check. It allowed any authenticated user to terminate any agent in any company, leading to a cross-tenant denial of service.

This function, handling agent deletion, was vulnerable due to a missing assertCompanyAccess check. It allowed any authenticated user to delete any agent in any company, leading to a severe cross-tenant availability and integrity impact.

While the primary vulnerability was the missing authorization check in the route handler, this service function is a key part of the exploit chain. It is called by the vulnerable POST /api/agents/:id/keys endpoint and is responsible for creating the API token. Crucially, it associates the new token with the victim agent's companyId, which is what allows the attacker's token to gain access to the victim's tenant. This function would appear in a runtime profile during exploitation.

This route handler is the core of the remote code execution vulnerability. It was missing an authorization check to ensure that only instance administrators could create new companies via the import functionality. An attacker, after creating a basic account, could call this endpoint with a specially crafted payload to create a new company and define an agent with a 'process' adapter, which executes arbitrary shell commands on the server.

Similar to the '/import' route, this route handler for previewing an import was missing an instance administrator check for the 'new_company' mode. This allowed any authenticated user to probe and prepare for the exploitation of the main import vulnerability.

This function was vulnerable to a cross-company authorization bypass. It only checked if the caller was a board user (assertBoard) but did not verify if the user had access to the company associated with the approval ID. This allowed an attacker to approve requests in any company on the instance.

This function was vulnerable to a cross-company authorization bypass. It only checked if the caller was a board user (assertBoard) but did not verify if the user had access to the company associated with the approval ID. This allowed an attacker to reject requests in any company on the instance.

This route handler was missing an authorization check. It allowed any authenticated board user to list issues related to a heartbeat run from any company, potentially exposing sensitive information.

This function was vulnerable to a cross-company authorization bypass. It allowed any authenticated board user to cancel an agent run in any company, leading to a potential denial of service.

The function was vulnerable to SQL injection because it directly interpolated the maxLoadedId parameter from the request body into an SQL query string without sanitization or parameterization. An attacker could provide a malicious string for maxLoadedId to execute arbitrary SQL commands. The patch adds validation to ensure maxLoadedId is an integer and uses parameterized queries to prevent injection.

The function was vulnerable to SQL injection because it directly interpolated the syncFrom and syncUntil date values from the request body into an SQL query string. Although these were expected to be dates, they were not properly validated, allowing an attacker to inject SQL expressions. The patch adds validation and uses parameterized queries.

This route handler for /sync/load_changes is the entry point for the vulnerability. It takes the syncInfos object from the request body and passes it to the getSyncRows function. The maxLoadedId within syncInfos was not sanitized, leading to the SQL injection vulnerability in getSyncRows.

The function used string concatenation to build a DELETE query with a list of IDs, making it vulnerable to SQL injection if the ids array contained malicious values. The patch fixes this by using a parameterized query.

The function used string interpolation for id and oldLastModified in an UPDATE query. This could lead to SQL injection if these parameters were not properly sanitized before being passed to the function. The patch fixes this by using parameterized queries.

The function used string interpolation for id and a timestamp value in an INSERT query for the sync info table. This could lead to SQL injection. The patch fixes this by using parameterized queries.

The run function in src/main.ts is the main entry point for the run-gemini-cli GitHub Action. This function is responsible for orchestrating the execution of the gemini-cli tool. The vulnerability lies in the fact that this function would execute a vulnerable version of gemini-cli in an environment that the CLI would implicitly trust, leading to potential remote code execution. The patch for the action involves updating the documentation to guide users on how to configure the new trust settings, as evidenced by the commit that adds trust-guidance.md. Therefore, the run function is the function that would appear in a runtime profile during the exploitation of this vulnerability within the action.

The @login_optionally_required decorator was incorrectly placed before the @backups_blueprint.route decorator. In Flask, the @route decorator must be the outermost to correctly register the wrapped function with all its decorators. Due to this incorrect ordering, the request_backup function was registered without the authentication check, allowing unauthenticated users to trigger a backup creation.

The incorrect ordering of the @login_optionally_required and @backups_blueprint.route decorators caused the authentication check for the download_backup function to be bypassed. This allowed an unauthenticated attacker to download sensitive backup files.

The create function, responsible for rendering the backup creation page, was left unprotected due to the decorator ordering issue. This exposed two routes ('/' and '/create' under the backups blueprint) to unauthenticated access.

Authentication was bypassed for the remove_backups function due to the incorrect decorator order. This allowed an unauthenticated attacker to delete all existing backups.

The restore function, which displays the backup restoration page, was accessible to unauthenticated users because the @login_optionally_required decorator was not correctly applied.

The backups_restore_start function, which initiates the backup restore process, was vulnerable to unauthenticated access due to the incorrect decorator ordering, allowing an attacker to upload and restore a potentially malicious backup.

The browsersteps_start_session function was unprotected due to the decorator ordering flaw, enabling an unauthenticated user to start a new browser steps session, potentially leading to resource exhaustion or other issues.

Authentication was bypassed for the browser_steps_fetch_screenshot_image function, allowing an unauthenticated user to fetch screenshot images related to browser automation steps, potentially leaking sensitive information.

The browsersteps_ui_update function was left unprotected due to the decorator ordering issue, allowing unauthenticated POST requests. This could lead to unauthorized modifications of browser step configurations.

The runLinux function is vulnerable to command injection. It constructs a shell command using the name parameter, which is derived from a remote source (GitHub releases), without proper sanitization. An attacker controlling the release filename could inject arbitrary commands that would be executed by the exec function.

The runWin function is vulnerable to command injection. It constructs a shell command using the name parameter, which is derived from a remote source (GitHub releases), without proper sanitization. An attacker controlling the release filename could inject arbitrary commands that would be executed by the exec function.

The runMac function is vulnerable to command injection. It constructs a shell command using the name parameter, which is derived from a remote source (GitHub releases), without proper sanitization. An attacker controlling the release filename could inject arbitrary commands that would be executed by the exec function.