CVE-2026-111695 in data-platform-open
Summary
by MITRE • 10/16/2026
Shaiwz data-platform-open through commit efeacd3 contains an insecure direct object reference vulnerability that allows authenticated workspace members to access other workspaces' datasources by numeric id. Attackers can send foreign sequential ids to /datasource/detail, /listSchemaTable, /tableDetail, /update or /delete to obtain JDBC credentials, enumerate database schemas, and modify or delete datasources.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 10/16/2026
The vulnerability identified in Shaiwz data-platform-open prior to commit efeacd3 represents a critical failure in access control mechanisms, specifically classified as an Insecure Direct Object Reference (IDOR). This flaw stems from the application's reliance on client-supplied numeric identifiers to locate and manipulate resources without performing adequate authorization checks against the requesting user's permissions. By accepting sequential integer values for workspace datasource IDs, the system fails to verify that the authenticated user possesses administrative or member privileges specifically within the context of the targeted workspace. Consequently, an attacker who has valid authentication credentials can bypass logical access controls by manipulating these identifiers in HTTP requests directed at various endpoints including /datasource/detail, /listSchemaTable, /tableDetail, /update, and /delete. This lack of boundary enforcement allows users to traverse across organizational boundaries within the platform, accessing resources that are logically isolated from their assigned workspace.
The operational impact of this vulnerability is severe due to the breadth of actions an attacker can perform once they gain access to foreign datasources. By exploiting the /datasource/detail endpoint, attackers can retrieve sensitive configuration data associated with external databases, most notably JDBC connection strings which often contain plaintext usernames and passwords for backend database systems. This exposure facilitates further lateral movement into internal infrastructure where these credentials may be reused or possess higher privileges than intended within the Shaiwz context. Furthermore, through endpoints such as /listSchemaTable and /tableDetail, attackers can enumerate the structure of external databases, revealing table names, column types, and potentially sensitive data stored therein. This capability effectively turns a single authenticated account into a pivot point for comprehensive database reconnaissance across multiple workspaces that should remain isolated from one another.
Beyond information disclosure, the vulnerability extends to integrity violations through the /update and /delete endpoints. An attacker can modify datasource configurations, potentially redirecting connections to malicious servers or altering connection parameters to disrupt service availability. More critically, the ability to delete datasources allows for denial of service attacks against other workspaces by removing their critical data connectivity definitions. This destruction of configuration data can halt business operations within those affected workspaces until an administrator manually restores the datasource settings from backups or reconfigures them entirely. The combination of credential theft, schema enumeration, and destructive capability creates a multi-stage attack path that compromises confidentiality, integrity, and availability simultaneously.
From a classification perspective, this vulnerability aligns with CWE-639, which describes Insecure Direct Object References where an application exposes internal implementation objects like database keys or file names to users without proper access control checks. It also maps directly to the MITRE ATT&CK framework technique T1078, specifically Valid Accounts and potentially T1528 Steal Application Access Tokens if session tokens are leveraged for further exploitation. The sequential nature of the IDs suggests a lack of randomization or UUID usage in resource identification, which is a common anti-pattern that facilitates brute-force enumeration attacks even when access controls are partially implemented but flawed.
Mitigation strategies must focus on implementing robust authorization checks at every point where external identifiers are used to retrieve or modify resources. Developers should enforce object-level permissions by verifying that the authenticated user's session context includes explicit rights for the specific workspace associated with the requested datasource ID, rather than relying solely on global authentication status. Additionally, replacing sequential numeric IDs with universally unique identifiers (UUIDs) can significantly increase the difficulty of enumeration attacks, although this is a secondary defense and does not replace proper access control logic. Input validation should also be applied to ensure that only expected data types are processed, though this alone cannot prevent IDOR if authorization checks are absent. Regular security code reviews focusing on logical flaws in business logic layers are essential to identify such vulnerabilities before deployment.