n8n,best tool ever, or disaster waiting to happen?

Automation is essential for any business, and tools like n8n have emerged to help with this need.  Add in AI features to n8n and there isn’t a task that couldn’t be automated.  Except maybe making me a peanut butter and fluff sandwich.

n8n is a powerful open-source automation tool that can connect to multiple applications and services from AI and APIs to databases, cloud services and webhooks without the need to write code, making it incredibly powerful and flexible.

For teams that self-hosts n8n, there are a lot of benefits: it gives you direct control to data, integrations, connections, automations, security, backups and updates.

That’s why it has become very popular, in fact, Shodan, a search engine specifically designed for discovering internet-connected services, shows that there are at least 9,700 n8n’s self-hosted sites in the US alone.

But that popularity comes with critical responsibility.  

n8n holds the keys to so many platforms and systems, so an exposed or misconfigured instance can become a serious security risk. The most sensitive part?

Credentials…

The n8n credentials store contains authentication information that allows n8n to connect to all its external services. If attackers gain access to your companies' n8n console, they potentially gain access to everything n8n touches, e.g. databases, AI tools, cloud services, accounts, internal systems and more.  This could be the “keys to the kingdom”.

That’s why understanding how to properly secure your self-hosted setup is not optional, it’s essential.

We reviewed Shodan and found that in many of the self-hosted n8n instances, there are vulnerabilities on port 80 and sometimes on both ports 443 and 80. While the n8n service may be secure (for now), the nginx layer is currently reporting vulnerabilities.  This nginx is used to proxy traffic to the n8n internal service.

One of the current vulnerabilities that we see in Shodan is CVE-2025-23419.

When multiple server blocks are configured to share the same IP address and port, an attacker can use session resumption to bypass client certificate authentication requirements on these servers. This vulnerability arises when TLS Session Tickets https://nginx.org/en/docs/http/ngx_http_ssl_module.html#ssl_session_ticket_key are used and/or the SSL session cache https://nginx.org/en/docs/http/ngx_http_ssl_module.html#ssl_session_cache are used in the default server and the default server is performing client certificate authentication.

https://nvd.nist.gov/vuln/detail/CVE-2025-23419  

Imagine if this was a remote code execution for something not related to n8n.  An attacker could take advantage of that vulnerability and move across on the self-hosted linux server and grab the n8n credentials database.  

About n8n credentials

In n8n, the credentials store has information to connect with specific apps and services. After creating credentials with your authentication information (e.g. username and password, API key, OAuth secrets, etc.), you can use the associated app node to interact with the service.

When n8n is self-hosted, it stores encrypted credentials locally in a database (SQLite by default if not configured, also supports and recommends PostgreSQL; MySQL and MariaDB support got deprecated in v1.0), each credential is encrypted before being written to the DB using AES-256, and the encryption key (critical for security) is stored either as an environment variable (N8N_ENCRYPTION_KEY) or randomly generated under ~/.n8n when n8n first starts up, if this file or the directory gets destroyed or deleted and recreated, you will lose the encryption key and you would have to re-make all credential items.

If someone gains access to this database, they can't read the credentials unless they have the encryption key, so when someone has access to the encryption key through the config file or using CLI, they can have full access to the credentials.  This is the nightmare scenario.  A RCE vulnerability via the web server, allowing someone to copy the credentials store and decryption key.

In n8n case, the security of the credentials mostly relies on how the encryption key is managed, if someone has access to just the database, the decryption is hard, but if someone has full server access, they could be able to extract both the DB and the decryption key, with access to the machine running the n8n application anyone can execute the command n8n export:credentials --all --decrypted and gain access to all stored credentials in an unencrypted format.

Some practices to ensure credentials security:

⦁ Provide the encryption key explicitly through environment variable and not rely on the auto-generated one.

⦁ External secrets integration. n8n supports AWS Secrets Manager, Azure Key Vault, GCP Secrets Manager, Infisical and HashiCorp Vault Secrets, this allows to store sensitive credential information in external vaults instead of n8n's internal database, this provides an extra layer of security and enables centralized credential management across multiple n8n environments.

⦁ Enable Two-Factor authentication (everywhere!)

⦁ Least Privilege Principle. Share credentials only with users who need them.

⦁ Organize credentials by Project to control access.

⦁ Periodically review credential sharing.

⦁ Use descriptive names that identify purpose and service.

⦁ Block users from the Execute Commands and Read/Write Files from Disk nodes.

This is helpful if your users might be untrustworthy. A community thread dated from April 2025 explains that anyone able to create a workflow can execute a command node to export clear credentials commands without any obstruction if not configured.[https://community.n8n.io/t/cli-exporting-decrypted-credentials-with-authentication/103024/12#:~:text=In%20any%20shared,user%20interface%20restrictions.]

⦁ Disable the n8n public REST API to prevent others from using it.

Some sites of interest:

https://github.com/n8n-io/n8n

https://github.com/n8n-io/n8n-docs

https://n8n.io/legal/security/

https://docs.n8n.io/hosting/architecture/database-structure/

https://community.n8n.io/t/how-are-credentials-stored/40166/4

https://community.n8n.io/t/help-understand-n8n-credentials-encryption-for-backup/139830/2

https://deepwiki.com/n8n-io/n8n-docs/4-self-hosting-and-configuration

https://deepwiki.com/n8n-io/n8n-docs/5.2-credential-management

‍