Description

StarRocks performs no privilege check when a legacy synchronous materialized view is dropped. Every other statement type routed through AuthorizerStmtVisitor calls into Authorizer before execution, but visitDropMaterializedViewStatement returns immediately with a comment stating the check happens in execution logic. That holds only for asynchronous materialized views: LocalMetastore.dropMaterializedView calls Authorizer.checkMaterializedViewAction inside a branch taken when the resolved table is a MaterializedView. A legacy synchronous materialized view is stored as a rollup index on an OlapTable rather than a MaterializedView, so the other branch runs, reaching AlterJobMgr.processDropMaterializedView and MaterializedViewHandler, neither of which contains any Authorizer call. The former locates the target by scanning every OlapTable in the named database for a matching rollup index, and the latter validates only table state and name conflicts. Any authenticated account can therefore drop a legacy synchronous materialized view belonging to any database, holding no grant on the view, the base table or the database, and the drop is indistinguishable from an authorized one.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.1",
  "pubDate": "2026-08-26T10:16:42.637Z",
  "pubdate": "2026-08-26T10:16:42.637Z",
  "executiveSummary": "StarRocks exhibits a critical authorization bypass vulnerability during the execution of DROP MATERIALIZED VIEW statements targeting legacy synchronous materialized views (rollups).\nThe vulnerability originates from inconsistent enforcement of access control policies within the AuthorizerStmtVisitor component, which fails to invoke the Authorizer for specific legacy object types.\nThis flaw allows any authenticated user to delete materialized views across the entire database instance, regardless of their assigned permissions or ownership status.\nThe impact is significant, leading to unauthorized data structure modification, potential service disruption, and loss of performance optimization metadata.\nNo specific privileges are required to exploit this; a valid session on the StarRocks cluster is the sole prerequisite.\nThe vulnerability highlights a failure in the architectural security boundary where legacy synchronous rollups are erroneously handled outside the centralized authorization framework.",
  "technicalDetails": "The root cause of this vulnerability lies in the logic governing AuthorizerStmtVisitor. When a DROP MATERIALIZED VIEW statement is processed, the visitor implementation for visitDropMaterializedViewStatement explicitly returns without performing an authorization check, relying on the assumption that subsequent execution logic will validate permissions.\nIn the StarRocks codebase, materialized views are categorized into two types: modern asynchronous materialized views and legacy synchronous materialized views (often stored as rollup indices on an OlapTable).\nFor asynchronous materialized views, LocalMetastore.dropMaterializedView correctly triggers Authorizer.checkMaterializedViewAction, ensuring that the request is verified against the user's current privileges. However, for legacy synchronous materialized views, the resolution logic classifies the object as an OlapTable index rather than a MaterializedView object.\nThis classification discrepancy forces the execution path into a branch that invokes AlterJobMgr.processDropMaterializedView and MaterializedViewHandler. Neither of these components incorporates a call to the Authorizer or any permission validation mechanism.\nThe exploitation flow is as follows: 1) An attacker establishes a connection to the StarRocks instance as an authenticated user. 2) The attacker issues a DROP MATERIALIZED VIEW statement targeting a legacy synchronous materialized view in a database where they possess no permissions. 3) The AuthorizerStmtVisitor bypasses the authorization check due to the object's classification. 4) The execution engine reaches AlterJobMgr, which proceeds to locate the rollup index by scanning all OlapTables within the target database. 5) The index is successfully dropped without any ownership or grant verification.\nBecause the drop action is executed by the system handlers without checking if the requester has the required permissions on the base table or the database, the operation is effectively indistinguishable from a legitimate authorized drop command in system logs, complicating incident detection and forensic analysis.\nThis vulnerability is particularly severe because the deletion of rollup indices impacts query performance, effectively serving as a denial-of-service vector against analytic workloads that rely on specific materialized index structures for low-latency execution."
}