n8n OAuth Refresh Token Resource Substitution Leading to Cross-Workflow Access

Technical Analysis

The n8n OAuth token endpoint correctly scoped the initial access token to the resource a user approved, but the refresh flow only validated that the requested resource was a registered target, not that it matched the resource from the original grant. An attacker who registers an OAuth client and gets a legitimate user to approve access to one known protected workflow can later request a refresh token for a different protected resource URL (e.g., another MCP Trigger or webhook workflow) that the same user is authorized to execute, effectively laundering consent across resources. This crosses agent/automation boundaries because n8n workflows frequently act as tool-executing agents (including MCP servers), so an unbound refresh token can grant an external OAuth client execution rights over unrelated automations without renewed user consent. Exploitation requires social engineering (getting one approval) plus knowledge of a second resource's URL, making it a targeted but plausible attack against multi-tenant or multi-workflow n8n deployments.

Affected Systems

n8n; protocols: OAuth 2.0, MCP

Detection Signatures

• Refresh token requests specifying a 'resource' parameter that differs from the resource in the original authorization grant
• OAuth client refresh calls targeting multiple distinct n8n workflow/resource URLs shortly after a single consent event
• Unexpected access to MCP Trigger, webhook, or form workflows from OAuth clients not explicitly approved for those resources
• Audit logs showing token refresh activity against protected resources with no corresponding initial consent record

Remediation Steps

1. 1

   Upgrade n8n

   Update to n8n 2.38.1, 2.37.7, or later where refresh tokens are cryptographically bound to the originally granted resource.

2. 2

   Force re-authorization

   Revoke all existing OAuth refresh tokens and require users to re-approve OAuth clients post-upgrade, since pre-patch tokens lack resource binding.

3. 3

   Audit OAuth clients

   Review all registered OAuth clients connected to the n8n instance and remove any unrecognized or unused clients.

4. 4

   Restrict exposure

   Limit n8n instance access to trusted users and disable unused MCP Trigger, webhook, or form workflows protected by the OAuth server.

5. 5

   Monitor token refresh activity

   Add logging/alerting for refresh token requests that reference a resource different from the one in the client's original consent grant.