CVE-2026-123291 in Datalore
Summary
by MITRE • 11/06/2026
In JetBrains Datalore before 2026.4 improper owner validation allowed reading another workspace's issues and runs notebook
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 11/06/2026
The vulnerability identified in JetBrains Datalore prior to version 2026.4 represents a critical failure in access control mechanisms, specifically categorized under CWE-284 Improper Access Control. This flaw stems from an insufficient validation of the requesting user's ownership or authorization status when interacting with workspace-specific resources such as issues and notebook execution runs. In secure software architecture, every request to retrieve sensitive data must be rigorously checked against the identity and permissions of the authenticated session. However, in this instance, the application logic failed to enforce strict boundaries between distinct workspaces, allowing a user to bypass intended isolation protocols. This type of vulnerability is particularly dangerous because it undermines the fundamental principle of multi-tenancy or workspace segregation that enterprise data science platforms rely upon to protect proprietary code and datasets.
From an operational perspective, this flaw enables unauthorized information disclosure where one tenant can access data belonging to another. Specifically, attackers could read issues associated with other users' workspaces, potentially exposing sensitive project management details, bug reports, or internal communications. Furthermore, the ability to view notebook runs allows adversaries to inspect execution logs, output variables, and intermediate states of computational processes. This exposure is significant because notebooks often contain hardcoded credentials, API keys, database connection strings, or proprietary algorithms that are executed during runtime. By observing these runs, an attacker could extract sensitive configuration data or reverse-engineer business logic without ever needing direct access to the source code files themselves.
The attack vector for this vulnerability typically involves a malicious actor who has valid authentication credentials within the Datalore environment but lacks explicit permissions for the target workspace. The attacker would craft specific API requests targeting endpoints responsible for fetching issue lists and notebook run histories, omitting or manipulating parameters that indicate ownership. Because the server-side validation is deficient, these requests are processed successfully rather than being rejected with an access denied error. This behavior aligns with MITRE ATT&CK technique T1005 Data from Local System Retrieval, as it involves gathering information directly from a compromised system's storage mechanisms through legitimate application interfaces that have been abused due to poor input validation and authorization checks.
The impact of this vulnerability extends beyond simple data leakage; it compromises the integrity and confidentiality guarantees expected by enterprise customers using Datalore for collaborative machine learning projects. Organizations relying on these platforms assume that their intellectual property is isolated from other tenants or departments. The ability to read another workspace's issues could reveal strategic project timelines, known vulnerabilities in internal software, or personnel assignments. Similarly, accessing notebook runs might allow an attacker to infer the structure of data pipelines or identify specific models being trained, which could be leveraged for further attacks such as model poisoning or targeted phishing campaigns based on observed technical workflows.
Mitigation strategies must prioritize immediate patching and rigorous access control reviews. JetBrains addressed this issue in version 2026.4 by implementing stricter owner validation logic that ensures the authenticated user is explicitly authorized to view resources within a specific workspace context. For organizations still running older versions, temporary mitigations include restricting network-level access to Datalore endpoints if possible, enforcing strict role-based access control policies where users are granted only the minimum necessary permissions, and monitoring for anomalous API calls that attempt to access resources outside of assigned workspaces. Additionally, security teams should audit their current configurations to ensure no shared tokens or overly permissive service accounts exist that could exacerbate this risk if exploited by insider threats or compromised credentials. Regular penetration testing focused on horizontal privilege escalation is recommended to detect similar flaws in other parts of the application ecosystem before they can be leveraged for data exfiltration.