EUVD-2026-47643
GHSA-9r8p-h6cc-6qhm
Severity by source
CVSS:4.0/AV:N/AC:L/AT:P/PR:H/UI:N/VC:L/VI:N/VA:N/SC:H/SI:L/SA:L/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X
PR:H because log or traffic access is required; S:C and C:H reflect full private key disclosure enabling GCP service account impersonation; I:L for indirect modification potential via impersonation.
Primary rating from Vendor (VulnCheck).
CVSS VectorVendor: VulnCheck
Lifecycle Timeline
2DescriptionCVE.org
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.
AnalysisAI
Credential exposure in n8n workflow automation platform leaks full Google Service Account PEM private keys into the JWT header's kid field, where they are trivially recoverable via Base64 decoding. Affected versions span both the 1.x line (before 1.123.64) and the 2.x line (before 2.29.8 and 2.30.1), but only deployments configured with Google Service Account credentials are at risk. An attacker who captures these JWTs from logs, network traffic, or monitoring systems can extract the raw private key and fully impersonate the service account against any Google Cloud resource it is authorized to access. No public exploit code has been identified at time of analysis, and no confirmed active exploitation is recorded in CISA KEV.
Technical ContextAI
n8n is an open-source, self-hostable workflow automation platform (CPE: cpe:2.3:a:n8n-io:n8n) that supports Google Cloud integrations via Service Account credentials. Google Service Accounts authenticate using RSA private keys in PEM format. The vulnerable code path incorrectly populated the JWT kid (Key ID) header parameter with the full PEM private key material rather than an opaque key identifier string as specified by RFC 7515. Because JWT headers are only Base64url-encoded - not encrypted or integrity-protected against observers - any system that logs or inspects the JWT header can trivially recover the raw private key by decoding the kid field. CWE-312 (Cleartext Storage of Sensitive Information) directly describes this root cause: sensitive key material was placed in a transmission field that provides no confidentiality guarantees. The bug likely arose from passing the key object itself to a field that expected a key reference string, a common developer error at the boundary between cryptographic key management and JWT construction libraries.
RemediationAI
Upgrade n8n to version 1.123.64 or later for 1.x deployments, or to 2.29.8 or 2.30.1 or later for 2.x deployments; these versions are confirmed as patched releases per the vendor security advisory at https://github.com/n8n-io/n8n/security/advisories/GHSA-9r8p-h6cc-6qhm. After upgrading, treat all Google Service Account keys that were in use during the affected period as compromised: immediately rotate the key in Google Cloud IAM Console, audit Google Cloud Audit Logs for any API calls made under the service account during the exposure window, and revoke the old key. As a compensating control before patching, restrict filesystem and platform access to n8n application logs, configure log aggregation systems (Splunk, ELK, Datadog) to redact JWT Authorization headers, and limit network visibility of traffic between n8n and Google APIs - note that these controls reduce exposure but do not eliminate the key from existing stored logs and do not fix the underlying bug.
n8n workflow automation (through 1.121.2) allows authenticated users to execute arbitrary code via the n8n service, with
n8n workflow automation (1.65.0 to 1.121.0) allows unauthenticated file access through form-based workflows. A critical
n8n has a fifth critical RCE vulnerability (CVSS 9.9) in the Expression evaluator, enabling code execution through craft
A prototype pollution vulnerability in the XML and GSuiteAdmin nodes of n8n workflow automation platform allows authenti
An authenticated user with workflow creation or modification privileges in n8n workflow automation platform can exploit
n8n-workflows Main Commit ee25413 allows attackers to execute a directory traversal via the download_workflow function w
Authenticated n8n users can hijack administrator accounts when LDAP authentication is enabled by manipulating their LDAP
The n8n package 0.218.0 for Node.js allows Escalation of Privileges. Rated high severity (CVSS 8.8), this vulnerability
SQL injection in n8n's Data Table Get node allows authenticated users with workflow modification permissions to execute
Authenticated users can exploit string formatting and exception handling in n8n's Python task executor to escape sandbox
n8n workflow automation platform Community Edition contains an authorization bypass vulnerability allowing authenticated
The n8n package 0.218.0 for Node.js allows Information Disclosure. Rated high severity (CVSS 7.5), this vulnerability is
Same weakness CWE-312 – Cleartext Storage of Sensitive Information
View allSame technique Information Disclosure
View allShare
External POC / Exploit Code
Leaving vuln.today