GHSA-fvfv-ppw4-7h2w

What it actually does

Improper input validation in n8n's Guardrail node lets certain crafted workflow payloads skip configured content-safety checks. Data that should have been blocked or flagged (policy-violating prompts, secrets, or other restricted content) can continue into later nodes. The issue does not grant remote code execution, authentication bypass, or host compromise; it weakens an in-workflow control rather than the n8n runtime.

Why it matters to the business

Teams that treat Guardrail nodes as a binding safety or compliance gate may allow restricted content into downstream apps, models, or data stores. Consequences are typically policy evasion and possible sensitive-data exposure through connected services, not outage or platform takeover. The issue is low severity (CVSS 3.7), is not in CISA KEV, has no reported ransomware use, and has no known public exploit more than seven months after publication. Unpatched n8n (npm) below 2.10.0 remains relevant mainly where Guardrails are a documented AI or automation safety control.

How an attack unfolds

An actor who can submit data into an n8n workflow that includes a Guardrail node supplies input the node does not correctly validate. Guardrail checks are skipped or short-circuited, so later nodes treat the payload as having passed policy review. Restricted content can then be stored, sent to a model, or forwarded to webhooks and third-party integrations. Abuse requires a reachable workflow that actually uses Guardrail nodes and relies on them as a control. No public exploit code and no named threat-actor campaigns are known.

How to fix it

Upgrade the n8n npm package to 2.10.0 or later. Treat Guardrail nodes as defense-in-depth, not as a sole security boundary, and add application-level validation or external content filtering wherever workflows accept untrusted input. If an immediate upgrade is not possible, restrict who can submit data to Guardrail-protected workflows and review those workflows for over-reliance on the node.

How to confirm the fix worked

Confirm the running n8n version is 2.10.0 or newer via the in-app version display, CLI, or lockfile/image inventory. Inventory workflows that include Guardrail nodes. After upgrade, exercise legitimate policy-violation test cases those workflows already use and confirm Guardrail nodes still block expected categories. Search package lockfiles, container images, and deployment manifests for n8n versions below 2.10.0.

Typical attack path

1. Identify an n8n workflow that accepts external input and includes a Guardrail node
2. Submit unexpected or malformed input that the Guardrail node does not evaluate
3. The Guardrail control is skipped and the workflow continues as an allowed execution
4. Later nodes store, transform, or forward content that the Guardrail was meant to stop

How to detect it

There are no distinctive malware artifacts; a successful bypass looks like a normal allowed workflow run. Review n8n execution history and audit logs for Guardrail nodes that allowed traffic you expected to block, especially on untrusted webhooks, forms, or chat triggers. Correlate Guardrail pass outcomes with unusual payloads in downstream systems (model logs, outbound webhooks, connected SaaS). Absence of evidence is not conclusive. Focus hunts on the window before instances were upgraded to 2.10.0.

What your security team should do

• Upgrade n8n to 2.10.0 or later on every instance, prioritizing those whose workflows use Guardrail nodes
• Inventory workflows that depend on Guardrail nodes as a content-safety or compliance control
• Do not treat Guardrail pass/fail as a hard security boundary until patched and independently validated
• Add compensating input validation on untrusted webhook, form, and chat triggers
• Schedule this with routine patching rather than emergency change: exploit maturity is none, KEV is false, and severity is low