Issue Station
Sign In
Tools hereToolbox

n8n - ✅(Solved) Fix Breaking change in 2.9.0 when saving/sharing Credentials, using external vault [2 pull requests, 3 comments, 3 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
n8n-io/n8n#28516•Fetched 2026-04-16 07:05:18
View on GitHub
Comments
3
Participants
3
Timeline
11
Reactions
0
Author
jhaumontjhaumont
Participants
jeanibarzjeanibarzjhaumontjhaumontn8n-assistant[bot]n8n-assistant[bot]
Timeline (top)
commented ×3renamed ×3cross-referenced ×2labeled ×1

Error Message

The error we have: Could not find a valid external secret vault name inside "={{ $secrets.azureKeyVault["postgres-n8n-data"] }}" used in "password" 6. Try to update the credential or to share it, you will have an error

Root Cause

We using an external secret provider (azure key vault). An example of value in a credential : {{ $secrets.azureKeyVault["postgres-n8n-data"] }}. We have to use the [ ] because of the - in the secret name in the azure key vault (this is a internal convention).

Fix Action

Fix / Workaround

The issue comes from this PR https://github.com/n8n-io/n8n/pull/25406, released in the 2.9.0 A new check of the format forget to check the possibility to have a mix of . and []

PR fix notes

PR #25406: feat(core): Ensure credentials only use secret providers that are available in their project (no-changelog)

Description (problem / solution / changelog)

Summary

Project-specific external secret providers have not been released yet. This is why the added logic in this PR only runs if the env var N8N_ENV_FEAT_EXTERNAL_SECRETS_FOR_PROJECTS is true.

This PR adds validation to the internal credentials API that a $secrets. expression only references vaults that are accessible in the project the credential belongs to.

Covers these endpoints:

  • POST /rest/credentials
  • PATCH /rest/credentials/:credentialId
  • PATCH /api/v1/credentials/:credentialId

Credential transfer endpoints are covered in a sub-PR: https://github.com/n8n-io/n8n/pull/25625

Does not affect POST /api/v1/credentials since that one is limited to only creating credentials in the personal project. Instance owners will be able to use project secrets in there but nobody else will.

Related Linear tickets, Github issues, and Community forum posts

https://linear.app/n8n/issue/LIGO-170/be-credential-savingmoving-prevent-saving-a-secret-expression-for-a

Review / Merge checklist

  • PR title and summary are descriptive. (conventions) <!-- **Remember, the title automatically goes into the changelog. Use `(no-changelog)` otherwise.** -->
  • Docs updated or follow-up ticket created.
  • Tests included. <!-- A bug is not considered fixed, unless a test is added to prevent it from happening again. A feature is not complete without tests. -->
  • PR Labeled with release/backport (if the PR is an urgent fix that needs to be backported)

Changed files

  • packages/@n8n/db/src/repositories/secrets-provider-connection.repository.ee.ts (modified, +37/-1)
  • packages/cli/src/credentials/__tests__/credentials.controller.test.ts (modified, +9/-0)
  • packages/cli/src/credentials/__tests__/credentials.service.test.ts (modified, +221/-61)
  • packages/cli/src/credentials/__tests__/credentials.test-data.ts (modified, +37/-1)
  • packages/cli/src/credentials/__tests__/validation.test.ts (modified, +300/-29)
  • packages/cli/src/credentials/credentials.controller.ts (modified, +1/-2)
  • packages/cli/src/credentials/credentials.service.ts (modified, +31/-4)
  • packages/cli/src/credentials/validation.ts (modified, +147/-2)
  • packages/cli/src/modules/external-secrets.ee/secret-provider-access-check.service.ee.ts (added, +11/-0)
  • packages/cli/src/public-api/v1/handlers/credentials/__tests__/credentials.service.test.ts (modified, +83/-8)
  • packages/cli/src/public-api/v1/handlers/credentials/credentials.handler.ts (modified, +2/-2)
  • packages/cli/src/public-api/v1/handlers/credentials/credentials.middleware.ts (modified, +3/-3)
  • packages/cli/src/public-api/v1/handlers/credentials/credentials.service.ts (modified, +33/-5)
RAW_BUFFERClick to expand / collapse

Bug Description

After migrating from the v1 to the v2, we have an issue with all our credentials: we can't update or share them anymore. The error we have: Could not find a valid external secret vault name inside "={{ $secrets.azureKeyVault["postgres-n8n-data"] }}" used in "password"

We using an external secret provider (azure key vault). An example of value in a credential : {{ $secrets.azureKeyVault["postgres-n8n-data"] }}. We have to use the [ ] because of the - in the secret name in the azure key vault (this is a internal convention).

In the UI, the expression is valid <img width="627" height="136" alt="Image" src="https://github.com/user-attachments/assets/3e391ceb-1baa-482a-8b3c-86e36f135963" />

The issue comes from this PR https://github.com/n8n-io/n8n/pull/25406, released in the 2.9.0 A new check of the format forget to check the possibility to have a mix of . and []

ExpressionDot regex ((?=\.))Bracket regex ($secrets[ )
$secrets.vault.key✅ matches vault❌
$secrets["vault"]["key"]❌✅ matches vault
$secrets.vault["key"]❌ (next char is [)❌ ($secrets[ not present)

So there is a diff between the validation in the UI and the validation in the back for credential fields. Also, there is a lack of documentation regarding the possible format for the credential fields when using external secrets (https://docs.n8n.io/external-secrets/#use-secrets-in-n8n-credentials)

To Reproduce

  1. Deploy a 2.8.4 version of n8n
  2. Configure an external vault (example : azure key vault)
  3. Add a new secret inside the vault: postgres-n8n-data (dash are important here) to store the password connection
  4. Create a new postgre credential on n8n and inside Password field, set {{ $secrets.azureKeyVault["postgres-n8n-data"] }} as expression.
  5. Update n8n to latest version
  6. Try to update the credential or to share it, you will have an error

Expected behavior

{{ $secrets.azureKeyVault["postgres-n8n-data"] }} is valid as it's green on the UI (so valid expression)

Debug Info

N/A

Operating System

Kubernetes

n8n Version

2.15.1

Node.js Version

24

Database

PostgreSQL

Execution mode

queue

Hosting

self hosted

extent analysis

TL;DR

The issue can be fixed by updating the validation logic to handle mixed dot and bracket notation for external secret vault names.

Guidance

  • The problem arises from a change in validation logic introduced in version 2.9.0, which does not account for the possibility of mixed dot and bracket notation in external secret vault names.
  • To verify the issue, try updating the credential or sharing it with the current notation {{ $secrets.azureKeyVault["postgres-n8n-data"] }} and observe the error.
  • A potential workaround could be to use a consistent notation throughout, either using only dots or only brackets, but this may require changes to the external secret vault configuration.
  • The documentation for external secrets in n8n credentials should be updated to reflect the possible formats and limitations.

Example

No code snippet is provided as the issue is related to configuration and validation logic rather than code.

Notes

The issue is specific to versions 2.9.0 and later, and the workaround may not be applicable to all use cases. The documentation update is necessary to prevent similar issues in the future.

Recommendation

Apply workaround: Update the external secret vault name to use a consistent notation, either dots or brackets, to avoid the validation error. This is a temporary solution until the validation logic is updated to handle mixed notation.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

FAQ

Expected behavior

{{ $secrets.azureKeyVault["postgres-n8n-data"] }} is valid as it's green on the UI (so valid expression)

#search optimization#API routing#API middleware#SSR setup#ISR setup

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING