CVE-2026-77085: n8n: SSRF protection bypass in SearXNG Agent tool

MEDIUM
Published August 20, 2026
CISO Take

n8n's SearXNG Agent tool used a raw HTTP client that bypassed the platform's centralized SSRF protection, so even instances running with N8N_SSRF_PROTECTION_ENABLED=true were not actually protected against this specific path. An authenticated user with permission to create SearXNG credentials could point the tool's API URL at an internal host — think cloud metadata endpoints or internal admin APIs — and have the response streamed back through the agent's chat output. There's no CVSS score published yet, it isn't in CISA KEV, and there's no public exploit or Nuclei template, but n8n has 16 tracked downstream dependents and 201 other CVEs in the package's history, underscoring a pattern of recurring exposure in this widely self-hosted automation platform. Exploitation only requires a low-privilege authenticated role, not admin, so any multi-tenant or team-shared n8n deployment should treat this as more than theoretical. Patch to 2.34.1 (or 2.33.4 on the 2.33.x branch) immediately, and in the interim restrict who can create SearXNG credentials or configure personal agents.

Sources:NVDGitHub AdvisoryCISA KEVOpenSSFATLAS

What is the risk?

Moderate risk. The vulnerability requires authentication and a specific permission (creating SearXNG credentials / configuring a personal agent), which raises the bar above a fully unauthenticated SSRF but is still trivially reachable in any n8n instance with more than one user role or shared team access — a common pattern for AI agent orchestration platforms. There is no evidence of active exploitation (not in CISA KEV, no EPSS score, no public PoC or Nuclei template), so urgency is driven by exposure and blast radius rather than observed attacks. The core danger is that it silently defeats a security control (N8N_SSRF_PROTECTION_ENABLED) that administrators explicitly enabled and trusted, which is worse than an undocumented gap because it creates false assurance.

How does the attack unfold?

Initial Access
An authenticated user with permission to create SearXNG credentials configures a personal AI agent with a malicious API URL pointing at an internal host.
AML.T0081
SSRF Protection Bypass
The Agent tool's raw HTTP client sends the request without routing through n8n's centralized SSRF protection, even though it is enabled.
AML.T0053
Internal Reconnaissance
The n8n server connects to the attacker-specified internal host or cloud metadata endpoint on the attacker's behalf.
AML.T0075
Data Exfiltration
The internal host's response content is returned through the Agent chat output, leaking internal data or credentials directly to the attacker.
AML.T0086

What systems are affected?

PackageEcosystemVulnerable RangePatched
n8nnpm—No patch
209.2KOpenSSF 7.116 dependentsPushed yesterday44% patched~19d to patchFull package profile →

Do you use n8n? You're affected.

How severe is it?

CVSS 3.1
N/A
EPSS
0.4%
chance of exploitation in 30 days
Higher than 30% of all CVEs
Exploitation Status
No known exploitation
Sophistication
Moderate

What should I do?

1 step
  1. 1) Upgrade to n8n 2.34.1, or 2.33.4 if on the 2.33.x branch. 2) Until patched, restrict the permission to create SearXNG credentials and configure agent tools to trusted/admin roles only. 3) Confirm N8N_SSRF_PROTECTION_ENABLED=true is set, but do not treat it as sufficient on unpatched versions — it did not cover this code path. 4) Apply network-level egress controls (firewall/security groups) blocking the n8n host from reaching cloud metadata endpoints (169.254.169.254) and internal-only services regardless of application-layer protections. 5) Audit existing SearXNG credential configurations for URLs pointing at internal/private IP ranges or metadata endpoints as an indicator of prior abuse. 6) Review agent chat logs for responses containing internal hostnames, IAM credentials, or unexpected internal data.

What does CISA's SSVC say?

DecisionTrack
Exploitationnone
AutomatableNo
Technical Impactpartial

Source: CISA Vulnrichment (SSVC v2.0). Decision based on the CISA Coordinator decision tree.

How is it classified?

Which compliance frameworks are affected?

This CVE is relevant to:

EU AI Act
Article 15-Accuracy, robustness and cybersecurity
OWASP LLM Top 10
LLM02-Sensitive Information DisclosureLLM06-Excessive Agency

Frequently Asked Questions

What is CVE-2026-77085?

