CVE-2026-118643 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 stores credential secrets in execution error data when operations fail in the Git, MongoDB Atlas Vector Store, and Google Cloud Storage nodes. Users who can view a workflow's executions but cannot read the credential can recover Git passwords or tokens, MongoDB database passwords, or Google access tokens from that data.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 10/28/2026
The vulnerability identified involves improper handling of sensitive credentials within the n8n automation platform, specifically affecting versions prior to 1.123.85, 2.x before 2.43.5, and 2.44.x before 2.44.1. This flaw manifests when operations fail in nodes that interact with external services such as Git, MongoDB Atlas Vector Store, and Google Cloud Storage. Under normal circumstances, n8n is designed to mask or omit sensitive credential data from execution logs and error messages to prevent accidental exposure. However, due to this implementation defect, the full plaintext values of stored secrets are inadvertently included in the structured error response generated when a node operation encounters an exception. This behavior creates a significant security gap where confidential authentication material becomes visible within the system's operational telemetry.
The technical root cause lies in how the application constructs error payloads for these specific integrations. When a request to Git, MongoDB Atlas Vector Store, or Google Cloud Storage fails, the underlying code path captures the context of the failure and includes associated parameters in the output data structure intended for debugging or user feedback. In this process, the sanitization logic that typically strips out sensitive fields like passwords, API keys, and access tokens is bypassed or not applied correctly to these specific node types. Consequently, the error object returned to the client contains the raw credential values rather than masked placeholders such as asterisks or ellipses. This represents a classic case of information leakage through improper output encoding and insufficient data sanitization during exception handling routines.
The operational impact of this vulnerability is severe for organizations relying on n8n for workflow automation, particularly those with role-based access control models. The primary risk vector involves users who possess the ability to view execution history or logs but lack the permissions required to read the actual credential configurations stored in the system's database. In many enterprise deployments, developers or analysts may have permission to inspect why a workflow failed without having full administrative rights over secret management systems. An attacker with such limited privileges can exploit this flaw by triggering failures in affected nodes and subsequently extracting the plaintext secrets from the resulting error messages. This allows for credential harvesting that bypasses standard access control mechanisms, effectively granting unauthorized users elevated privileges equivalent to those of the service accounts used within the workflows.
This vulnerability aligns closely with CWE-209, which describes the generation of an error message that includes sensitive information useful for an attacker, and CWE-798, concerning the use of hardcoded credentials or improper credential storage in logs. From a threat modeling perspective using the MITRE ATT&CK framework, this behavior facilitates Credential Access techniques such as T1530 Data from Cloud Storage Object Discovery if attackers can access stored execution data, or more directly relates to unauthorized access through insufficiently protected authentication mechanisms. The exposure of Git tokens could lead to repository compromise and supply chain attacks via malicious code injection. Similarly, the leakage of MongoDB Atlas passwords allows for direct database exfiltration or manipulation, while compromised Google Cloud Storage credentials enable unauthorized reading or modification of cloud-hosted data assets.
Mitigation strategies must prioritize immediate version upgrades as the primary defense vector. Organizations running affected versions should upgrade to n8n 1.123.85 or later, 2.43.5 or later for the 2.x branch, and 2.44.1 or later for the 2.44.x series where this issue has been resolved by developers implementing stricter sanitization protocols in error handling paths. In environments where immediate patching is not feasible due to operational constraints, temporary mitigations include restricting access to workflow execution logs so that only users with full administrative privileges can view detailed error outputs. Additionally, rotating the exposed credentials immediately after discovering potential exposure is critical to neutralize any damage caused by prior exploitation attempts. Long-term architectural improvements should involve implementing a centralized secrets management solution that decouples credential storage from application logic and ensures that no sensitive data ever enters execution logs or debug output streams regardless of operation success or failure status.