CVE-2026-111670 in ClickVisual
Summary
by MITRE • 10/16/2026
ClickVisual through 1.1.2 contains a missing authorization vulnerability in the /api/v2/reports handlers that allows authenticated low-privileged users to access ClickHouse instances they were not granted. Attackers can iterate the instance-id parameter in ReportSourceDatabases, ReportSourceTables, ReportTableColumns and WhereCheckRun to enumerate schemas and infer row counts of restricted tables.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 10/17/2026
The vulnerability identified in ClickVisual versions through 1.1.2 represents a critical failure in access control mechanisms within its reporting API subsystem. Specifically, the flaw resides in the /api/v2/reports endpoint handlers which are designed to facilitate data visualization and analysis by connecting to underlying ClickHouse database instances. While the application correctly enforces authentication for general access, it fails to perform adequate authorization checks when processing requests related to specific report sources. This architectural oversight allows authenticated users with low-privilege roles to bypass intended restrictions on which databases or tables they are permitted to query. The core technical flaw is a missing object-level permission check during the execution of queries against ClickHouse instances referenced in various parameters such as ReportSourceDatabases, ReportSourceTables, ReportTableColumns, and WhereCheckRun. Instead of validating whether the current user has explicit rights to access the specific instance-id provided in these fields, the application trusts the client-supplied identifier without verifying it against an internal permission matrix or role-based access control list.
This lack of server-side validation enables a direct exploitation path for information disclosure and data enumeration. An attacker with valid but limited credentials can manipulate the API parameters to point towards ClickHouse instances that are logically isolated from their authorized scope. By iterating through different instance identifiers within these specific endpoints, an adversary can systematically probe the backend database infrastructure. This capability allows them to enumerate available schemas and infer row counts of restricted tables even if they cannot directly read the content of those rows in a meaningful way initially. The ability to determine schema structures and data volumes constitutes a significant reconnaissance advantage, as it reveals the existence and organization of sensitive datasets that should remain hidden from lower-privileged users. This behavior aligns with CWE-269, which classifies Improper Privilege Management, specifically highlighting scenarios where an actor is granted privileges they are not authorized to have or can bypass restrictions intended for their role.
The operational impact of this vulnerability extends beyond simple data leakage; it facilitates deeper lateral movement and more sophisticated attacks against the organization's data infrastructure. By successfully enumerating schemas and table structures, attackers gain a detailed map of the database environment. This knowledge is instrumental in planning further exploitation attempts, such as crafting precise SQL injection payloads or identifying high-value targets for subsequent exfiltration if additional vulnerabilities are discovered. The ability to infer row counts also aids in statistical inference attacks where patterns in data volume can reveal sensitive business metrics or operational statuses. From a threat modeling perspective, this vulnerability supports the ATT&CK technique T1087, Account Discovery, as it allows an attacker to enumerate accounts and services within the database environment. Furthermore, because the exploitation occurs through authenticated API calls, it may evade basic network-level security controls that do not inspect application-layer logic for privilege escalation or unauthorized data access patterns.
Mitigation strategies must focus on implementing robust authorization checks at the point of request processing rather than relying solely on authentication. Developers should enforce strict validation of instance-id parameters against a server-side registry of user permissions before any database connection is established or query is executed. This involves ensuring that every API call to /api/v2/reports verifies that the authenticated user has explicit read access rights for the specific ClickHouse instance and associated tables referenced in the request payload. Additionally, implementing principle of least privilege across all application roles ensures that low-privileged users are denied access to sensitive data sources by default. Security testing should include automated checks for broken object level permissions using tools designed to detect CWE-269 flaws. For immediate remediation without code changes, network segmentation can be employed to isolate ClickHouse instances from the web server tier where possible, and strict input validation on API endpoints can help block malformed or unauthorized instance identifiers before they reach the database layer.