GHSA-q7m3-rhxg-7vxr: Path Traversal
Affected versions < 1.0.0
Patched version 1.0.0
Description In versions prior to 1.0.0, the SQLite node accepted the database file path as a direct node parameter visible and editable in the workflow. A workflow author who mapped untrusted user input to the dbpath field could allow an attacker to control which file was opened by SQLite, potentially enabling path traversal to read or overwrite arbitrary files accessible to the n8n process.
The vulnerability requires the workflow author to explicitly wire untrusted input to the dbpath parameter, so it does not affect standalone deployments where only trusted users author workflows. However, in multi-tenant or user-facing n8n deployments the risk is elevated.
Fixed in v1.0.0 by moving the database path into a credential (v2 node architecture), which is stored server-side and not controllable by workflow input data.
References - Fix commit: 145a887 - Introduced credential-based path: v2 node
Credits dyingman1 (role: Reporter)
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
npm/n8n-nodes-sqlite3to a version that resolves this vulnerability.Fixed in 1.0.0 - Upgrade
Upgrade
SQLite node (n8n)to a version that resolves this vulnerability.Fixed in 1.0.0 - Configuration
For versions prior to 1.0.0, ensure the SQLite node no longer accepts a workflow-visible, editable db_path parameter that could be wired from untrusted user input; apply the v1.0.0 fix where the database path is moved into a credential.
n8n workflow / SQLite node db_path (use credential-backed database path instead of workflow-visible node parameter) = Use credential-based db_path (credential wiring) rather than a direct node parameter - Operational
Review existing multi-tenant or user-facing n8n workflows that may wire untrusted input into the SQLite node’s db_path; update them to remove any direct mapping to db_path so the database path comes from the credential as in v1.0.0 (fix commit: 145a887).
Event History
Frequently Asked Questions
Which deployments are most exposed?
Multi-tenant or user-facing n8n deployments are at elevated risk when workflow authors can map untrusted user-controlled data into the SQLite node's db_path field. Standalone deployments in which only trusted users author workflows are not affected by this condition.
What must an attacker be able to do to exploit the issue?
A workflow author must explicitly wire untrusted input to the db_path parameter. An attacker who can influence that input may then control the file SQLite opens, potentially reading or overwriting files accessible to the n8n process.
Does the default node configuration allow exploitation?
No. Exploitation depends on an author configuring the workflow to pass untrusted input into db_path; it is not triggered merely by using the SQLite node.
What changes in the patched release?
Version 1.0.0 moves the database path into a server-side credential using the v2 node architecture. Workflow input data can no longer control the database path through the node parameter.
What can be done before upgrading?
Review workflows for SQLite nodes whose db_path field is mapped from untrusted input, and remove those mappings. Limit workflow authoring to trusted users where possible.