Unauthenticated Slack Token Exfiltration and Full-Response SSRF via the Slack Trigger Webhook

Impact

The Slack Trigger webhook accepted a request whose signature could not be verified, because the signing secret is an optional credential field and the check returned success when it was absent. Such a request could name the file the node then downloaded, and the credential attached the workspace access token to that request whatever the destination. An unauthenticated caller who knows the webhook URL could have the token sent to a host of their choosing and read the response back.

Patches

The issue has been fixed in n8n versions 1.123.83, 2.41.4, and 2.42.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:

• Set a Signature Secret on all Slack API credentials used with the Slack Trigger node so that the signature check does not fail open.
• Disable the "Download Files" option on any active Slack Trigger nodes.
• Restrict network-level access to the n8n webhook endpoint to Slack's published IP ranges only.
• Enable SSRF protection by setting N8N_SSRF_PROTECTION_ENABLED=true.
• Rotate any Slack OAuth tokens associated with Slack Trigger workflows that may have been exposed.

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