Impact
When a GraphQL node's request failed at the connection level, the node re-threw the underlying HTTP client error unchanged instead of wrapping it in n8n's standard error type. That error carried the live request's headers, including a decrypted credential secret, and the execution engine persisted it verbatim. Any authenticated user able to read the resulting execution could retrieve the decrypted secret from the stored run data.
Patches
The issue has been fixed in n8n versions 1.123.69, 2.33.4, and 2.34.1. Users should upgrade to one of these versions or later to remediate the vulnerability.
Workarounds
If upgrading is not immediately possible, administrators should consider the following temporary mitigations:
- Restrict n8n instance access to fully trusted users only.
- Disable the GraphQL node by adding
n8n-nodes-base.graphql to the NODES_EXCLUDE environment variable.
- Audit existing execution records for unexpected credential values in GraphQL node error data and rotate any affected credentials.
These workarounds do not fully remediate the risk and should only be used as short-term mitigation measures.
Impact
When a GraphQL node's request failed at the connection level, the node re-threw the underlying HTTP client error unchanged instead of wrapping it in n8n's standard error type. That error carried the live request's headers, including a decrypted credential secret, and the execution engine persisted it verbatim. Any authenticated user able to read the resulting execution could retrieve the decrypted secret from the stored run data.
Patches
The issue has been fixed in n8n versions 1.123.69, 2.33.4, and 2.34.1. Users should upgrade to one of these versions or later to remediate the vulnerability.
Workarounds
If upgrading is not immediately possible, administrators should consider the following temporary mitigations:
n8n-nodes-base.graphqlto theNODES_EXCLUDEenvironment variable.These workarounds do not fully remediate the risk and should only be used as short-term mitigation measures.