Upgrade first, investigate second
n8n has published a high-severity security advisory for a flaw that could allow an ordinary member of a shared instance to send another user's decrypted credential to an external host. The issue affects releases before 2.39.6 on that branch and before 2.40.1 on the newer branch. n8n says the flaw is fixed in 2.39.6 and 2.40.1.
If more than one person can log in to your n8n instance, do this now:
- Upgrade to 2.39.6 or later, or to 2.40.1 or later.
- Until the upgrade is complete, allow access only to people you fully trust.
- Inspect inline agent workflows for tool nodes that reference unfamiliar credentials.
- Rotate credentials whose IDs were visible to members through workflow JSON, exports, editor URLs or API responses.
Those steps follow the maintainer's remediation and temporary mitigations. The restrictions and audit reduce exposure, but n8n explicitly says they do not fully remediate the flaw. The upgrade is the fix.
What the flaw does
The vulnerable path resolves a tool's input schema when a node tool is registered on an inline agent. During that process, n8n could decrypt whichever credential ID the caller supplied without first checking whether the caller's project owned it. Credential IDs themselves are not secrets: they can appear in workflow files, exports and editor URLs. A low-privilege member who knew an ID could therefore direct its plaintext secret to a host they controlled.
This is not a claim that every vulnerable instance has been compromised. The advisory describes what was possible; it does not report exploitation on your server. Rotation is warranted where an untrusted member could see credential IDs or edit relevant workflows, not merely because an old version existed for a few days.
Who needs to act
The urgent case is a shared instance with members who should not be able to use every credential. A one-person instance that has never admitted another user has a much narrower exposure to this particular attack path. It should still be upgraded, but the advisory's attacker needs member access.
Cloud users should check the version shown in their instance rather than assume the hosting model settles the question. Self-hosters should take their normal backup before upgrading, then confirm that important workflows still activate. Do not paste secrets into test runs; use the existing credential objects after the patched version is running.
One related check
n8n published several advisories on the same day. One separate high-severity shared-workflow issue affects releases before 1.123.80 and can also expose credentials to a workflow editor. If your instance is still on the older major line, upgrade to 1.123.80 or later and review who has Editor access.
The practical line is simple: shared n8n instances should not remain below a patched release. Upgrade, review the people and workflows that had access, and rotate only the credentials whose exposure path was actually open.