Summary
An authorization flaw in n8n's inline agent node-tool introspection allows credential references to be processed without confirming ownership. An attacker who can influence the referenced credential ID may decrypt and send plaintext secrets to an attacker-controlled host.
Affected context
The issue occurs in n8n workflows that use inline agent nodes with tool introspection and credential references. Risk is present when a user or workflow can cause arbitrary credential identifiers to be resolved and the application does not enforce ownership or equivalent authorization checks before decrypting the associated secret.
Exploit preconditions
- Attack surface: Inline agent node-tool introspection and credential resolution
- Required access: Ability to create, modify, or invoke a workflow that influences the referenced credential identifier
- Trigger point: Credential lookup and decryption during tool introspection
- Why exploitation is possible: The application resolves credential data without verifying that the requesting context owns or is authorized to access the referenced credential
Why this happens
The underlying bug is a missing object-level authorization check. Credential identifiers are treated as sufficient authority to retrieve and decrypt secrets, rather than being validated against the requesting user, workflow, project, or execution context. This behavior maps to CWE-639: Authorization Bypass Through User-Controlled Key, where a user-controlled identifier can access another protected object without an ownership check.
Potential impact
- Plaintext credentials may be disclosed
- Secrets may be transmitted to attacker-controlled infrastructure
- Connected services and integrations could be accessed using exposed credentials
- Additional systems may be compromised through credential reuse
- Confidential workflow and infrastructure information could be exposed
General mitigation guidance
Mitigation generally focuses on enforcing authorization at every credential access boundary and minimizing the trust placed in user-controlled identifiers.
Common defensive patterns include:
- Verify credential ownership or explicit access rights before lookup, decryption, and use
- Bind authorization decisions to the authenticated user, project, workflow, and execution context
- Avoid returning or transmitting plaintext secrets when a scoped operation or opaque reference is sufficient
- Apply least-privilege permissions to workflow execution and integration accounts
- Restrict outbound connections from automation workers and monitor unexpected destinations
- Use short-lived, narrowly scoped credentials and rotate secrets when unauthorized access is suspected
How teams detect issues like this
Organizations can look for authorization weaknesses through:
- Static analysis and code review of credential lookup paths for missing ownership or scope checks
- Tests that substitute identifiers belonging to other users, projects, or workflows
- Review signals such as direct database access followed by decryption without an authorization decision
- Policy enforcement requiring centralized authorization before secret retrieval
- Audit logging for credential access, decryption, workflow identity, and outbound destinations
- Automated security review tools that flag user-controlled object identifiers and missing access-control checks
