CVE-2026-54687: Path Traversal via User-Controlled Database File Path in n8n-nodes-sqlite3

The n8n-nodes-sqlite3 package is a community-contributed integration for n8n, a popular workflow automation platform. This node allows workflows to interact directly with a local SQLite database file on the hosting file system. In versions prior to 1.0.0, the node exposed the database path via a parameter named db_path. By default, n8n parameters support dynamic data expression evaluation, which lets input fields parse and resolve values derived from upstream nodes.\n\nThis design introduces a path traversal vulnerability (CWE-22) when workflow authors configure the node to dynamically set the database file path using untrusted external inputs. For example, if webhooks or HTTP triggers feed user-controlled parameters directly into the db_path configuration, an attacker can manipulate the file path. This manipulation allows the backend process to interact with arbitrary SQLite-compatible databases across the system, restricted only by the privileges of the underlying n8n process.

The root cause of this vulnerability lies in the default handling of input fields in the n8n integration framework combined with insufficient input validation. In the legacy implementation (nodes/SqliteNode/v1/SqliteV1.node.ts), the db_path property was declared as a standard string parameter. In the n8n node ecosystem, string parameters are implicitly configured to allow dynamic data expressions. This design means that the n8n runtime evaluates any syntax enclosed within curly braces before passing the computed string to the node's underlying execution logic.\n\nWhen the SQLite node processes this parameter, it utilizes the evaluated string directly as the file path argument for the SQLite database driver. Because there is no check or sanitization to ensure the path remains restricted to a designated directory, an attacker who can inject data into the dynamic expression can traverse the directory structure. This configuration allows arbitrary file system navigation, leading to improper limitation of a pathname to a restricted directory (CWE-22).

To understand the flaw and its remediation, examine the vulnerable implementation in SqliteV1.node.ts. The original parameter definition exposed db_path without restrictive properties, allowing expression evaluation by default.\n\ntypescript\n// Before patch\n{\n\tdisplayName: 'Database Path',\n\tname: 'db_path',\n\ttype: 'string',\n\tdefault: '',\n\tplaceholder: '/path/to/database.sqlite',\n\tdescription: 'The path to the SQLite database file',\n\trequired: true,\n}\n\n\nThe patch resolves the issue by introducing the noDataExpression: true property to the parameter configuration block. This property explicitly instructs the n8n execution engine to treat the input as a static literal string and bypass any template expression evaluation.\n\ntypescript\n// After patch\n{\n\tdisplayName: 'Database Path',\n\tname: 'db_path',\n\ttype: 'string',\n\tdefault: '',\n\tplaceholder: '/path/to/database.sqlite',\n\tdescription: 'The path to the SQLite database file',\n\trequired: true,\n\tnoDataExpression: true, // Prevents expression evaluation and dynamics\n}\n\n\nBy setting this flag, any input matching expression syntax (such as {{ ... }}) is treated strictly as a literal, neutralizing the traversal vector. Additionally, the node's version 2 (V2) implementation introduces a credential-based architecture where the database path is stored securely within backend credentials configuration rather than dynamic node properties.

Exploitation requires a specific pre-existing workflow pattern where a workflow author maps untrusted external input (such as an incoming query string or POST request payload) directly to the db_path parameter. Under these circumstances, the exploitation flow proceeds as follows:\n\nmermaid\ngraph LR\n Attacker["Attacker Payload"] -->|1. Webhook Request| Webhook["Webhook Trigger"]\n Webhook -->|2. Untrusted db_path Expression| SqliteNode["SqliteV1 Node"]\n SqliteNode -->|3. Traversed File Path| SQLite["SQLite Driver"]\n SQLite -->|4. File Interaction| TargetFile["Target Database File"]\n\n\nFirst, the attacker crafts an HTTP request to a webhook trigger configured in n8n, containing a traversal string in the query parameter (e.g., ?path=../../../../var/lib/conf.db). When the workflow executes, the webhook node passes this parameter to the vulnerable n8n-nodes-sqlite3 node. The n8n engine evaluates the expression {{ $json.query.path }} and passes the traversed path to the SQLite driver. The driver then attempts to open or initialize the database file at the specified path. Depending on the SQL queries executed in subsequent node steps, the attacker can read from or write to arbitrary files, provided they are structured as SQLite databases or can be parsed as such.

The impact of this vulnerability is classified as Medium, with a CVSS v4.0 base score of 6.1. This rating reflects the high attack complexity and specific operational requirements, as exploitation is not possible in the default configuration. A successful exploit requires a workflow to be explicitly configured to accept dynamic database paths from untrusted input sources.\n\nIf these prerequisites are met, the vulnerability poses significant confidentiality and integrity risks. An attacker can read sensitive information stored in other SQLite databases on the system or write arbitrary database files. This action could result in file corruption, resource exhaustion, or the overwrite of critical configuration databases accessible to the n8n execution environment. The vulnerability does not directly extend past the host process boundary, meaning subsequent system impact is limited.

To remediate this vulnerability, administrators and developers must take immediate action. The primary remediation strategy is upgrading the n8n-nodes-sqlite3 package to version 1.0.0 or higher. This update applies the noDataExpression restriction to the legacy V1 node and introduces secure V2 node architectures.\n\nAdditionally, organizations should audit existing workflows for dangerous patterns. Workflows can be analyzed by searching their JSON definitions for dynamic expressions mapped to the db_path parameter. If immediate patching is not possible, administrators should manually replace dynamic expressions in the db_path field with hardcoded, absolute paths to approved directories, thereby preventing any runtime user control over the target file location.