CVE-2026-103246 in n8n
Summary
by MITRE • 10/01/2026
n8n versions before 2.39.6 and 2.40.0 before 2.40.1 fail to validate credential ownership during inline agent node-tool introspection. Attackers can reference arbitrary credential IDs to decrypt and exfiltrate plaintext secrets to attacker-controlled hosts without ownership verification.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 10/02/2026
The vulnerability identified in n8n versions prior to 2.39.6 and the specific release of version 2.40.0 before patch level 1 represents a critical failure in access control logic within the workflow automation platform's inline agent node-tool introspection mechanism. This flaw stems from an insufficient validation of credential ownership during the process where internal agents query or inspect available tools and their associated configurations. In a properly secured system, any request to utilize or decrypt sensitive credentials must be strictly bound to the identity of the user or service account initiating the action, ensuring that entities only access resources they are explicitly authorized to manage. However, in these affected versions, the backend logic fails to enforce this binding relationship during introspection operations. This architectural oversight allows an authenticated attacker who has gained control over a workflow node or can manipulate input parameters within the inline agent context to bypass standard authorization checks. By directly referencing arbitrary credential identifiers stored elsewhere in the system's database rather than those associated with their own account, the attacker exploits the lack of ownership verification to trigger decryption routines for secrets they do not own.
The technical exploitation of this vulnerability relies on the ability to supply crafted inputs that point to specific credential IDs within the n8n instance's storage layer. When the inline agent processes these requests during tool introspection, it retrieves the corresponding encrypted secret and applies the necessary cryptographic operations to decrypt it without verifying whether the requester has permission to view or use that particular credential. This effectively neutralizes the isolation boundaries between different users or workflows in a multi-tenant setup or even within single-user instances where multiple distinct secrets are stored for various integrations such as AWS, Slack, GitHub, or database connections. The consequence is a complete compromise of confidentiality for all plaintext secrets managed by the n8n instance. Attackers can systematically enumerate credential IDs and extract sensitive information including API keys, passwords, tokens, and connection strings, which can then be exfiltrated to attacker-controlled external hosts. This capability transforms what might have been an isolated workflow execution into a comprehensive data breach of the organization's integrated service credentials.
From an operational impact perspective, this vulnerability poses severe risks to organizational security posture by enabling lateral movement and privilege escalation across connected services. Once plaintext secrets are obtained, attackers can authenticate as legitimate users or services in external systems such as cloud providers, communication platforms, or enterprise databases. This facilitates unauthorized access to sensitive data repositories, potential modification of critical configurations, and further exploitation of downstream applications that trust the compromised credentials. The ability to exfiltrate these secrets without detection is particularly dangerous because standard audit logs may not clearly distinguish between legitimate credential usage by authorized owners and malicious retrieval via this introspection flaw unless detailed request-level auditing is specifically configured and monitored. Furthermore, since n8n is often used in DevOps and continuous integration pipelines, the compromise of build or deployment credentials could lead to supply chain attacks where malicious code is injected into software artifacts before distribution.
This vulnerability aligns with CWE-269 Improper Privilege Escalation as it allows an actor to gain access to resources beyond their assigned permissions through a logic flaw rather than a traditional buffer overflow or injection technique. It also maps closely to CWE-359 Expose Private Information Without Proper Control, specifically regarding the failure to restrict exposure of sensitive data based on user identity. In terms of MITRE ATT&CK framework classification, this behavior corresponds to T1078 Valid Accounts and potentially T1552 Unsecured Credentials if the exfiltrated secrets are used for subsequent authentication attempts. The exploitation vector is primarily classified under T1190 Exploit Public-Facing Application if the n8n instance is internet-facing with valid credentials, or T1053 Scheduled Task/Job if leveraged within automated workflows to periodically steal data.
Mitigation strategies must prioritize immediate patching of all affected instances to version 2.40.1 or later where this ownership validation logic has been corrected. Organizations should verify that their n8n deployments are updated and confirm the presence of proper access control checks in the introspection endpoints. In environments where upgrading is not immediately feasible, network segmentation can help limit exposure by ensuring that only trusted internal services can communicate with the n8n API interfaces. Additionally, implementing strict input validation on all parameters passed to inline agent nodes can reduce the attack surface, although this is a compensatory control rather than a fix for the underlying logic error. Security monitoring should be enhanced to detect unusual patterns of credential decryption requests or high volumes of introspection calls that may indicate automated enumeration attempts. Regular rotation of all credentials managed by n8n is also recommended after remediation to ensure that any secrets potentially exposed during the window of vulnerability are no longer valid, thereby limiting the utility of stolen data for future attacks.