Velocity Curve
Book a call
← The register
SECSEC-02  ·  Security

Keys left in publicly readable code still opened 321 n8n setups, because taking a key out of the current files does not switch it off

Exposed
4,576 keys for n8n setups readable in publicly published code on GitHub, pointing at 1,255 separate setups · 321 of the 896 setups that could be reached accepted at least one published key, approximately 36% of the reachable setups and about 26% of all the setups named in the code · 129 setups reachable from the internet whose published identifying value matched weak master keys that had already appeared in public code · 4,398 of the 31,793 setups found were publishing the identifying value worked out from their master key, 13.8% of the setups observed
Loss — not established
Loss was not established. Nobody can say whether any of these keys were used by anyone other than the research team, and nobody can say what the systems behind those setups held or reached.
Determination

Researchers went looking through public GitHub commits for keys that open n8n automation setups, and found thousands of them, pointing at 1,255 different setups. Some setups had more than one key exposed, so the researchers gathered all the keys belonging to each setup and tried them. By then, 896 of those setups were still online and could be tested. In 321 of them, at least one of the publicly readable keys still worked.

Incident

n8n is an automation tool that many businesses run on their own servers. It stores the logins for the other systems it connects to, and a single master key inside each setup unlocks all of them. GitGuardian, which looks for keys published by mistake, examined how far someone could get starting from a leaked key.

The team searched code published on GitHub, including the old versions kept in its history, and found 4,576 keys for n8n setups. The keys pointed at 1,255 separate setups. Some of those setups had more than one key exposed, so the team collected every key belonging to each setup and tried them. Of the 896 setups that could be reached at the time of testing, 321 accepted at least one published key. That was approximately 36% of the reachable setups and about 26% of all the setups named in the code. 575 of the reachable setups accepted none of the keys tried.

In a separate count, the team used an internet-wide search service and identified 31,793 n8n setups. 4,398 of them were publishing an identifying value that n8n works out from the master key, 13.8% of the setups observed. For 129 of those, the published value matched weak master keys that had already appeared in public code. The team also reported weaknesses in the way n8n builds the secrets that sign logins, and 48 security flaws had been recorded against n8n by the time of the research.

The team further reproduced an attack through n8n's Git feature, turning a key that belonged to a sufficiently privileged account into access to the master key and the scrambled login records. Whether anyone outside the research used these routes against a working setup is unknown, and whether anyone's stored logins were unscrambled is unknown.

GitGuardian made several disclosures directly to n8n while the research was running. n8n acknowledged the reports, said it was aware of the issues and planned to address them, and later closed them. n8n fixed the Git feature flaw in versions 1.123.10 and 2.5.0. The team's own checks found that from version 2.25.6 the identifying value was no longer handed out in the same form. When GitGuardian published, it had not independently confirmed that all changes covering the key-handling findings had been released.

At the time of this researchn8n had received 48 CVEs since January 2026; several allowed attackers to escape the workflow execution environment and gain code execution or filesystem access on the host.
Before n8n v2.25.6Unauthenticated requests to GET /rest/settings could return the public instance ID, which was derived from the same encryption key, providing a second independent way to confirm a candidate key.
Beginning with v2.25.6Based on the researchers' validation, that public instance ID behavior was no longer present in the same form.
During the researchThe researchers found three weaknesses in the way n8n derives signing and session secrets and demonstrated how weak encryption keys can be recovered offline from public artifacts.
During the researchThe researchers reproduced an attack using CVE-2026-25053 that allowed an API key associated with a sufficiently privileged account to be escalated into access to the encryption key and encrypted credential records.
At the time of testing129 internet-accessible instances had public artifacts that still matched known weak encryption key patterns previously exposed on GitHub.
At the time of testingOf the 896 instances reachable, 321 accepted at least one exposed token found in public GitHub commits.
During the researchGitGuardian made several disclosures directly to n8n.
After the disclosuresn8n acknowledged the reports, said it was aware of the issues and planned to address them, and subsequently closed the reports.
Versions 1.123.10 and 2.5.0n8n fixed CVE-2026-25053, the critical Git node vulnerability.
At the time of publicationGitGuardian had not independently confirmed that all changes related to the cryptographic findings had been released.