n8n's SearXNG Agent tool used a raw HTTP client that bypassed the platform's centralized SSRF protection, so even instances running with N8N_SSRF_PROTECTION_ENABLED=true were not actually protected against this specific path. An authenticated user with permission to create SearXNG credentials could point the tool's API URL at an internal host — think cloud metadata endpoints or internal admin APIs — and have the response streamed back through the agent's chat output. There's no CVSS score published yet, it isn't in CISA KEV, and there's no public exploit or Nuclei template, but n8n has 16 tracked downstream dependents and 201 other CVEs in the package's history, underscoring a pattern of recurring exposure in this widely self-hosted automation platform. Exploitation only requires a low-privilege authenticated role, not admin, so any multi-tenant or team-shared n8n deployment should treat this as more than theoretical. Patch to 2.34.1 (or 2.33.4 on the 2.33.x branch) immediately, and in the interim restrict who can create SearXNG credentials or configure personal agents.

Is CVE-2026-77085 actively exploited?

No confirmed active exploitation of CVE-2026-77085 has been reported, but organizations should still patch proactively.

How to fix CVE-2026-77085?

1) Upgrade to n8n 2.34.1, or 2.33.4 if on the 2.33.x branch. 2) Until patched, restrict the permission to create SearXNG credentials and configure agent tools to trusted/admin roles only. 3) Confirm N8N_SSRF_PROTECTION_ENABLED=true is set, but do not treat it as sufficient on unpatched versions — it did not cover this code path. 4) Apply network-level egress controls (firewall/security groups) blocking the n8n host from reaching cloud metadata endpoints (169.254.169.254) and internal-only services regardless of application-layer protections. 5) Audit existing SearXNG credential configurations for URLs pointing at internal/private IP ranges or metadata endpoints as an indicator of prior abuse. 6) Review agent chat logs for responses containing internal hostnames, IAM credentials, or unexpected internal data.

What systems are affected by CVE-2026-77085?

This vulnerability affects the following AI/ML architecture patterns: agent frameworks, AI agent tool integrations, workflow automation pipelines.

What is the CVSS score for CVE-2026-77085?

No CVSS score has been assigned yet.

What is the AI security impact?

Affected AI Architectures

agent frameworksAI agent tool integrationsworkflow automation pipelines

MITRE ATLAS Techniques

AML.T0053AI Agent Tool Invocation
AML.T0075Cloud Service Discovery
AML.T0086Exfiltration via AI Agent Tool Invocation

Compliance Controls Affected

EU AI Act: Article 15
OWASP LLM Top 10: LLM02, LLM06

What are the technical details?

Original Advisory

n8n before 2.34.1 and 2.33.x before 2.33.4 contains an SSRF protection bypass in the SearXNG Agent tool. The tool sent requests to the user-supplied API URL using a raw HTTP client that did not route through n8n's centralized SSRF protection. On instances with N8N_SSRF_PROTECTION_ENABLED=true, an authenticated user with permission to create SearXNG credentials and configure a personal agent could set the API URL to an internal host, causing the n8n server to connect to that host and return the response content through the Agent chat output.

Exploitation Scenario

A contractor or low-privilege team member with access to create SearXNG credentials in a shared n8n instance sets up a personal AI agent for research tasks. Instead of a legitimate SearXNG endpoint, they set the API URL to the cloud provider's instance metadata service (e.g., http://169.254.169.254/latest/meta-data/iam/security-credentials/) or an internal-only admin panel. When the agent invokes the SearXNG tool, n8n's raw HTTP client sends the request directly, bypassing the platform's SSRF allowlist/denylist checks. The metadata service or internal service responds, and that response content — potentially including cloud IAM credentials or internal service data — is rendered back to the attacker through the agent's chat output, giving them a path to pivot further into the cloud environment or internal network.

Weaknesses (CWE)

CWE-918 — Server-Side Request Forgery: The web server receives a URL or similar request from an upstream component and retrieves the contents of this URL, but it does not sufficiently ensure that the request is being sent to the expected destination.

  • [Implementation, Operation] If there is a known list of applications, IP, hostname, and/or domains to which the product is allowed to communicate, then use allowlists to ensure that outgoing requests are restricted to these known entities. The allowlists could be in the application code or possibly enforced by firewalls or network segmentation [REF-1511].
  • [Implementation, Operation] If the product is expected to be able to connect to arbitrary IP addresses or domains, consider using a denylist that includes private network addresses, internal domain names, etc. The denylist could be in the application code or possibly enforced by firewalls or network segmentation [REF-1511].

Source: MITRE CWE corpus.

Timeline

Published
August 20, 2026
Last Modified
August 21, 2026
First Seen
August 20, 2026

Related Vulnerabilities