CVE-2026-77846 in ash_sqlite
Summary
by MITRE • 08/30/2026
Improper Neutralization of Special Elements in Data Query Logic vulnerability in ash-project ash_sqlite allows an attacker who controls a get_path/2 segment to traverse into nested JSON the application never exposed, disclosing private or sensitive? embedded fields.
AshSqlite.SqlImplementation builds the SQLite json_extract path with "$." <> Enum.join(right, "."), so a single segment containing ., [, ], or $ re-interprets the JSON path (for example "private.secret" descends two levels instead of naming one key). The path is bound as a parameter, so this is confined to the JSON-path grammar rather than SQL. Any endpoint that lets user input reach a get_path segment (a common pick-a-field pattern) can read nested values it never meant to expose.
This issue affects ash_sqlite: from 0.1.2-rc.0 before 0.2.18.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 08/30/2026
The vulnerability identified in the AshSqlite library represents a critical failure in input validation and data query logic, specifically categorized under CWE-79 Improper Neutralization of Special Elements Used in an SQL Command or more accurately in this context as JSON Path Injection due to improper neutralization of special elements. The core technical flaw lies within the SqlImplementation module where the application constructs SQLite json_extract paths by concatenating a base string with user-supplied segments joined by dots. This approach assumes that each segment provided by the user represents a single, literal key name within the JSON structure. However, because the resulting path is interpreted as a JSONPath expression rather than a simple dot-separated identifier, special characters such as periods, square brackets, and dollar signs are not escaped or sanitized before being incorporated into the query logic. This allows an attacker who controls any segment of the get_path/2 function to inject additional traversal commands that alter the intended scope of the data retrieval operation.
From an operational perspective, this flaw enables unauthorized access to nested JSON fields that were never explicitly exposed by the application's API or user interface. For instance, if a developer intends for a client to retrieve a value from a top-level key named "private.secret", they might pass ["private.secret"] as the path segment. The system concatenates this with "$." to form "$.private.secret". In standard JSONPath syntax, however, the period acts as a delimiter indicating a descent into nested objects rather than part of a single key name. Consequently, the database engine interprets this not as one key but as two levels: first accessing an object at "private", and then extracting the value from its child key named "secret". This mechanism effectively bypasses access control boundaries that rely on exposing only specific top-level or shallowly nested fields, allowing attackers to read sensitive embedded data such as internal identifiers, configuration secrets, or user-specific private information.
The impact of this vulnerability is significant because it compromises the confidentiality and integrity of application data without requiring authentication bypass or SQL injection in the traditional sense. Since the path parameter is bound correctly for SQL execution, the attack does not lead to arbitrary code execution or database structure manipulation but rather focuses strictly on data exfiltration through logical exploitation of the JSON parsing engine. This aligns with ATT&CK technique T1087 Account Discovery and potentially T1530 Data from Cloud Storage if the JSON represents cloud-synced objects, as it allows an attacker to enumerate and extract hidden attributes that should remain inaccessible. The vulnerability is particularly dangerous in applications using a common pattern where users can dynamically select which fields of a resource they wish to retrieve, as this flexibility becomes a vector for deep traversal into protected data structures.
Mitigation strategies must focus on strict input validation and the use of safe API methods provided by the underlying database driver or JSON library. Developers should avoid constructing JSON paths through simple string concatenation when user input is involved. Instead, they should utilize functions that explicitly treat each segment as a literal key name, ensuring that special characters are escaped or handled in a way that prevents path traversal interpretation. If dynamic field selection is required, the application must maintain an allowlist of permitted top-level keys and reject any input containing delimiters like periods or brackets unless those specific nested paths have been explicitly whitelisted by the administrator. Upgrading to ash_sqlite version 0.2.18 or later resolves this issue as it implements proper sanitization for these special elements within data query logic, ensuring that user-controlled segments are treated strictly as literal identifiers rather than executable JSONPath commands.