CVE-2026-59209: n8n: Shared Credential Header Leak via HTTP Request Pagination Expression

When an HTTP Header Auth credential is applied to a paginated request, the secret sits in $request.headers while pagination expressions are evaluated. A user who can edit expressions in that workflow can read it there.

The attacker is an authenticated member with use-only editor access to a shared workflow that uses the credential. They write a pagination expression that copies the header value into item data. A later HTTP Request node, pointed at a server they control, sends the item data out.

This bypasses the credential's "Allowed HTTP Request Domains" restriction. That check guards the credential's own request path, but here the secret leaves as ordinary item data, not as a credential-bearing request. The member never sees the secret in the credentials UI, and now has it.

With the secret, the attacker can call the target API with its full permissions. The advisory says the flaw applies only when N8N_EXPRESSION_ENGINE=vm is set and paginated HTTP Request workflows using shared credentials are reachable by non-owner users.

The n8n npm package before 1.123.61, from 2.0.0-rc.0 before 2.27.4, and 2.28.0 before 2.28.1. It matters on instances that set N8N_EXPRESSION_ENGINE=vm and share workflows that use HTTP Request nodes with pagination and an HTTP Header Auth credential.

npm ls n8n

For Docker, check the image tag and the environment for N8N_EXPRESSION_ENGINE.

Upgrade to n8n 1.123.61, 2.27.4 or 2.28.1, or later on your release line.

npm install [email protected]

Temporary mitigations from the advisory, which do not fully remove the risk:

• Restrict workflow sharing to fully trusted users.
• Do not give use-only credential access to untrusted users on workflows with paginated HTTP Request nodes.

Rotate Header Auth secrets that untrusted members could reach.

Inspect shared workflows for HTTP Request nodes whose pagination expressions reference $request, especially $request.headers, or that write it into item data. Look for later HTTP Request nodes sending to hosts outside your normal set. Check egress logs from the n8n host for unexpected destinations after runs of those workflows.

Impact

An authenticated member with use-only editor access to a shared workflow could read credential-populated headers exposed via the $request object inside an HTTP Request node's pagination expression. When an HTTP Header Auth credential is applied to a paginated request, the secret is present in $request.headers when pagination expressions are evaluated. A user-controlled expression could read that secret, copy it into item data, and exfiltrate it through a later HTTP Request node, bypassing credential domain restrictions, since the secret leaves via item data rather than the credential's own request mechanism.

This issue only affects instances with N8N_EXPRESSION_ENGINE=vm set, where paginated HTTP Request workflows using shared credentials are accessible to non-owner users.

Patches

The issue has been fixed in n8n versions 1.123.61, 2.27.4, and 2.28.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:

• Restrict workflow sharing to fully trusted users only.
• Avoid sharing credentials with use-only access to untrusted users on workflows that use HTTP Request nodes with pagination enabled.

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