Primary source — S1: https://blog.gitguardian.com/n8n-security-encryption-key-compromiseSnapshot

Cause of loss

  • A key published inside code kept working after it was taken out of the current files, because it expires only when someone cancels that exact key. Old versions of code stay readable on a public code host, and keys of this kind carry no expiry date of their own. So a key stayed usable from the moment it was published until somebody deliberately cancelled it, and where a setup had several keys out in the open, cancelling the one that was noticed left the others working.Technical name: long-lived secret in version history
  • Each published key carried the full powers of the account that created it, so whoever read the key inherited all of them. Keys like these were usually made by the people wiring up connections, who hold the top-level account, so a single key reached far past the one job it was made for. With it, someone could read every automation, list the saved logins and start new automations running on the server.Technical name: overscoped credential
  • A value worked out from a setup's master key was handed to requests that never had to prove who they were. Because that value was given out without a login, a guess at the master key could be checked against it without touching the setup again. The research team matched 129 reachable setups to weak master keys that were already sitting in public code.Technical name: unauthenticated access

Finding

A key published by accident does not stop working when the code that carried it moves on; it stops working only when someone cancels that one key. When several keys open the same setup, cancelling the one you noticed leaves the rest live, and anyone can find out which setups are still reachable.

Verification

What only you can answer

  • Were you working on the understanding that removing a key from your current code stopped it working, and had anything ever told you that it keeps working until it is cancelled at the automation tool itself?
  • Were you assuming your automation setup had a single key, held only by you, and could you say today who asked for each of the others and why?
  • If a key that opens your automation setup were readable by a stranger right now, which of your other accounts, customer records and suppliers would it reach, and is that reach one you are willing to carry?

What your AI can check

Report only; do not change any code or configuration. Answer each item with file or console references for every finding, and say plainly when something cannot be determined.

  1. Search the complete history of every repository this project owns, including all branches, tags, deleted files and exported workflow JSON, for n8n API keys and for the n8n encryption key value. Report every hit with file or console references, including hits that no longer exist in the current checkout, and state for each whether the same value still appears in any live configuration.
  2. List every n8n API key currently registered on the instance, with its owner and creation source, and report which keys are still accepted. Then report whether any automated secret scanning runs over this repository's history and over exported workflow JSON before files are committed or shared, and whether it runs on every change; cite file or console references.
  3. For each n8n API key in use, report the account it belongs to and that account's role and permissions, and state explicitly which keys can list stored credential objects, read full workflow definitions, inspect execution data, or create and activate workflows. Report any key issued from an owner or administrator account; cite file or console references.
  4. Report whether this n8n instance is reachable from the public internet, whether an unauthenticated request to its settings route returns the public instance ID, and what version it runs compared with 2.25.6. Also report whether the public API and its Swagger playground are disabled, and whether a separate randomly generated user-management signing secret is configured rather than authentication material depending on the encryption key; cite file or console references.

Prevention

Cancel the key, not just the copy of it

Treat any key that has ever been published, pasted or exported as live until you have cancelled it inside n8n itself. Deleting it from a file, a chat message or an export changes nothing about whether it still opens your setup. Keep a written list of every key ever issued for the setup, with who asked for it and what it was for, so that cleaning up means working down that list rather than dealing with the one key that surfaced.

Give each automation its own key, and never hand over the owner account

Ask for a separate key for each automation, made by an account that can do only what that automation needs, and refuse to connect the tool using the account that owns everything. When someone sets up a new connection for you, make "which account did you use, and what can it do?" part of the handover you accept in writing.

Assume anything your setup tells strangers can be used to test guesses at its master key

Ask whoever installed the setup to confirm in writing which parts of it answer strangers without a login, and to replace any memorable master key, such as your company or project name, with a long random value that is not also used to sign logins. Until you have that in writing, keep the setup off the open internet behind a private network or a strict list of allowed addresses, and keep the number of systems you connect to it small.

A key stops being dangerous when someone cancels it, not when it scrolls out of sight.

Same failure class

SEC-01A key left in a code project's saved history kept running up charges for months, with nothing to cap them, until a student's bill reached 55,444.78 USDLoss$55,444.78 · 14,200+ requests · 100 % failed