Because legacy synchronous materialized views are stored as rollup indexes within an OlapTable object rather than as standalone MaterializedView objects, the system fails to trigger the Authorizer.checkMaterializedViewAction logic. Instead, the process proceeds through AlterJobMgr.processDropMaterializedView and MaterializedViewHandler, neither of which contains authorization checks. Consequently, any authenticated user can successfully execute a command to drop a legacy synchronous materialized view in any database, regardless of their actual permission set. This issue presents a significant availability risk, as an attacker can silently remove materialized views, causing downstream query failures and data inconsistencies.

Impact

Successful exploitation allows any authenticated account to delete legacy materialized views belonging to any database, despite lacking the necessary grants on the views, the underlying base tables, or the target databases. This results in unauthorized data modification and potential service disruption for users relying on those views for reporting or query performance.

Recommendation

Prioritize patching StarRocks to a version where privilege checks are correctly implemented in MaterializedViewHandler for legacy objects. In the interim, restrict access to the StarRocks environment to strictly authorized users, as any authenticated account currently possesses the ability to drop these materialized views. Audit current database schemas to identify all legacy synchronous materialized views to assess the potential impact of potential deletion attempts.