mediumAgent ThreatFramework Vulnerability

n8n Google Service Account Private Key Leak via JWT Header

First seen Jul 22, 2026 · Updated Jul 22, 2026

n8ncredential-exposurejwtgoogle-service-accountkey-leakworkflow-automationsecrets-managementASI02 · Tool MisuseSurface: Tool LayerPropagation: Single Hop

n8n, a workflow automation platform commonly used to orchestrate AI agent and API integrations, incorrectly embedded the full PEM private key of a Google Service Account inside the 'kid' field of a JWT header instead of a key identifier. Because JWT headers are only Base64-encoded (not encrypted), any system that logged, proxied, or inspected these tokens could recover the private key and impersonate the service account against Google Cloud resources. This is a genuine credential-exposure vulnerability with a clear patch, not a novel agentic-AI attack technique, but it is highly relevant to agent pipelines that rely on n8n for tool/API orchestration.

Technical Analysis

The vulnerability stems from a coding error in n8n's Google Service Account authentication flow, where the full PEM private key was placed into the JWT header's 'kid' field, a field intended only to hold a non-secret key identifier used for key lookup. Since JWT headers are Base64url-encoded rather than encrypted or signed for confidentiality, any component that logs, caches, or forwards the token in transit (proxies, load balancers, application logs, browser devtools, monitoring tools) exposes the raw private key in plaintext-recoverable form. An attacker who captures a single JWT can extract the key and directly impersonate the Google Cloud service account, gaining whatever IAM permissions it holds (e.g., access to Drive, Sheets, BigQuery, Cloud Storage, or other Google APIs n8n workflows commonly integrate with). This crosses a trust boundary from the workflow/automation layer into the identity layer of connected cloud services, effectively turning a logging or observability weakness into full credential compromise for any downstream agent or tool that used that service account.

Affected Systems

n8n; protocols: JWT

Detection Signatures

  • JWT header 'kid' field containing PEM-formatted content beginning with '-----BEGIN PRIVATE KEY-----'
  • Unusually long 'kid' field values (normal kid values are short identifiers, typically <100 chars)
  • Log entries, proxy access logs, or APM traces containing full JWT tokens issued by n8n Google Service Account nodes
  • Unexpected Google Cloud API calls from IPs/service accounts not associated with known n8n instances

Remediation Steps

  1. 1

    Upgrade n8n

    Update to n8n 1.123.64, 2.29.8, 2.30.1, or later, which fixes the JWT header key placement.

  2. 2

    Rotate exposed credentials

    Immediately rotate any Google Service Account keys that were used with a vulnerable n8n version, treating them as compromised.

  3. 3

    Audit logs for exposure

    Review proxy, load balancer, application, and observability logs for JWT headers containing PEM key material and flag any matches for incident response.

  4. 4

    Restrict service account scope

    Apply least-privilege IAM roles to service accounts used in n8n workflows to limit blast radius if a key is compromised.

  5. 5

    Avoid interim use of affected auth

    Until patched, avoid configuring new Google Service Account credentials in n8n or disable existing ones as a temporary mitigation.

CVE / Advisory IDs

CVE-2026-65599GHSA-9r8p-h6cc-6qhm

Industries Most Exposed

Software/SaaSIT/DevOps automationCloud servicesAny industry using n8n for workflow/agent orchestration

Sources

Respond to this threat

Pro subscribers get a full AI-generated incident-response playbook for this threat — detection, containment, eradication, and recovery steps — plus an unlimited AI Threat Advisor for questions about your environment.