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.
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
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.