CVE-2026-59257: n8n SQL Injection in Legacy MySQL v1 Node

Technical summary

The vulnerability stems from unsafe string concatenation in the MySQL v1 node's executeQuery operation. The node evaluates n8n expressions (marked by {{ ... }}) and directly interpolates the results into raw SQL strings without using prepared statements or parameterized queries. When expression values originate from external, attacker-controlled sources—typically HTTP request bodies or query parameters fed through a Webhook or HTTP Request node—an attacker can craft inputs that break out of their intended SQL context and inject arbitrary commands. The MySQL v2 node avoids this flaw by using parameterized queries, which enforce strict separation between SQL structure and data. The severity is elevated because the injected SQL executes with the authenticated credentials of the MySQL connection configured in n8n, potentially granting the attacker read or write access to sensitive database tables.

Business impact

A successful exploitation allows an attacker to bypass database access controls and exfiltrate or modify sensitive data stored in MySQL databases accessible to the n8n instance. In automation-heavy environments, n8n often orchestrates processes that interact with customer data, financial records, or operational databases. SQL injection via a publicly exposed Webhook can enable data theft, unauthorized modification of records, or deletion of critical information. For organizations using n8n in production integrations, this represents a risk to data confidentiality, integrity, and availability. The requirement for an authenticated n8n user (per CVSS) slightly limits the attack surface—the attacker cannot simply create new workflows but must leverage an existing vulnerable workflow or have valid n8n credentials.

Affected systems

Vulnerable versions are n8n 1.x before 1.123.61, all 2.x versions before 2.27.4, and 2.28.0. The MySQL v2 node is not vulnerable. Organizations running n8n in connected environments with externally-accessible workflows are at highest risk, particularly if those workflows accept user input and pass it to MySQL v1 nodes. Air-gapped or internally-only n8n instances face reduced risk unless the attacker has network access and valid n8n credentials.

Exploitability

Exploitation requires network access to the n8n instance and ability to trigger a workflow connected to a vulnerable MySQL v1 node—this is straightforward if the workflow uses a Webhook or HTTP Request node exposed to the internet. The attacker must craft an HTTP request with SQL injection payloads in parameters or body fields that flow through expressions into the executeQuery operation. No complex exploit code is needed; standard SQL injection techniques apply. The CVSS vector (PR:L) indicates the attacker must have a valid n8n user account, though this could be a low-privileged account created by the organization or obtained through phishing or credential compromise. If a public Webhook is misconfigured or documented, the barrier is even lower.

Remediation

Upgrade to n8n 1.123.61 or later for 1.x users, 2.27.4 or later for 2.x users, or 2.28.1 or later if on 2.28.x. The patch removes the unsafe string interpolation and applies parameterized queries to the MySQL v1 node, or the patched versions deprecate/disable the vulnerable operation. As an immediate workaround, replace any vulnerable MySQL v1 nodes with MySQL v2 nodes in existing workflows, reconfigure expressions to avoid user-sourced input where possible, and restrict webhook access to trusted sources via firewall or authentication policies. Review all active workflows to identify those combining external triggers with MySQL v1 operations.

Patch guidance

Apply updates as soon as possible given the high CVSS score and ease of exploitation. Prioritize n8n instances with publicly exposed Webhooks or HTTP Request nodes that feed into MySQL v1 operations. Test patches in a non-production environment first to ensure workflow compatibility. Verify against the official n8n release notes and security advisories for any breaking changes or migration steps related to the MySQL node changes. After patching, audit workflow configurations to confirm that legacy MySQL v1 nodes have been replaced or hardened.

Detection guidance

Monitor n8n logs and MySQL audit logs for suspicious query patterns originating from the n8n service account—watch for UNION-based injection, time-delay payloads, or queries targeting unauthorized tables. Network detection should flag HTTP requests to public n8n Webhooks containing SQL keywords (SELECT, UNION, DROP, INSERT, etc.) in parameters or bodies. Review workflow definitions in n8n for any MySQL v1 nodes accepting expression-based input from external sources. Database monitoring tools can alert on unusual query complexity or unauthorized table access from the n8n user account. Correlation of HTTP request timing with unexpected database queries can reveal injection attempts.

Why prioritize this

A CVSS 8.8 HIGH score reflects the combination of network-accessible attack surface, high impact (confidentiality, integrity, and availability of the database), and relatively low complexity. The legacy MySQL v1 node is a clear security anti-pattern—unsafe interpolation of user input into SQL—that organizations may have overlooked during migration to MySQL v2. Public Webhooks are common in n8n workflows for SaaS integrations and automation, making the vulnerable pattern likely to exist in real deployments. The requirement for authenticated access (PR:L) moderates but does not eliminate urgency. This should be treated as a patch-soon priority in any organization running n8n connected to production databases.

Risk score, explained

The CVSS 3.1 score of 8.8 is HIGH due to: (1) Network-accessible attack vector (AV:N) via externally exposed Webhooks; (2) low attack complexity (AC:L)—standard SQL injection, no special conditions required; (3) low privileges required (PR:L)—attacker must have a valid n8n account, but this is a reasonable assumption in many organizations; (4) high impact across all three confidentiality, integrity, and availability dimensions (C:H, I:H, A:H) because the attacker can read, modify, or delete database records. The scope is unchanged (S:U), meaning the impact is limited to the MySQL database. The score would be higher (CRITICAL) if no authentication were required; the PR:L constraint reflects the fact that internal or malicious n8n users are the primary threat, not unauthenticated internet users.

Frequently asked questions