n8n Databricks Node EUVD-2026-113822

Requires an n8n instance (2.14.0-2.46.3) running a workflow that uses the Databricks node AND binds its spaceId, indexName, or filePath parameters to attacker-controllable input delivered through a webhook, chat, or form trigger, with a valid Databricks credential stored on that workflow. The flaw is that the node builds the Public API request path from the caller-supplied identifier without encoding or validating it, so ../ sequences repoint the authenticated call. Limiting factors: the vulnerable field must be expression-bound to untrusted input (not a default configuration - reflected in AC:H/AT:P), and the attacker's reach is bounded to resources the stored credential already has scope for. The webhook/form entry point itself is unauthenticated (PR:N).

The CVSS 4.0 vector (AV:N/AC:H/AT:P/PR:N/UI:N/VC:H) scores 8.2 (High) and describes an unauthenticated, network-reachable path traversal whose only impact is high confidentiality (reading secrets via a stored Databricks credential), with no integrity or availability effect. Two signals temper the headline severity: AC:H and AT:P indicate the attack is not turn-key - it depends on an n8n workflow being built so that webhook/chat/form input is bound to the Databricks node's spaceId, indexName, or filePath fields, which is a deployment-specific precondition rather than a default state. EPSS is not provided in the input, and the vulnerability is NOT listed in CISA KEV, so there is no confirmed active exploitation; the vuln.today decision label is 'this_week' (elevated but not act_now/emergency). A public technical research writeup (abraxaslabs.tech) and the vulnerable source lines are referenced, but the input does not mark a verified working exploit as available. Net assessment: a genuine, credential-exposing issue worth patching on a near-term (this-week) cadence, but real-world risk is gated by whether the Databricks node is actually used with untrusted-input binding - it is not a blanket remote-root scenario. EPSS is missing, so widespread-vs-targeted exploitation likelihood cannot be quantified from the data.

An attacker sends a crafted request to a public webhook, chat, or form endpoint of an n8n instance whose workflow passes that input into the Databricks node's spaceId, indexName, or filePath parameter. By injecting unencoded ../ sequences and query strings, the attacker redirects the Databricks API call - authenticated with the workflow's stored credential - to an arbitrary endpoint and reads secrets outside the intended scope. A public technical writeup describes the mechanism; the input does not confirm verified working exploit code, and the CVE is not in CISA KEV.