N8N · GHSA-prmc-fg87-r4gh · AI agents & MCP
FIX → >= 2.46.1 +2
n8n re-sent the Authorization header and basic auth credentials to a different origin when an authenticated HTTP request was redirected there. An attacker who can steer a redirect target, through an expression-fed URL or a malicious endpoint, can collect the stored credential.
first public Oct 28, 2026 · 1 source
Could this affect your app?
Free first check from your website. Connect your repo for the full answer.
Self-hosted or managed n8n instances where workflows make credential-authenticated HTTP requests to URLs that can be influenced by untrusted data or by an attacker-controlled endpoint. The HTTP Request node v4.4 was not affected by the default, so workflows that use only that node are less exposed. Instances with only fully trusted users and fixed destinations carry less risk.
Not affected if default-config-no-untrusted-urls, trusted-users-only
Who cares http-request, n8n, self-hosted, workflows
n8n --version or the n8n entry in package.json; versions below 2.45.5, 2.46.1 or are affected depending on the release lineWhen an HTTP request made by a credential-authenticated node followed a redirect to a different origin, n8n re-attached the Authorization header and basic auth credentials to the redirected request. The internal helper that builds the redirect configuration defaulted sendCredentialsOnCrossOriginRedirect to true. The HTTP Request node v4.4 opted out of this default, but other credential-using nodes did not. Where a workflow makes authenticated HTTP requests and the redirect target can be influenced by untrusted data, such as an expression-fed URL or a redirect issued by an attacker-controlled endpoint, the stored credential could be forwarded to an unintended destination.
The issue has been fixed in n8n versions 2.46.1, 2.45.5 and v3.0.1. Users should upgrade to one of these versions or later to remediate the vulnerability.
If upgrading is not immediately possible, administrators should consider the following temporary mitigations:
N8N_SSRF_PROTECTION_ENABLED=true to reduce the risk of attacker-influenced outbound requests.Check it with your coding agent
It reads this page and tells you if your code is affected.
Are you affected?
Ask from here. InfraStack checks the affected versions against your stack and answers in your inbox.
InfraStack checks the affected versions against your stack and answers in Slack, with the evidence and the fix.
3.0.1Upgrade to >= 2.46.1 +2
2.45.5 on the 2.45 line2.46.1 on the 2.46 line3.0.1 on the 3.x lineThese workarounds do not fully remediate the risk and should only be used as short-term mitigation measures.