n8n before 1.123.64, 2.29.8, and 2.30.1 Credential Exposure via JWT Header
- Published
- Last modified
- Where the record stands: published, rejected by its publisher, or superseded by another id.What do these mean? →
- published
- Whether CISA lists it in its Known Exploited Vulnerabilities catalog: proof that attackers are using it.What do these mean? →
- Not listed in CISA KEV
- Fix
- Fixed in 1.123.64, 2.30.1, 2.29.8
- Whether working attack code is public (Exploit-DB, Metasploit, Nuclei or GitHub). Public code makes attacks easier.What do these mean? →
- None on Exploit-DB, Metasploit or GitHub
- Exploitation: none
- Automatable: no
- Technical impact: partial
Summary
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.
Timeline
- CVE published
- CISA SSVC assessment
Exploitation: none · Automatable: no · Technical impact: partial
- Record last updated
Affected versions
- n8n-io n8n
fixed in 1.123.64
- n8n-io n8n
From 2.30.0 · fixed in 2.30.1
- n8n-io n8n
From 2.0.0-rc.0 · fixed in 2.29.8
- n8nnpm
fixed in 1.123.64
- n8nnpm
From 2.30.0 · fixed in 2.30.1
- n8nnpm
From 2.0.0-rc.0 · fixed in 2.29.8