Secret exposure when using External Secrets in non-secret OAuth fields (Client ID)

Questions
1

Describe the problem/error/question

We have identified a potential secret exposure issue when combining:

  • External Secrets ($secrets.*)

  • OAuth credential fields

  • User-editable credential forms

  • Identity Providers that reflect input values in error messages (e.g. Azure AD)

Although some OAuth fields (e.g. Client ID) are not secrets by definition, n8n allows expressions to be used in all credential fields, including non-secret ones.

This makes it possible for a user to reference any external secret by name (at least any accessible by the n8n instance) in a non-secret field and cause its value to be reflected back to the UI via an OAuth error message.

Tested for github and o365 but likely replicable for many other oauth2 credentials. Example:

  • O365 credentials redirect to login.microsoft. The secret leaked is not a valid application ID and microsoft will return the error “Application with identifier ‘very-secret-value’ was not found in the directory”
  • Github credentials will simply show a 404 from github as the aplication id is not found, but basic inspection shows the client id (or actually the very-secret-value) in plain text in the url

What is the error message (if any)?

Exposure in plain text to the user of any secret n8n has access to in the external vault. Suggestion is to disallow (or allow an admin to disallow at n8n instance level) usage of reference to secrets when using expresions as client ID in oauth credentials.

Please share your workflow

N/A. This applies to credential creation

Share the output returned by the last node

N/A. This applies to credential creation

Information on your n8n setup

  • n8n version: 2.3.4 (onprem)
  • Database (default: SQLite): PostgreSql
  • n8n EXECUTIONS_PROCESS setting (default: own, main):
  • Running n8n via (Docker, npm, n8n cloud, desktop app): kubernetes on AWS EKS
  • Operating system: linux x64
1 Like
2

Hey @jc.lucena Welcome to the n8n community!

you are correct using $secrets.* in any credential field can leak secrets, as n8n allows expressions everywhere, and external secrets resolve to plain text. There’s no built-in way to block $secrets.* in specific fields like OAuth IDs.

To improve security:

  1. Limit $secrets.* usage to trusted credentials owned by admins.
  2. Keep non-secret data like OAuth IDs as literals.
  3. Reporting this would help others also i would do that

Currently, disallowing secrets in non-secret fields isn’t possible, but it’s worth raising as a security issue. Let me know if this helps

3

Thanks @Anshul_Namdev . The issue is not about having non-secret data stored as secrets. I agree that clientId shouldn’t be stored as a secret. The issue is that being able to set a secret in the clientId oauth field allows to expose any secret in the vault, reagardless if it is a clientId, the client secret or event any arbitrary secret which has nothing to do with the oauth credential being setup.

The attack surface is moderate as only n8n admins can actually reference the external secrets. However, in most organisations, an n8n admin should not have direct access to, for example, a postgre database password and this would be safely stored in an external vault (by the actual DB admin). However, with this vulnerability, nothing stops the n8n admin from exposing secrets via this mechanism.

Apologies as I am new to the forum. How would this be raised as a security issue?

1 Like
4

To report this security issue properly to n8n, follow these steps:

  1. Email the security team directly
    Send an email to: [email protected] this is the dedicated address for vulnerabilities and security-related questions.

  2. Include detailed information
    In your email, provide:

  • Your n8n version and hosting setup (you mentioned 2.3.4 / EKS, which is perfect).
  • Clear reproduction steps: credential types, where you used $secrets..., behavior with IdP, logs/screenshots if possible.
  • Why this could bypass organizational controls, as you explained regarding DB admins vs n8n admins.

This aligns with n8n’s vulnerability disclosure program and best practices.

  1. Optional: Link your forum thread
    Include a link to your discussion so they can review the context.

This is the official channel, and the security team will handle it privately. I did the same when i found a bug in the previous version of n8n which they patched in the 2.x version, let me know if this helps!

5

I will go ahead and do that. Many thanks @Anshul_Namdev

6

Let me know if that helps :smile: