CVE-2026-65599: n8n GCP service account key leaks

Q: Is CVE-2026-65599 actively exploited?

No confirmed active exploitation of CVE-2026-65599 has been reported, but organizations should still patch proactively.

Q: How to fix CVE-2026-65599?

1) Patch n8n to 1.123.64, 2.29.8, or 2.30.1 immediately in all environments using Google Service Account credentials. 2) Treat every service account key ever used with an affected n8n version as potentially compromised — rotate the private key in GCP IAM regardless of whether you've observed exposure. 3) Scope service accounts to least privilege so a leaked key has minimal blast radius going forward. 4) Search existing logs, APM/tracing tools, and error-reporting systems for any stored JWTs from n8n's Google Service Account flow and purge them. 5) Enable GCP Cloud Audit Logs on the affected service account and review for anomalous API calls predating the patch. 6) Restrict who/what can read n8n application logs, since log access is the primary exploitation vector here.

Q: What systems are affected by CVE-2026-65599?

This vulnerability affects the following AI/ML architecture patterns: agent frameworks, workflow automation pipelines, cloud service integration layers.

Q: What is the CVSS score for CVE-2026-65599?

No CVSS score has been assigned yet.

CISO Take

n8n mishandled Google Service Account credentials by placing the full PEM private key inside the JWT header's `kid` field, a field meant only to hold a key identifier and encoded in Base64 rather than encrypted — meaning anyone who can read a logged or inspected JWT can trivially recover the raw private key. This matters because n8n is a widely deployed AI agent/workflow automation platform with 16 tracked downstream dependents and an OpenSSF Scorecard of just 6.6/10, and any organization piping Google Cloud actions through n8n agent workflows is exposed if that key surfaces in application logs, observability tooling, or support tickets. There is no CVSS score, EPSS data, CISA KEV listing, or public exploit/scanner for this issue yet, so opportunistic mass exploitation is unlikely, but the blast radius of a leaked service account key — full impersonation and access to whatever GCP resources it's scoped to — is high in any single affected environment. Patch to n8n 1.123.64, 2.29.8, or 2.30.1 immediately if you use Google Service Account credentials, and treat any previously issued keys as compromised: rotate them in GCP IAM and audit logs/traces for exposed JWTs regardless of patch status, since rotation is the only way to invalidate keys that may already have leaked.

Sources: NVD GitHub Advisory ATLAS OpenSSF vulncheck.com

What is the risk?

No CVSS vector, EPSS score, or CISA KEV listing exists for this CVE, and there is no public exploit or Nuclei template, so opportunistic internet-wide exploitation risk is currently low. However, the vulnerability class (CWE-312, cleartext storage of sensitive information in a supposedly non-sensitive JWT field) is severe in impact once triggered: a leaked PEM private key grants full impersonation of the associated Google Cloud service account, with no reliance on the JWT's signature or expiry to limit re-use. Exploitability is opportunistic rather than remote — an attacker needs read access to logs, traces, error reporting, or any system that captures the JWT, which narrows the realistic attacker population but does not eliminate insider, supply-chain, or logging-infrastructure-compromise scenarios. Overall risk should be scored as high-impact/low-likelihood at present, escalating quickly for any organization with centralized or third-party log aggregation.

How does the attack unfold?

Log/Trace Access

Adversary gains read access to logging, observability, or tracing infrastructure that captures n8n's outbound JWTs for Google Cloud API calls.

AML.T0055

Credential Extraction

Adversary Base64-decodes the JWT header and recovers the full PEM private key mistakenly stored in the `kid` field.

AML.T0055

Service Account Impersonation

Adversary uses the recovered private key to mint valid, self-signed JWTs and authenticate directly to Google's OAuth2 token endpoint as the service account.

AML.T0091.000

Cloud Resource Impact

Adversary accesses, exfiltrates, or modifies any Google Cloud resource (storage, BigQuery, Vertex AI, etc.) the impersonated service account is authorized to use.

Log/Trace Access

Adversary gains read access to logging, observability, or tracing infrastructure that captures n8n's outbound JWTs for Google Cloud API calls.

AML.T0055

Credential Extraction

Adversary Base64-decodes the JWT header and recovers the full PEM private key mistakenly stored in the `kid` field.

AML.T0055

Service Account Impersonation

Adversary uses the recovered private key to mint valid, self-signed JWTs and authenticate directly to Google's OAuth2 token endpoint as the service account.

AML.T0091.000

Cloud Resource Impact

Adversary accesses, exfiltrates, or modifies any Google Cloud resource (storage, BigQuery, Vertex AI, etc.) the impersonated service account is authorized to use.

What systems are affected?

Package	Ecosystem	Vulnerable Range	Patched
n8n	npm	< 1.123.64	`1.123.64`
204.1K OpenSSF 6.6 16 dependents Pushed 7d ago 53% patched ~5d to patch Full package profile →

Do you use n8n? You're affected.

How severe is it?

CVSS 3.1

N/A

EPSS

0.2%

chance of exploitation in 30 days

Higher than 5% of all CVEs

Source: EPSS v3 — FIRST.org

Exploitation Status

No known exploitation

Sophistication

Moderate

What should I do?

1 step

