CVE-2026-65599: n8n: Google Service Account Private Key Exposed in JWT Header

When n8n signs a JWT for a Google service account, the header should hold a key identifier in kid. Affected versions wrote the whole PEM private key there instead. A JWT header is just Base64 text, not encrypted. Anyone who can see the token can decode the header and read the key.

That covers every place the token could be logged or inspected: reverse proxies, load balancers, application logs, tracing tools, or a network position that can see the request. The advisory scopes the risk to instances that use Google Service Account credentials.

With the private key, an attacker can sign tokens as the service account. They can then access or modify any Google Cloud resource that account is allowed to use, from any machine, without touching n8n. The CVSS 4.0 vector shows the attack needs an existing foothold (AT:P) and high privileges on n8n, but a high impact on subsequent systems, which matches a leaked cloud key. The weakness class is cleartext storage of sensitive information (CWE-312).

Upgrading stops new leaks. It does not unleak a key that is already sitting in old logs.

The npm package n8n below 1.123.64 on the 1.x line, >= 2.0.0-rc.0, < 2.29.8, and 2.30.0. Only instances that use a Google Service Account credential are affected. Other Google credential types such as OAuth are not named in the advisory.

npm ls n8n

Then list your n8n credentials of the Google Service Account type, and the Google Cloud service accounts they map to.

Upgrade n8n to 1.123.64, 2.29.8 or 2.30.1, or later, matching your release line.

Then deal with the keys, as the advisory advises:

• Rotate any Google Service Account keys that were used with an affected n8n version.
• Review proxy, load balancer and application logs for JWT headers that may hold key material. Treat any key found there as compromised.

If you cannot upgrade yet, avoid Google Service Account credentials until you do. The advisory says these steps do not fully remediate the risk.

Search proxy, load balancer, API gateway and application logs for JWTs sent by n8n whose Base64 header decodes to a kid value starting with -----BEGIN PRIVATE KEY----- or similar PEM text. A very long first JWT segment is a hint. Check log retention too, since old logs may be copied to external stores.

On the Google Cloud side, review audit logs for the service account for calls from addresses that are not your n8n host, and list the keys that exist on the account for any you did not create. Delete exposed keys and issue new ones.

Impact

When n8n was configured with a Google Service Account key, the full PEM private key was mistakenly placed in the JWT header's kid field (which should only have held a key identifier). Since JWT headers were Base64-encoded rather than encrypted, the 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.

Patches

The issue has been fixed in n8n versions 1.123.64, 2.29.8, and 2.30.1. Users should upgrade to one of these versions or later to remediate the vulnerability.

Workarounds

If upgrading is not immediately possible, administrators should consider the following temporary mitigations:

• Avoid using Google Service Account credentials until the instance is patched.
• Rotate any Google Service Account keys that may have been used with an affected n8n version.
• Review proxy, load balancer, and application logs for JWT headers that may contain exposed key material and treat any such keys as compromised.

These workarounds do not fully remediate the risk and should only be used as short-term mitigation measures.