n8n Chat Trigger Security Fix: Who Should Check Their Setup?

n8n published a security advisory on October 28, 2026 about the Chat Trigger. The affected situation is specific: a published Chat Trigger using Embedded Chat with n8n User Auth could allow an unauthenticated GET request to bypass the intended check. If your business uses an n8n chat on a site or portal, identify its mode, authentication setting, and installed version. The advisory is a reason to inspect your setup; it is not evidence that every n8n chat was exposed or that your organization was breached.

What the advisory says happened

A setup GET route was exempt from n8n User Auth so the hosted chat page could load. The exemption also applied to embedded chat. In the advisory’s affected configuration, an unauthenticated request to the chat webhook could read the conversation history of a named session or trigger the workflow with supplied input. The exact downstream impact depends on what the workflow does. A simple question-and-answer flow differs from one that writes CRM records or calls other services. The maintainer rates this issue Moderate; use its technical conditions rather than a generic “all chatbots are unsafe” headline.

Identify whether your workflow matches

1. Find the workflow that serves the chat and open its Chat Trigger node.
2. Check whether the chat mode is Embedded Chat rather than Hosted Chat.
3. Check whether authentication is n8n User Auth.
4. Confirm whether the workflow is published and reachable.
5. Record the n8n version and who administers the instance.

The Chat Trigger documentation explains these settings. The presence of a widget on a WordPress page does not reveal the server-side mode or auth setting. If a vendor hosts your automation, ask them to answer each question with configuration and version evidence.

Choose the corrected version for your line

The advisory lists patched versions 1.123.89, 2.45.5, 2.46.1, and 3.0.1 for their respective release lines. Those numbers are not an instruction to migrate every installation to the 3.x line. Confirm the line you run, its maintained channel, and the relevant patch with your administrator. A higher-numbered prerelease is not automatically the appropriate production upgrade. Follow the official n8n updating guidance for your installation method and prepare a recovery path before changing production.

Test the business workflow after patching

Use a staging environment and fictitious records where possible. Confirm that an authorized user can start a session and get the expected response. Confirm that a request without the required login is denied in the affected route. Then check every connected tool the chat can invoke, including CRM lookup, record creation, or notifications. Record the result and version. A green execution status alone does not prove that records were written to the right customer or that an access rule holds. Have the responsible owner accept the outcome before restoring normal traffic.

If you cannot update immediately

The advisory discusses temporary exposure reduction, such as disabling the affected chat or restricting access, while arranging the patch. Treat those as interim measures, not a substitute for an installed correction. Consider what users will see if the channel is unavailable and provide another approved contact route. Do not improvise a change that silently breaks customer support, and do not test against a third-party instance without authorization.

Keep other advisories separate

n8n published other notices around the same time, including legacy code-node exposure and a distinct OAuth2 credential-flow issue. They have different prerequisites and remediation. Do not collapse them into the Chat Trigger finding or conclude that every OAuth connection is vulnerable. Inventory affected features separately, document the decision for each, and check any saved workflows that require migration.

Questions to send your provider

Record the scope of the response

A maintenance record should identify the affected instance, environment, version before and after, workflow, patch date, and test result. Avoid a global statement that “n8n is secure” when only one Chat Trigger was checked. If several clients share an installation, review the configurations separately and confirm which team can modify each workflow. The advisory describes one access-control failure; routine credential rotation, permission review, monitoring, and backups still matter but are separate controls. Keep the evidence specific enough for a future maintainer to repeat the check after the next upgrade.

Ask: “Does our published chat use Embedded Chat with n8n User Auth? Which n8n version runs it? Which patched release was installed? What happened when authorized and unauthorized access were tested? Were connected actions checked?” Those answers are more useful than a generic assurance that the server is current. The immediate objective is a corrected, verified configuration and a record of how the customer-facing workflow behaves afterward.

If your provider confirms the configuration was not affected, ask them to record why: the chat mode, authentication option, publication state, or another documented condition. A transparent negative finding is useful; it avoids repeated emergency changes prompted by the same headline. If they cannot establish those facts, treat the installation as needing technical triage rather than assuming safety or compromise.

For a customer-facing service, also plan how users will be informed if the chat must be taken offline temporarily. A simple link to an existing contact route is better than letting a broken widget accept messages that nobody receives. Confirm that the replacement route has an owner and that inquiries created during the maintenance window can be followed up. This operational check is separate from the security patch, but it prevents the corrective work from creating an avoidable support gap.