CVE-2026-86082 in n8n
Summary
by MITRE • 09/09/2026
n8n is an open source workflow automation platform. Prior to 1.123.76, 2.37.7, and 2.38.2, the OpenAI Chat Model node enforced credential allowed-domain restrictions for normal calls but not for the model-search dropdown. A workflow editor could set options.baseURL to an arbitrary host and make the searchModels path send the openAiApi credential there. The affected implementation is packages/@n8n/nodes-langchain/nodes/llms/LMChatOpenAi/methods/loadModels.ts, which omitted assertOpenAiCredentialAllowsUrl. This issue is fixed in versions 1.123.76, 2.37.7 and 2.38.2.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 09/09/2026
The vulnerability identified in n8n workflow automation platforms prior to versions 1.123.76, 2.37.7, and 2.38.2 represents a critical authentication bypass mechanism within the OpenAI Chat Model node implementation. This flaw stems from an inconsistent enforcement of credential validation policies across different functional paths of the application. Specifically, while standard API calls correctly enforced allowed-domain restrictions for credentials to ensure that sensitive keys were only transmitted to authorized endpoints, this security control was omitted during the execution of model search operations triggered via the user interface dropdowns. The technical root cause lies in the file packages/@n8n/nodes-langchain/nodes/llms/LMChatOpenAi/methods/loadModels.ts, which failed to invoke the assertOpenAiCredentialAllowsUrl function before processing requests for available models. This omission created a discrepancy where normal operational calls were secured against unauthorized destinations, but administrative or discovery actions remained exposed to manipulation by authenticated workflow editors.
From an offensive security perspective, this vulnerability allows for credential exfiltration through server-side request forgery techniques. An attacker with access to the n8n interface can configure the options.baseURL parameter to point toward a malicious host under their control. When such a configuration is applied and the model search functionality is triggered, the system transmits the stored openAiApi credentials directly to the attacker-controlled domain rather than the legitimate OpenAI service endpoints. This behavior effectively bypasses any intended network-level or application-level restrictions designed to limit where API keys can be used. The impact of this flaw is severe as it leads to the unauthorized disclosure of sensitive authentication material, potentially granting attackers full access to the victim's OpenAI account and associated billing resources depending on the permissions attached to that specific key.
This issue aligns with CWE-209, which describes the generation of an error message that includes sensitive information, although in this context it is more accurately characterized as a failure to enforce security controls during data transmission, falling under CWE-319: Cleartext Transmission of Sensitive Information within an Unprotected Channel. Furthermore, from the MITRE ATT&CK framework perspective, this vulnerability facilitates Credential Access via Tactic 1078 and potentially contributes to Initial Access if those credentials are reused across other services. The lack of input validation on the baseURL parameter during specific API discovery operations highlights a gap in defense-in-depth strategies where trust boundaries were not consistently applied across all code paths within the same module.
Mitigation for this vulnerability requires immediate upgrading to version 1.123.76, 2.37.7, or 2.38.2 of n8n, which includes patches that enforce credential domain restrictions uniformly across both standard calls and model search operations. For organizations unable to upgrade immediately due to operational constraints, compensating controls should include restricting network egress traffic from the n8n server to only known legitimate API endpoints using firewall rules or proxy configurations. Additionally, rotating any OpenAI API keys that may have been exposed during periods when this vulnerability was active is essential to prevent unauthorized usage and potential financial abuse. Regular audits of workflow configurations for suspicious baseURL parameters can also help detect exploitation attempts in environments where patching has not yet occurred.