CVE-2026-33663: n8n · Insecure Direct Object Reference
Affects n8nSource CVE Database V5
Not known to be exploited · CVSS 8.5 High : upgrade to 2.13.3 or 1.123.27 soon.
Data as of 30 Oct 2026, 11:52 UTC
- EPSS
- 0.3% chance of exploitation in 30 days – higher than 34% of CVEsExploit Prediction Scoring System: the likelihood attackers will use this flaw soon.
- Patch
- Available – fixed in 2.13.3, 1.123.27
CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:N/VA:N/SC:H/SI:H/SA:HExploitation evidence
Disclosed: evidence found.
CVE published 25 Mar 2026
Detectable: no evidence on record.
No public nuclei template indexed
Weaponized: no evidence on record.
No public exploit code indexed in Metasploit or Exploit-DB
Exploited in the wildExploited: no evidence on record.
Not in CISA KEV and no source reports exploitation
Observed by OffSeq MirageSeen by Mirage: no evidence on record.
No attack traffic recorded by OffSeq Mirage sensors
A missing step is not evidence of safety. Sources: cve.org (opens in a new tab), the Metasploit, Exploit-DB and nuclei-templates index as of 30 Oct 2026.
What to do
Upgrade n8n to 2.13.3 or 1.123.27; n8n-io/n8n to 1.123.27.
Affected software
| Product | Affected | Fixed in |
|---|---|---|
| n8n-ion8n | Affected
| Fixed in
|
GitHubn8n-io/n8npkg:github/n8n-io/n8nOther threats | Affected
| Fixed in
|
Check your own hosts for these packages with threat-finder (opens in a new tab), our free open-source scanner.
AI-suggested
- Upgrade n8n Community Edition instances immediately to version 1.123.26, 2.13.3, 2.14.1, or later to apply the official fix.
- If upgrading is not immediately possible, restrict access to the n8n instance to fully trusted users only, minimizing the risk of malicious insiders exploiting the vulnerability.
- Audit all generic HTTP credentials (httpBasicAuth, httpHeaderAuth, httpQueryAuth) stored on the instance and rotate any that may have been exposed or are in use by multiple users.
- Implement strict role-based access controls and monitor user activities for unusual workflow executions that may indicate abuse of credentials.
- Consider migrating sensitive workflows to the Enterprise Edition, which includes additional permission gates preventing this attack chain.
- Regularly review and update credential management policies to avoid sharing or reusing generic HTTP credentials across users.
- Enable detailed logging and alerting on credential access and workflow executions to detect potential exploitation attempts.
- Educate users about the risks of credential exposure and encourage prompt reporting of suspicious activities.
Description
n8n is an open source workflow automation platform. Prior to versions 2.14.1, 2.13.3, and 1.123.27, an authenticated user with the `global:member` role could exploit chained authorization flaws in n8n's credential pipeline to steal plaintext secrets from generic HTTP credentials (`httpBasicAuth`, `httpHeaderAuth`, `httpQueryAuth`) belonging to other users on the same instance. The attack abuses a name-based credential resolution path that does not enforce ownership or project scope, combined with a bypass in the credentials permission checker that causes generic HTTP credential types to be skipped during pre-execution validation. Together, these flaws allow a member-role user to resolve another user's credential ID and execute a workflow that decrypts and uses that credential without authorization. Native integration credential types (e.g. `slackApi`, `openAiApi`, `postgres`) are not affected by this issue. This vulnerability affects Community Edition only. Enterprise Edition has additional permission gates on workflow creation and execution that independently block this attack chain. The issue has been fixed in n8n versions 1.123.27, 2.13.3, and 2.14.1. Users should upgrade to one of these versions or later to remediate the vulnerability. If upgrading is not immediately possible, administrators should consider the following temporary mitigations: Restrict instance access to fully trusted users only, and/or audit credentials stored on the instance and rotate any generic HTTP credentials (`httpBasicAuth`, `httpHeaderAuth`, `httpQueryAuth`) that may have been exposed. These workarounds do not fully remediate the risk and should only be used as short-term mitigation measures.