Velociraptor's WatchEvent gRPC API can specify the OrgId of the org from which events should be streamed. The server checks the API permissions against the caller's Org instead of the requested Org. This allows a user with API access in one org to read events from another org for which they have no access.

Velociraptor's SetClientMetadata used the wrong permission check to enforce setting metadata on the server. This allows a user with LABELCLIENTS permission to update the server metadata.

Server metadata is often used to store site wide configuration data that should only be updated by the server admin.

Velociraptor allows collection of VQL queries packaged into Artifacts from endpoints. These artifacts can be used to do anything and usually run with elevated permissions. To limit access to some dangerous artifact, Velociraptor allows for those to require high permissions like EXECVE to launch.

The Windows.Sysinternals.SysmonLogForward is a monitoring artifact used to forward sysmon events to the server. The artifact allows the user to specify an arbitrary binary path as a parameter, and did not enforce an additional required permission, allowing users with COLLECTCLIENT permissions (normally given by the "Investigator" role) to collect it from endpoints and run a different binary program than the installed sysmon binary. To successfully exploit this vulnerability the user must already have access to collect artifacts from the endpoint (i.e. have the COLLECTCLIENT given typically by the "Investigator" role).

Velociraptor stores the compiled VQL in the hunt object internally to avoid having to recompile the artifacts for each endpoint in the hunt. Although the field "compiledcollectorargs" is an internal field, Velociraptor allowed the field to be set from a user API call. This allows another user who can schedule a hunt (minimal role of "investigator" ) to set the compiled VQL statements for the hunt bypassing any ACL checks that would normally be applied.

This flaw can then be escalated to allow the "investigator" user to run arbitrary VQL statements as an administrator user on the Velociraptor server.

Velociraptor contains a deadlock condition that may be triggered by authenticated users. The issue stems from a lock management bug in the user management module.

An authorization bypass (CWE-639) in the GetUserRoles gRPC API endpoint in Velocidex Velociraptor below version 0.76.5 allows any authenticated low-privilege user to retrieve the complete ACL policy (roles and permissions) for any user across all organizations by supplying targeted Name and Org parameters via a network request.

An off-by-one error (CWE-193) in the ConsumeUnit16Array and ConsumeUnit64Array functions in Velocidex Velociraptor before version 0.76.5 on Windows and Linux allows a local attacker to cause a Denial of Service (DoS) via a process crash by providing a specially crafted .evtx file to the parseevtx VQL plugin.

Velociraptor versions prior to 0.76.4 contain a resource exhaustion vulnerability in the server's agent control channel.

This allows a compromised or rogue Velociraptor client to crash the server via out-of-memory (OOM) by sending crafted messages through the normal client communication channel.

Velociraptor versions prior to 0.76.4 contain a cross organization authorization bypass in the HTTP API. A user with only the reader role in the root organization (the lowest authenticated role, holding only READRESULTS permission ) can issue a single authenticated HTTP GET that can read any files from other orgs - even if they have no explicit permissions in the target org.

However, the problem does not occur in reverse - a user with read access to a sub org is unable to read from other org or the root org.

Velociraptor versions prior to 0.76.3 contain a vulnerability in the query() plugin which allows access to all orgs with the user's current ACL token. This allows an authenticated GUI user with access in one org, to use the query() plugin, in a notebook cell, to run VQL queries on other orgs which they may not have access to. The user's permissions in the other org are the same as the permissions they have in the org containing the notebook.