CVE-2026-108710 in NornicDB
Summary
by MITRE • 10/11/2026
NornicDB through 1.4.1 contains a missing authorization vulnerability that allows authenticated users to bypass per-database read restrictions on the /nornicdb/search and /nornicdb/similar endpoints. Viewer-role users allowlisted for a database but denied read can submit search queries or node IDs to retrieve node IDs, labels and full property maps.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 10/11/2026
The vulnerability identified in NornicDB versions through 1.4.1 represents a critical failure in access control mechanisms, specifically classified under CWE-285 Improper Authorization. This flaw allows authenticated users with the Viewer role to bypass per-database read restrictions when interacting with specific API endpoints. The core technical issue lies in the application's inability to properly validate whether an authorized user has explicit permission to perform read operations on a targeted database before processing search or similarity queries. While the system correctly restricts direct data retrieval for unauthorized users, it fails to apply these same constraints to indirect access vectors provided by the /nornicdb/search and /nornicdb/similar endpoints. This discrepancy creates an authorization bypass where the application logic assumes that if a user is allowedlisted for a database in some capacity, they should have full read access via all available interfaces, ignoring granular permission settings that explicitly deny read privileges.
From an operational perspective, this vulnerability enables information disclosure and potential data exfiltration by users who are intended to be restricted observers. An attacker with Viewer-level credentials can submit search queries or specific node identifiers to the affected endpoints. Despite being denied standard read access, these requests succeed in returning sensitive internal data structures. The returned payload includes node IDs, labels, and full property maps associated with nodes within the database. This level of detail exposure is particularly dangerous because it reveals not only the existence of records but also their structural metadata and content properties. Such information can be leveraged by malicious actors to map out the database schema, identify high-value targets for further exploitation, or reconstruct sensitive business logic embedded in node labels and property values. The ability to retrieve full property maps effectively negates the security boundary established by the read restriction policy, turning a limited-view account into one with near-administrative visibility of data contents.
This vulnerability aligns closely with ATT&CK technique T1087.2 Account Discovery: Local Accounts if used to enumerate internal user or system identifiers, and more critically with T1530 Data from Cloud Storage Object Misconfiguration when considering the exposure of stored node properties. It also reflects CWE-640 Weak Password Recovery Mechanisms for Authorized Users in a broader sense of improper privilege enforcement during authentication sessions. The impact extends beyond simple data leakage; it undermines the principle of least privilege by allowing lower-tier users to access resources reserved for higher-tier roles such as Editors or Administrators. This can lead to compliance violations, particularly in environments subject to regulations like GDPR or HIPAA where unauthorized access to specific datasets is strictly prohibited. Furthermore, the exposure of internal node IDs and property maps may facilitate subsequent attacks, including SQL injection if those properties are later used in dynamic queries without proper sanitization, or social engineering campaigns based on revealed organizational structures.
Mitigation strategies must focus on enforcing consistent authorization checks across all API endpoints rather than relying on endpoint-specific permissions. Developers should implement a centralized access control layer that validates user privileges against the requested resource before any business logic is executed. This includes ensuring that search and similarity queries undergo the same permission verification as direct data retrieval operations. Additionally, implementing strict input validation and output encoding can help mitigate secondary risks associated with exposed metadata. For immediate remediation, upgrading to a version of NornicDB beyond 1.4.1 where this authorization logic has been corrected is essential. In cases where an upgrade is not immediately feasible, network-level controls such as Web Application Firewalls should be configured to monitor and restrict access patterns that resemble enumeration or bulk data extraction attempts by low-privilege accounts. Regular security audits focusing on role-based access control consistency across all application interfaces are recommended to prevent similar discrepancies in future development cycles.