Summary
n8n fails to enforce the "Allowed HTTP Request Domains" restriction for HTTP-based credentials when used in the GraphQL node, allowing credential misuse.
An authenticated user who can create or edit workflows may direct requests to a server they control, potentially exfiltrating restricted credentials whenever they are shared and domain-limited.
n8n fails to enforce the "Allowed HTTP Request Domains" restriction for HTTP-based credentials when used in the GraphQL node, allowing credential misuse.
An authenticated user who can create or edit workflows may direct requests to a server they control, potentially exfiltrating restricted credentials whenever they are shared and domain-limited.
Affected context
The vulnerability appears in n8n workflow configurations that:
- Use HTTP-based credentials (Header, Basic, Query, OAuth) with "Allowed HTTP Request Domains" restrictions
- Expose those credentials to non-owner users (e.g., shared credentials, team environments)
- Utilize the GraphQL node, which does not honor the domain restriction unlike the HTTP Request node
In such setups, domain-restricted credentials are expected to only be used with specific hosts, but GraphQL node calls bypass this constraint.
The vulnerability appears in n8n workflow configurations that:
- Use HTTP-based credentials (Header, Basic, Query, OAuth) with "Allowed HTTP Request Domains" restrictions
- Expose those credentials to non-owner users (e.g., shared credentials, team environments)
- Utilize the GraphQL node, which does not honor the domain restriction unlike the HTTP Request node
In such setups, domain-restricted credentials are expected to only be used with specific hosts, but GraphQL node calls bypass this constraint.
Exploit preconditions
- Attack surface: n8n workflow editor and execution environment
- Required access: An authenticated account capable of creating or editing workflows using shared HTTP-based credentials
- Trigger point: Configuring a GraphQL node endpoint to point to an attacker-controlled server and binding restricted credentials to that node
- Why exploitation is possible: The authorization logic for "Allowed HTTP Request Domains" is not applied to GraphQL node requests, allowing credentials to be sent to arbitrary domains despite configured limits
- Attack surface: n8n workflow editor and execution environment
- Required access: An authenticated account capable of creating or editing workflows using shared HTTP-based credentials
- Trigger point: Configuring a GraphQL node endpoint to point to an attacker-controlled server and binding restricted credentials to that node
- Why exploitation is possible: The authorization logic for "Allowed HTTP Request Domains" is not applied to GraphQL node requests, allowing credentials to be sent to arbitrary domains despite configured limits
Why this happens
This issue stems from inconsistent enforcement of authorization constraints across different workflow nodes.
The "Allowed HTTP Request Domains" control is applied to the HTTP Request node but omitted from the GraphQL node, creating a gap where credentials can be used outside their intended scope.
Conceptually, this maps to CWE-863: Incorrect Authorization, where access control rules for resource usage (here, credential-bound domains) are not uniformly applied in all code paths that consume those credentials.
This issue stems from inconsistent enforcement of authorization constraints across different workflow nodes.
The "Allowed HTTP Request Domains" control is applied to the HTTP Request node but omitted from the GraphQL node, creating a gap where credentials can be used outside their intended scope.
Conceptually, this maps to CWE-863: Incorrect Authorization, where access control rules for resource usage (here, credential-bound domains) are not uniformly applied in all code paths that consume those credentials.
Potential impact
- Credentials for APIs and services may be exfiltrated to attacker-controlled servers
- Unauthorized calls to external services using shared credentials could be made
- Abuse of organization-owned accounts or API keys associated with those credentials
- Expansion of access to downstream systems that rely on those credentials for authentication or authorization
- Credentials for APIs and services may be exfiltrated to attacker-controlled servers
- Unauthorized calls to external services using shared credentials could be made
- Abuse of organization-owned accounts or API keys associated with those credentials
- Expansion of access to downstream systems that rely on those credentials for authentication or authorization
General mitigation guidance
Mitigation generally focuses on enforcing consistent authorization rules wherever credentials are consumed and limiting credential exposure:
- Apply the same domain restriction checks to all nodes that can send HTTP requests with credentials, not just dedicated HTTP nodes
- Treat credentials as scoped resources with centrally enforced policies that cannot be bypassed in specific components
- Reduce the set of users with access to shared credentials and prefer per-user or per-workflow credentials where practical
- Implement least-privilege for credentials, ensuring they only grant access necessary for specific workflows and cannot be freely repurposed
Mitigation generally focuses on enforcing consistent authorization rules wherever credentials are consumed and limiting credential exposure:
- Apply the same domain restriction checks to all nodes that can send HTTP requests with credentials, not just dedicated HTTP nodes
- Treat credentials as scoped resources with centrally enforced policies that cannot be bypassed in specific components
- Reduce the set of users with access to shared credentials and prefer per-user or per-workflow credentials where practical
- Implement least-privilege for credentials, ensuring they only grant access necessary for specific workflows and cannot be freely repurposed
How teams detect issues like this
Detection typically involves verifying how credentials are used across workflow components:
- Static or configuration analysis to identify workflows where GraphQL nodes use credentials that have domain restrictions configured
- Code review focused on credential-handling paths, checking that domain and policy constraints are enforced consistently across all nodes
- Policy enforcement that flags or blocks workflows sending restricted credentials to domains outside their allowed list
- Monitoring and logging of outbound requests from workflow nodes to detect unusual destinations or credential usage patterns
Detection typically involves verifying how credentials are used across workflow components:
- Static or configuration analysis to identify workflows where GraphQL nodes use credentials that have domain restrictions configured
- Code review focused on credential-handling paths, checking that domain and policy constraints are enforced consistently across all nodes
- Policy enforcement that flags or blocks workflows sending restricted credentials to domains outside their allowed list
- Monitoring and logging of outbound requests from workflow nodes to detect unusual destinations or credential usage patterns
