CVE-2026-33713 in n8n
Summary
by MITRE • 03/25/2026
n8n is an open source workflow automation platform. Prior to versions 2.14.1, 2.13.3, and 1.123.26, an authenticated user with permission to create or modify workflows could exploit a SQL injection vulnerability in the Data Table Get node. On default SQLite DB, single statements can be manipulated and the attack surface is practically limited. On PostgreSQL deployments, multi-statement execution is possible, enabling data modification and deletion. The issue has been fixed in n8n versions 1.123.26, 2.13.3, and 2.14.1. Users should upgrade to one of these versions or later to remediate the vulnerability. If upgrading is not immediately possible, administrators should consider the following temporary mitigations: Limit workflow creation and editing permissions to fully trusted users only, disable the Data Table node by adding `n8n-nodes-base.dataTable` to the `NODES_EXCLUDE` environment variable, and/or review existing workflows for Data Table Get nodes where `orderByColumn` is set to an expression that incorporates external or user-supplied input. These workarounds do not fully remediate the risk and should only be used as short-term mitigation measures.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 04/01/2026
The vulnerability CVE-2026-33713 affects n8n, an open source workflow automation platform, and represents a critical SQL injection flaw within the Data Table Get node functionality. This vulnerability exists in versions prior to 2.14.1, 2.13.3, and 1.123.26, creating a significant security risk for organizations relying on this platform for automated workflows. The flaw specifically targets authenticated users who possess permissions to create or modify workflows, making it particularly dangerous in environments where multiple users have administrative privileges. The vulnerability manifests through improper input validation in the Data Table Get node, where user-supplied data is directly incorporated into SQL queries without adequate sanitization or parameterization.
The technical implementation of this vulnerability stems from insufficient input validation within the database query construction process. When the Data Table Get node processes user input, particularly through the orderByColumn parameter, the system fails to properly escape or parameterize the input values before incorporating them into SQL statements. This allows malicious users to inject additional SQL commands that can be executed by the database engine. The impact varies significantly based on the underlying database system in use, with SQLite deployments being more limited in scope due to their single-statement execution model. However, when deployed with PostgreSQL, the vulnerability becomes substantially more dangerous as multi-statement execution becomes possible, enabling attackers to perform data modification, deletion, and potentially extract sensitive information from the database.
The operational impact of this vulnerability extends beyond simple data compromise, as it can enable attackers to escalate privileges and gain unauthorized access to the underlying database infrastructure. Organizations using n8n with PostgreSQL deployments face the most severe consequences, as the multi-statement execution capability allows for complex attack patterns including data exfiltration, database corruption, and potential lateral movement within the network. The vulnerability aligns with CWE-89, which specifically addresses SQL injection flaws, and represents a clear violation of secure coding practices that require proper input validation and parameterization of database queries. From an adversary perspective, this vulnerability maps to ATT&CK technique T1078.004, which covers valid accounts with elevated privileges, as the attack requires authenticated access to workflow creation capabilities.
The remediation process involves upgrading to the fixed versions 1.123.26, 2.13.3, or 2.14.1, which implement proper input sanitization and parameterization of database queries. Until such upgrades are possible, administrators should implement layered mitigations including strict access controls limiting workflow creation and editing permissions to fully trusted users only. The temporary workaround of disabling the Data Table node through the NODES_EXCLUDE environment variable provides an additional layer of protection, while comprehensive workflow reviews focusing on Data Table Get nodes with external input in orderByColumn parameters can help identify and remediate existing vulnerabilities. These mitigations align with defense-in-depth principles and help reduce the attack surface while maintaining operational functionality. The vulnerability demonstrates the critical importance of input validation in database-driven applications and highlights the need for comprehensive security testing, particularly for platforms that handle user-supplied workflow data and integrate with various database backends. Organizations should also consider implementing database activity monitoring and regular security assessments to detect and prevent similar vulnerabilities in their workflow automation environments.