CVE-2026-18635

This is a cross-org privilege escalation in Velociraptor's VQL query() plugin. When multi-org support was added, the permission check for impersonation was written in the caller's security context rather than the target organization's context. An administrator in any organization can impersonate any user in any other organization in the deployment — not because the check was forgotten, but because the executing context is the default reference frame for security decisions, and the target org existed outside the code path's visible scope. The blast radius here is asymmetric in a way CVSS 7.2 obscures. The exploitability threshold is low — admin access in any org — but the impact ceiling is total: compromise of one throwaway org grants persistence across every organization in the deployment. This isn't a per-org privilege issue; it's a deployment-wide trust collapse. What to verify in your environment: First, confirm you're running a version that ever had multi-org support — if you're single-org, this doesn't apply. Second, audit your query() plugin usage, particularly any VQL artifacts or client scripts that invoke the plugin with an explicit org_id parameter. Check whether those calls are checking permissions in the caller's org rather than the target org. The vulnerable pattern is when the permission check resolves to the context where the code executes rather than the context being operated on. The fix structure matters. If the commit is a one-line parameter swap, the vulnerability was structurally latent — the target org was in scope but the wrong reference was used. If the fix required threading target org context through multiple call layers, the original design never exposed target org as a variable, making this a design gap rather than a coding error. Either way, audit other VQL plugins: query() is documented and reviewed. Less-used or internal plugins may have made the same silent transition from single-org to multi-org without architectural revision. The deeper question is whether your deployment's threat model treats multi-tenant boundaries as explicit security boundaries or as logical separations within a shared trust domain. If cross-org operations are syntactically invisible in your plugin code — just another parameter rather than a distinct operation class — then this class of vulnerability is reproducible. Treat every cross-context operation as a mandatory review point: whose permissions actually govern this action?

Reviewed through automated stages and approved by a human before publication.