CVE-2026-77076 in n8n
Summary
by MITRE • 08/20/2026
n8n versions before 1.123.69, 2.33.4, and 2.34.1 contain an information disclosure vulnerability in the GraphQL node. When a GraphQL request fails at the connection level, the node re-throws the underlying HTTP client error unchanged instead of wrapping it in n8n's standard error type. That error contains the live request's headers, including a decrypted credential secret, which the execution engine persists verbatim. Any authenticated user able to read the resulting execution can retrieve the decrypted credential secret from the stored run data.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 08/20/2026
The vulnerability identified in n8n versions prior to 1.123.69, 2.33.4, and 2.34.1 represents a critical information disclosure flaw within the GraphQL node implementation. This issue stems from improper error handling mechanisms that fail to sanitize sensitive data before persistence. Specifically, when a GraphQL request encounters a failure at the connection level rather than during query execution or validation, the system does not wrap the resulting exception in n8n's standard internal error type. Instead, it re-throws the underlying HTTP client error object directly into the execution context without modification. This design oversight allows raw network-level errors to propagate through the workflow engine and eventually get serialized for storage alongside other execution metadata.
The technical consequence of this architectural flaw is significant because the unmodified HTTP client error object contains comprehensive details about the failed request, including full header information. Among these headers are authentication tokens or credentials that were decrypted by n8n's credential management system to facilitate the connection attempt. Since the workflow engine persists the entire execution data structure verbatim for debugging and audit purposes, this sensitive plaintext secret is written directly into the database records associated with the failed run. Consequently, any user account possessing read access to the specific workflow or its historical executions can query these stored logs and extract the decrypted credential secrets without needing elevated privileges or exploiting a separate authentication bypass.
From an operational impact perspective, this vulnerability effectively compromises the confidentiality of all credentials configured within n8n workflows that utilize the GraphQL node for external API interactions. Attackers with authenticated access to the platform can systematically scan execution histories to harvest these plaintext secrets. Once obtained, these credentials allow unauthorized access to downstream services and APIs connected via n8n, potentially leading to data exfiltration, lateral movement within integrated systems, or further exploitation of dependent applications. The risk is exacerbated by the fact that many organizations treat workflow automation platforms as central hubs for sensitive integrations, making the leakage of API keys, OAuth tokens, or basic authentication headers particularly damaging to overall security posture.
This vulnerability aligns with CWE-209, which describes the generation of error messages containing sensitive information, and CWE-532, concerning exposure of log files to unauthorized users. In terms of adversary behavior, it maps to ATT&CK technique T1530, Data from Cloud Storage Objects, as attackers would retrieve stored execution data to harvest credentials. It also relates to T1608, Stage Capabilities, if the harvested secrets are used to deploy further malicious activities within connected environments. The core issue is a failure in secure coding practices regarding error handling and data sanitization before persistence.
To mitigate this vulnerability, organizations must immediately upgrade n8n to version 1.123.69 or later for the v1 branch, version 2.33.4 or later for the v2 stable branch, or version 2.34.1 or later for the latest release line. These updates include patches that ensure HTTP client errors are properly wrapped and sanitized before being persisted in execution logs, thereby preventing the leakage of decrypted credentials. In addition to upgrading, administrators should rotate all API keys and secrets associated with workflows that previously used the GraphQL node, as previous executions may have already leaked sensitive data into stored logs. Implementing strict access controls on workflow history viewing can also limit exposure until patches are applied, ensuring that only essential personnel can review execution details where such errors might still exist in older instances.