Description

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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "4.9",
  "pubDate": "2026-10-05T17:17:16.183Z",
  "pubdate": "2026-10-05T17:17:16.183Z",
  "executiveSummary": "This vulnerability is an Improper Authorization flaw within the Velociraptor WatchEvent gRPC API, specifically related to multi-tenancy logical isolation.\nThe issue stems from a failure in the server-side access control validation logic, which validates the requestor's permissions against their originating organization rather than the target organization specified in the gRPC request.\nAn authenticated user with API access in a single organization can successfully subscribe to and stream events from other organizations they are not authorized to access.\nThe impact includes unauthorized information disclosure of sensitive telemetry, system logs, and security events across organizational boundaries, severely compromising the multi-tenancy security posture of the platform.\nExploitation requires active API credentials within the system and the ability to interface with the WatchEvent gRPC endpoint. No specialized exploit code is required beyond standard gRPC client requests to manipulate the OrgId parameter.\nThis represents a significant risk to data confidentiality in deployments utilizing Velociraptor's organizational separation features.",
  "technicalDetails": "The vulnerability resides within the Velociraptor server's gRPC request handling logic for the WatchEvent API. The API is designed to allow clients to subscribe to event streams; however, the request schema allows the caller to define the 'OrgId' parameter, designating the target organization from which the event stream should be sourced.\nThe root cause is a deficiency in the authorization enforcement mechanism. When a request is received, the server attempts to verify the caller's privileges; however, the access control check is performed against the context of the caller's authenticated organization (the 'Subject' Org) rather than validating that the caller holds the appropriate permissions within the target organization (the 'Object' Org).\nThis logical decoupling allows a malicious or compromised API key—possessing sufficient 'read' privileges within their own organization—to bypass authorization boundaries. By sending a gRPC request to the WatchEvent endpoint with a modified 'OrgId' field, the attacker instructs the server to attach the subscriber to the event bus of an unauthorized organization.\nAttack flow: 1. The attacker authenticates with their legitimate, albeit restricted, API credentials. 2. The attacker initiates a gRPC WatchEvent call. 3. The attacker crafts the request payload, explicitly setting the 'OrgId' field to an identifier corresponding to a target organization they wish to monitor. 4. The server-side authentication middleware validates the user's token but incorrectly associates the authorization check with the user's home organization. 5. The server grants the subscription request, effectively hooking the attacker's gRPC stream into the target organization's event pipeline. 6. The attacker receives a continuous flow of sensitive event data originating from the target organization, which may include system metadata, endpoint activity, and other potentially confidential telemetry.\nThe vulnerability exists at the gRPC service layer, specifically within the WatchEvent implementation. It affects any deployment where multiple organizations are hosted on a single Velociraptor instance. Because the vulnerability is logic-based, it persists regardless of the network-layer configuration, as long as the gRPC interface is reachable by authenticated users."
}