CVE-2026-82306 in StarRocks
Summary
by MITRE • 08/28/2026
StarRocks through 4.0.13 contains an information disclosure vulnerability in the query_detail endpoint that returns unfiltered query history for all users. Authenticated attackers with low privileges can access full SQL text, execution plans, and profiling data from every query executed by other users, including statements containing credentials.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 08/28/2026
The vulnerability identified in StarRocks versions through 4.0.13 represents a critical failure in access control mechanisms within the database management system's web interface or API layer. Specifically, this flaw resides in the query_detail endpoint, which is designed to provide detailed information about specific SQL queries for monitoring and debugging purposes. The core technical deficiency lies in the absence of proper authorization checks when retrieving these details. Instead of validating that the requesting user has permission to view the data associated with a particular query ID or session, the system returns unfiltered results based solely on the existence of the resource identifier. This allows any authenticated user, regardless of their privilege level, to iterate through known or guessed query identifiers and retrieve sensitive execution metadata belonging to other users within the same cluster.
From a technical perspective, this vulnerability enables an attacker with low-privileged access to perform unauthorized data exfiltration by accessing full SQL text, detailed execution plans, and profiling data generated by high-privilege accounts or other tenants in a multi-user environment. The impact is severe because database queries often contain sensitive business logic, personally identifiable information, and frequently hardcoded credentials such as passwords for external databases or API keys embedded within stored procedures or application connection strings. By accessing the full SQL text of these queries, an attacker can extract plaintext secrets that were never intended to be exposed outside the specific context of their original execution environment. Furthermore, access to execution plans allows attackers to understand database schema structures and optimization strategies, which facilitates further reconnaissance and targeted attacks against data integrity or availability.
This vulnerability aligns with CWE-200: Information Exposure, as it involves the accidental disclosure of sensitive information that could be exploited by an attacker. Additionally, it maps directly to MITRE ATT&CK technique T1530: Data from Cloud Storage Object, specifically in contexts where internal services are treated as data stores, and more accurately to T1078: Valid Accounts if the attacker leverages legitimate credentials obtained through other means such as phishing or credential stuffing. The scenario also reflects CWE-284: Improper Access Control, highlighting a failure in enforcing proper authorization policies for sensitive resources. In multi-tenant database environments where data isolation is paramount, this flaw undermines the fundamental security boundary between users, potentially leading to significant regulatory compliance violations under frameworks such as GDPR or HIPAA if protected health information or personal data is exposed.
The operational impact extends beyond simple credential theft. With access to profiling data and execution plans, attackers can perform sophisticated analysis of database performance bottlenecks and query patterns, which aids in crafting more efficient malicious queries for future attacks like SQL injection exploitation or denial-of-service attempts tailored to the specific infrastructure configuration. The ability to view historical queries also means that transient sessions containing sensitive operations remain exposed long after they have completed, creating a persistent window of opportunity for data theft even if immediate session controls are otherwise secure. This lack of temporal and contextual access control fundamentally compromises the confidentiality guarantees expected from enterprise-grade database systems.
To mitigate this vulnerability, organizations running StarRocks versions up to 4.0.13 must immediately apply the latest security patches provided by the vendor that enforce strict role-based access control on the query_detail endpoint. Access should be restricted exclusively to users with administrative privileges or specific monitoring roles explicitly granted permission to view other users' query details for operational purposes. For environments where patching is not immediately feasible, network-level controls such as firewall rules restricting access to the management interface and API endpoints from untrusted networks can provide a layer of defense in depth. Additionally, implementing strict input validation and ensuring that all sensitive data within SQL statements is encrypted or masked before being stored or returned by diagnostic APIs can reduce the impact if similar vulnerabilities are discovered in future versions. Regular audits of user permissions and review of access logs for anomalous query detail retrieval patterns are also recommended to detect potential exploitation attempts early.