CVE-2026-118647 in n8n
Summary
by MITRE • 10/28/2026
n8n before 1.123.85, 2.x before 2.43.5, and 2.44.x before 2.44.1 saves the SeaTable Trigger node's API token in error execution data, because failed poll requests store raw request headers. Users who can view workflow executions but cannot read the credential can recover the token and access the connected SeaTable base.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 10/28/2026
The vulnerability identified involves a critical information disclosure flaw within n8n versions prior to 1.123.85, 2.x before 2.43.5, and 2.44.x before 2.44.1. This issue specifically affects the SeaTable Trigger node, which is designed to monitor changes in a SeaTable base via API polling mechanisms. The core technical flaw lies in how n8n handles error states during these automated workflows. When a poll request fails due to network issues, authentication errors, or server-side problems, the system captures detailed execution data for debugging and logging purposes. In this specific implementation, the raw HTTP response headers are included in the stored error logs without adequate sanitization of sensitive fields. Since API tokens are frequently transmitted via authorization headers such as Authorization: Bearer <token>, these credentials become embedded directly within the unencrypted or insufficiently protected error execution data structures.
This architectural oversight creates a significant privilege escalation vector for users who possess view access to workflow executions but lack explicit permissions to read stored credentials from the vault. In many n8n deployments, particularly in team environments, there is often a distinction between operators who can monitor and debug workflows and administrators or security officers who manage credential storage. An attacker with lower-level privileges can navigate to the execution history of any affected workflow that utilizes the SeaTable Trigger node. By inspecting past failed executions, they can extract the raw headers containing the plaintext API token associated with the connected SeaTable instance. This effectively bypasses the intended access control mechanisms designed to protect sensitive authentication material.
The operational impact of this vulnerability is severe, as it allows unauthorized actors to gain full read and potentially write access to the linked SeaTable base depending on the permissions granted to that specific API token. Once the token is recovered, an attacker can interact with the SeaTable API independently of n8n, accessing sensitive business data stored within the tables. This constitutes a direct breach of confidentiality for any organizational data hosted in SeaTable and integrated into n8n workflows. Furthermore, if the API token possesses elevated permissions, it could lead to data manipulation or deletion, impacting data integrity as well. The persistence of this risk depends on how long error logs are retained; even after immediate remediation, previously generated execution records remain a source of credential leakage unless manually purged or encrypted with stronger controls that prevent header exposure in log outputs.
From a classification perspective, this vulnerability aligns with CWE-209: Generation of Error Message Containing Sensitive Information and CWE-798: Use of Hard-coded Credentials if the token was statically configured, though it primarily represents an improper handling of sensitive data during error processing. In terms of adversary tactics, this maps to ATT&CK technique T1530: Data from Cloud Storage Object or Database, where attackers exfiltrate data by accessing stored credentials found in application logs or execution traces. It also relates to T1608: Stage Capabilities via Implant Download if the token is used to further compromise systems, but primarily it serves as a credential harvesting vector through log analysis.
Mitigation strategies must address both immediate remediation and long-term architectural improvements. The primary defense is upgrading n8n to version 1.123.85 or later for the legacy branch, or versions 2.43.5 and above for major release branches, where this specific logging behavior has been corrected to exclude sensitive headers from error execution data. For organizations unable to upgrade immediately due to compatibility constraints, a temporary workaround involves restricting access to workflow execution history so that only users with full administrative privileges can view detailed logs containing potential credential leaks. Additionally, implementing strict log rotation policies and purging old execution records reduces the window of exposure for previously generated vulnerable logs. Security teams should also audit their n8n configurations to ensure that API tokens are scoped with minimal necessary permissions, limiting the blast radius if a token is compromised through this or other vectors. Regular audits of workflow executions and integration points are essential to maintain visibility over how sensitive data flows through automation pipelines.