n8n credential permission check: October 14 advisory and next steps
The n8n credential permission check advisory published October 14, 2026 names fixed versions and temporary measures. Here’s what teams should do.
Checked against the cited sources on .
What n8n announced on October 14
The n8n credential permission check advisory GHSA-8vrr-mgc5-jg55, published on October 14, 2026, tells users to upgrade to version 1.123.85, 2.43.5 or 2.44.1, or later, to remediate a vulnerability involving inline sub-workflow nodes. October 14 is the advisory’s publication date; it is not a stated patch release date.
The announcement lists affected version thresholds below those fixes, without naming release channels. Our editorial suggestion is to compare the deployed version with the advisory. In our view, assigning a clear upgrade owner is the most useful first move for a team.
How the n8n credential permission check could miss a node
According to the announcement, the credential permission check and execution engine interpreted disabled nodes differently. For n8n inline sub-workflow nodes, that mismatch could allow a node to escape the permission check and still execute. The advisory concerns an n8n non-boolean disabled value: a value other than a true-or-false boolean.
The stated prerequisite matters for teams reviewing access: a member would need to know the ID of a credential they cannot access. The advisory says that member could use the vulnerability to send the credential’s decrypted contents to a server they control. It does not report observed exploitation, affected customer counts or measured incident outcomes.
What to do if upgrading must wait
For administrators unable to upgrade immediately, n8n recommends the following temporary actions for the n8n credential permission check vulnerability:
The announcement explicitly warns that these workarounds do not fully remediate the risk and should be short-term measures. It supplies review targets, but no log queries, forensic procedure or guarantee of detecting exploitation, and it does not quantify any risk reduction.
We think the access restrictions and log review belong alongside a scheduled upgrade, rather than becoming a reason to postpone it.
What the announcement leaves unspecified
The announcement does not state edition coverage, hosted-plan handling or whether cloud instances receive automatic patching. It also does not describe the fix’s implementation, exact malformed disabled values, upgrade commands or post-upgrade verification procedures.
Our editorial suggestion is to record those deployment questions separately when coordinating the n8n credential permission check update, so assumptions about who handles the upgrade do not become the team’s action plan.
