AI PRP: Exposed n8n UI/REST API leading to RCE

[YuriyPobezhymov]

Hello.

I would like to start implementing a plugin to detect exposed n8n automation
instances where internal UI/REST API endpoints are accessible without
authentication.

The detector uses a multi-signal fingerprinting approach to confirm the
presence of n8n before testing REST API exposure. Fingerprinting is
performed using one or more of the following indicators:

• n8n web UI endpoints (e.g. /workflows or redirect behavior from /)
• Authentication UI (/signin)
• n8n-specific headers or frontend markers

Once n8n presence is confirmed, the detector checks for unauthenticated
access to internal REST endpoints such as /rest/workflows.

In all supported n8n versions, the /rest/* API is intended to be accessible
only to authenticated users. When exposed, attackers can enumerate,
modify, and execute workflows containing built-in command execution
nodes, which can lead to remote code execution on the host system.

This issue may affect:

• Legacy n8n deployments where authentication is disabled
• Modern n8n (1.x) deployments where reverse proxy or access control
  misconfiguration exposes internal REST endpoints

[github-actions]

Welcome to the Tsunami patch reward program!

Your issue has been added to our triage queue and will reviewed
shortly. The panel usually takes a decision once per week, so it
can take up to a week before you hear back from us.

Please, do not start the work until the panel has reached a
decision. Although we always welcome contributions, unapproved
work is not eligible for a reward.

~The Tsunami PRP team

[github-actions]

This message is addressed to the Tsunami panel.

Contributor stats

• The contributor has 0 issues tagged as main;
• The contributor has 0 issues tagged as queue.

Useful links

• All open issues from this contributor
• All open PRs from this contributor

[github-actions]

Congratulations, your request has been approved! 🎉

This means that you can start working on this contribution.

❗ Please take a moment to fill the participation form

If you are unsure where to start, we have compiled a set of
useful guides in our documentation:

📖 https://google.github.io/tsunami-security-scanner/howto/

Unfortunately, our documentation is not yet complete for
fingerprints, Python plugins and weak credential detectors. For
these, we recommend looking at existing plugins.

📢 Read latest announcements on GitHub pages

~The Tsunami PRP team

[YuriyPobezhymov]

Hello @tooryx!
After testing across n8n 0.x, 1.x, and 2.x versions, I found that UI accessibility (setup/login/workflows state) cannot be reliably determined via server-side HTTP responses. n8n use a SPA frontend, where most UI routes return the same HTML shell and authentication decisions happen client-side. Since Tsunami does not execute JavaScript, UI state is not observable in a deterministic way.

For this reason, this detector can be focused solely on what is reliably testable and security-relevant: unauthenticated access to /rest/workflows.

If this endpoint returns 200 OK with workflow JSON content, it indicates unauthenticated API access, which can lead to workflow manipulation and potential RCE. This condition alone is sufficient for a CRITICAL finding.

What do you think about these changes?

[YuriyPobezhymov]

Ok, PR added.

Notes (updated)

• In older versions, exposure may occur when authentication is disabled.
  Exposure conditions vary across n8n versions. Early releases without user management (e.g., 0.54.0) did not consistently protect REST endpoints, and available authentication mechanisms (e.g., JWT or basic auth) not fully cover /rest/* routes. In later 0.x versions, authentication behavior could be inconsistent—for example, instances without an initialized owner account or with misconfigured or ineffective flags (e.g., N8N_USER_MANAGEMENT_DISABLED) may allow unauthenticated access to /rest/* endpoints.
• In newer versions, this issue is often caused by misconfigurations such as improperly secured reverse proxies.
  n8n 1.x through latest versions enforces authentication inside its Express application layer via session middleware applied directly to the /rest/ router. A reverse proxy misconfiguration (e.g. forwarding unauthenticated requests, stripping auth
  headers) reaches n8n's own auth check regardless. Empirical testing confirms /rest/workflows returns 401 on n8n 1.x in all configurations including fresh unconfigured instances with no owner account.