CVE-2026-65599 in n8n
Summary
by MITRE • 07/22/2026
n8n versions before 1.123.64, 2.29.8, and 2.30.1 contain a credential exposure vulnerability: when configured with a Google Service Account key, the full PEM private key was mistakenly placed in the JWT header's kid field (intended only for a key identifier). Because JWT headers are Base64-encoded rather than encrypted, the private key could be recovered by anything that logged or inspected the JWT. An attacker who obtained the key could impersonate the service account and access or modify any Google Cloud resource it was authorized to use. Only instances using Google Service Account credentials are affected.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 07/22/2026
This vulnerability represents a critical credential exposure flaw in n8n workflow automation software affecting versions prior to 1.123.64, 2.29.8, and 2.30.1. The issue stems from improper handling of Google Service Account authentication where the complete PEM private key was incorrectly placed within the JSON Web Token (JWT) header's kid field during authentication processes. This misconfiguration violates fundamental security principles as the kid field is specifically designed to contain only a key identifier rather than the actual cryptographic material. The vulnerability maps directly to CWE-200, which addresses improper exposure of sensitive information, and aligns with ATT&CK technique T1552.001 for unsecured credentials storage.
The technical implementation flaw occurs during JWT generation when n8n incorrectly populates the kid field in the JWT header with the entire private key instead of a simple identifier string. Since JWT headers are Base64-encoded rather than encrypted, any system component that logs or inspects these tokens inadvertently exposes the complete private key material. This exposure creates a significant attack surface as the Base64 encoding is easily reversible and does not provide cryptographic protection. The vulnerability essentially transforms a secure authentication process into an insecure credential disclosure mechanism where sensitive information flows through standard logging mechanisms without proper sanitization.
The operational impact of this vulnerability is severe and potentially catastrophic for organizations relying on Google Cloud services through n8n workflows. An attacker who gains access to any system that logs JWT tokens can immediately recover the complete private key and subsequently impersonate the service account with full privileges over all Google Cloud resources the account was authorized to access. This includes but is not limited to data read/write operations, resource management capabilities, and potential lateral movement within cloud environments. The attack vector is particularly dangerous because it leverages legitimate logging practices that are essential for system monitoring and debugging, making detection more challenging.
Organizations should immediately implement mitigation strategies including updating to the patched versions mentioned in the advisory, implementing comprehensive token sanitization protocols, and reviewing all logging configurations to ensure JWT headers are not logged or inspected. Security teams must also conduct thorough audits of their n8n deployments to identify any instances where service account credentials might have been exposed through log files or monitoring systems. The remediation process should include key rotation for all affected Google Service Accounts and implementation of automated monitoring to detect unauthorized access patterns that might indicate credential compromise. This vulnerability highlights the importance of proper cryptographic implementation practices and demonstrates how seemingly minor configuration errors can result in significant security breaches affecting cloud infrastructure access and data protection.