1) Patch n8n to 1.123.64, 2.29.8, or 2.30.1 immediately in all environments using Google Service Account credentials. 2) Treat every service account key ever used with an affected n8n version as potentially compromised — rotate the private key in GCP IAM regardless of whether you've observed exposure. 3) Scope service accounts to least privilege so a leaked key has minimal blast radius going forward. 4) Search existing logs, APM/tracing tools, and error-reporting systems for any stored JWTs from n8n's Google Service Account flow and purge them. 5) Enable GCP Cloud Audit Logs on the affected service account and review for anomalous API calls predating the patch. 6) Restrict who/what can read n8n application logs, since log access is the primary exploitation vector here.

What does CISA's SSVC say?

Decision Track

Exploitation none

Automatable No

Technical Impact partial

Source: CISA Vulnrichment (SSVC v2.0). Decision based on the CISA Coordinator decision tree.

How is it classified?

Data Leakage Auth Bypass Agent API AML.T0055 - Unsecured Credentials AML.T0083 - Credentials from AI Agent Configuration AML.T0091.000 - Application Access Token

Which compliance frameworks are affected?

This CVE is relevant to:

EU AI Act

Article 15 - Accuracy, Robustness and Cybersecurity

NIST AI RMF

MEASURE 2.7 - AI system security and resilience

OWASP LLM Top 10

LLM02 - Sensitive Information Disclosure

Frequently Asked Questions

What is CVE-2026-65599?

n8n mishandled Google Service Account credentials by placing the full PEM private key inside the JWT header's `kid` field, a field meant only to hold a key identifier and encoded in Base64 rather than encrypted — meaning anyone who can read a logged or inspected JWT can trivially recover the raw private key. This matters because n8n is a widely deployed AI agent/workflow automation platform with 16 tracked downstream dependents and an OpenSSF Scorecard of just 6.6/10, and any organization piping Google Cloud actions through n8n agent workflows is exposed if that key surfaces in application logs, observability tooling, or support tickets. There is no CVSS score, EPSS data, CISA KEV listing, or public exploit/scanner for this issue yet, so opportunistic mass exploitation is unlikely, but the blast radius of a leaked service account key — full impersonation and access to whatever GCP resources it's scoped to — is high in any single affected environment. Patch to n8n 1.123.64, 2.29.8, or 2.30.1 immediately if you use Google Service Account credentials, and treat any previously issued keys as compromised: rotate them in GCP IAM and audit logs/traces for exposed JWTs regardless of patch status, since rotation is the only way to invalidate keys that may already have leaked.

Is CVE-2026-65599 actively exploited?

No confirmed active exploitation of CVE-2026-65599 has been reported, but organizations should still patch proactively.

How to fix CVE-2026-65599?

1) Patch n8n to 1.123.64, 2.29.8, or 2.30.1 immediately in all environments using Google Service Account credentials. 2) Treat every service account key ever used with an affected n8n version as potentially compromised — rotate the private key in GCP IAM regardless of whether you've observed exposure. 3) Scope service accounts to least privilege so a leaked key has minimal blast radius going forward. 4) Search existing logs, APM/tracing tools, and error-reporting systems for any stored JWTs from n8n's Google Service Account flow and purge them. 5) Enable GCP Cloud Audit Logs on the affected service account and review for anomalous API calls predating the patch. 6) Restrict who/what can read n8n application logs, since log access is the primary exploitation vector here.

What systems are affected by CVE-2026-65599?

This vulnerability affects the following AI/ML architecture patterns: agent frameworks, workflow automation pipelines, cloud service integration layers.

What is the CVSS score for CVE-2026-65599?

No CVSS score has been assigned yet.

What is the AI security impact?

Affected AI Architectures

agent frameworksworkflow automation pipelinescloud service integration layers

MITRE ATLAS Techniques

AML.T0055 Unsecured Credentials

AML.T0083 Credentials from AI Agent Configuration

AML.T0091.000 Application Access Token

Compliance Controls Affected

EU AI Act: Article 15

NIST AI RMF: MEASURE 2.7

OWASP LLM Top 10: LLM02

What are the technical details?

Original Advisory

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.

Exploitation Scenario

An organization runs n8n to orchestrate an AI agent workflow that calls Google Cloud APIs (e.g., Vertex AI for inference, BigQuery for data retrieval) using a Google Service Account credential. n8n's centralized logging platform, or a third-party observability vendor with log access, captures the outbound JWT as part of standard request logging. An attacker who compromises that logging pipeline — or an insider with log-viewing permissions — copies the JWT, Base64-decodes the header, and extracts the full PEM private key that was mistakenly embedded in the `kid` field. Using that key, the attacker mints their own valid, signed JWTs to impersonate the service account directly against Google's OAuth2 token endpoint, bypassing n8n entirely, and then uses the resulting access token to read, exfiltrate, or modify any GCP resource (storage buckets, BigQuery datasets, Vertex AI models) the account is authorized for.

Weaknesses (CWE)

CWE-312 Cleartext Storage of Sensitive Information Primary CWE-312 Cleartext Storage of Sensitive Information Primary CWE-312 Cleartext Storage of Sensitive Information

CWE-312 — Cleartext Storage of Sensitive Information: The product stores sensitive information in cleartext within a resource that might be accessible to another control sphere.

[Implementation, System Configuration, Operation] When storing data in the cloud (e.g., S3 buckets, Azure blobs, Google Cloud Storage, etc.), use the provider's controls to encrypt the data at rest. [REF-1297] [REF-1299] [REF-1301]
[Implementation, System Configuration, Operation] In some systems/environments such as cloud, the use of "double encryption" (at both the software and hardware layer) might be required, and the developer might be solely responsible for both layers, instead of shared responsibility with the administrator of the broader system/environment.

Source: MITRE CWE corpus.