CVE-2025-49595: n8n DoS via empty filesystem URI

CISO Take

If your AI automation stack uses n8n (self-hosted or n8n.cloud), patch to v1.99.0 immediately — the fix is available and the attack is trivial to execute. Although high privileges are required, any authenticated user or compromised service account can trigger resource exhaustion on /rest/binary-data with a single malformed GET request, taking down all workflows on the instance. In AI agent pipelines, this translates to complete loss of automation capability — no remediation path without a restart.

What is the risk?

Effective risk is moderate-to-high in production AI environments despite the medium CVSS score. The high-privilege requirement (CVSS PR:H) is the only real barrier — once an attacker has any authenticated n8n session (insider, compromised token, stolen cookie), exploitation is trivially reproducible with no special tooling. n8n.cloud confirmed vulnerable with observable HTTP/2 524 timeout signatures, meaning this is detectable but not preventable without patching. Organizations running n8n as the backbone of their AI agent orchestration have a single point of failure here.

What systems are affected?

Package	Ecosystem	Vulnerable Range	Patched
n8n	npm	—	No patch
193.4K OpenSSF 6.6 Pushed 3d ago 55% patched ~7d to patch Full package profile →

Do you use n8n? You're affected.

How severe is it?

CVSS 3.1

4.9 / 10

EPSS

0.4%

chance of exploitation in 30 days

Higher than 30% of all CVEs

Source: EPSS v3 — FIRST.org

Exploitation Status

Exploit Available

Exploitation: MEDIUM

Sophistication

Trivial

Exploitation Confidence

medium

○ Public PoC indexed (trickest/cve)

Composite signal derived from CISA KEV, VulnCheck KEV, CISA SSVC, EPSS, Metasploit, Exploit-DB, trickest/cve, Nuclei templates, and inthewild.io exploitation reports.

What is the attack surface?

AV Network

AC Low

PR High

UI None

S Unchanged

C None

I None

A High

What should I do?

5 steps

PATCH

Upgrade to n8n v1.99.0 — this is the only complete fix.
IMMEDIATE WORKAROUND

If patching is delayed, add a reverse-proxy rule (nginx/Caddy) blocking GET requests to /rest/binary-data where the query parameter contains 'filesystem://' or 'filesystem-v2://' with no subsequent path.
RATE LIMIT

Apply per-user rate limiting on the /rest/binary-data endpoint to limit blast radius from a single compromised account.
DETECTION

Alert on HTTP 524 responses from n8n endpoints; query logs for GET /rest/binary-data with URI-encoded 'filesystem://' patterns.
AUDIT

Review n8n API tokens and service accounts — rotate any that are broadly shared, as the attack requires valid credentials.

What does CISA's SSVC say?

Decision Track

Exploitation none

Automatable No

Technical Impact partial

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

How is it classified?

DoS Agent Framework AML.T0012 - Valid Accounts AML.T0029 - Denial of AI Service AML.T0049 - Exploit Public-Facing Application

Which compliance frameworks are affected?

This CVE is relevant to:

EU AI Act

Article 9 - Risk management system

ISO 42001

A.9.3 - Operational availability of AI systems

NIST AI RMF

MANAGE 2.2 - Mechanisms to sustain deployed AI systems and manage incidents

OWASP LLM Top 10

LLM04 - Model Denial of Service

Frequently Asked Questions

What is CVE-2025-49595?

If your AI automation stack uses n8n (self-hosted or n8n.cloud), patch to v1.99.0 immediately — the fix is available and the attack is trivial to execute. Although high privileges are required, any authenticated user or compromised service account can trigger resource exhaustion on /rest/binary-data with a single malformed GET request, taking down all workflows on the instance. In AI agent pipelines, this translates to complete loss of automation capability — no remediation path without a restart.

Is CVE-2025-49595 actively exploited?

Proof-of-concept exploit code is publicly available for CVE-2025-49595, increasing the risk of exploitation.

How to fix CVE-2025-49595?

1. PATCH: Upgrade to n8n v1.99.0 — this is the only complete fix. 2. IMMEDIATE WORKAROUND: If patching is delayed, add a reverse-proxy rule (nginx/Caddy) blocking GET requests to /rest/binary-data where the query parameter contains 'filesystem://' or 'filesystem-v2://' with no subsequent path. 3. RATE LIMIT: Apply per-user rate limiting on the /rest/binary-data endpoint to limit blast radius from a single compromised account. 4. DETECTION: Alert on HTTP 524 responses from n8n endpoints; query logs for GET /rest/binary-data with URI-encoded 'filesystem://' patterns. 5. AUDIT: Review n8n API tokens and service accounts — rotate any that are broadly shared, as the attack requires valid credentials.

What systems are affected by CVE-2025-49595?

This vulnerability affects the following AI/ML architecture patterns: AI agent frameworks, workflow automation pipelines, RAG pipelines, LLM orchestration layers, multi-agent systems.

What is the CVSS score for CVE-2025-49595?

CVE-2025-49595 has a CVSS v3.1 base score of 4.9 (MEDIUM). The EPSS exploitation probability is 0.38%.

What is the AI security impact?

Affected AI Architectures

AI agent frameworksworkflow automation pipelinesRAG pipelinesLLM orchestration layersmulti-agent systems

MITRE ATLAS Techniques

AML.T0012 Valid Accounts

AML.T0029 Denial of AI Service

AML.T0049 Exploit Public-Facing Application

Compliance Controls Affected

EU AI Act: Article 9

ISO 42001: A.9.3

NIST AI RMF: MANAGE 2.2

OWASP LLM Top 10: LLM04

What are the technical details?

Original Advisory

n8n is a workflow automation platform. Prior to version 1.99.0, there is a denial of Service vulnerability in /rest/binary-data endpoint when processing empty filesystem URIs (filesystem:// or filesystem-v2://). This allows authenticated attackers to cause service unavailability through malformed filesystem URI requests, effecting the /rest/binary-data endpoint and n8n.cloud instances (confirmed HTTP/2 524 timeout responses). Attackers can exploit this by sending GET requests with empty filesystem URIs (filesystem:// or filesystem-v2://) to the /rest/binary-data endpoint, causing resource exhaustion and service disruption. This issue has been patched in version 1.99.0.

Exploitation Scenario

A disgruntled DevOps engineer or a threat actor who has phished an n8n service account token sends a loop of GET requests to https://<n8n-instance>/rest/binary-data?id=filesystem:// — the empty URI causes the binary data handler to enter a blocking resource-exhaustion state. Within seconds, the n8n worker pool is saturated, all executing AI workflows (LLM calls, RAG retrievals, agent tool invocations) time out, and the instance returns 524 errors to all users. The attacker needs no knowledge of AI systems — this is a standard API abuse pattern. On n8n.cloud, the attack signature is identical and has been confirmed to produce observable HTTP/2 524 responses.

Weaknesses (CWE)

CWE-400 Uncontrolled Resource Consumption

CWE-400 — Uncontrolled Resource Consumption: The product does not properly control the allocation and maintenance of a limited resource.

[Architecture and Design] Design throttling mechanisms into the system architecture. The best protection is to limit the amount of resources that an unauthorized user can cause to be expended. A strong authentication and access control model will help prevent such attacks from occurring in the first place. The login application should be protected against DoS attacks as much as possible. Limiting the database access, perhaps by caching result sets, can help minimize the resources expended. To further limit the potential for a DoS attack, consider tracking the rate of requests received from users and blocking requests that exceed a defined rate threshold.
[Architecture and Design] Mitigation of resource exhaustion attacks requires that the target system either: The first of these solutions is an issue in itself though, since it may allow attackers to prevent the use of the system by a particular valid user. If the attacker impersonates the valid user, they may be able to prevent the user from accessing the server in question. The second solution is simply difficult to effectively institute -- and even when properly done, it does not provide a full solution. It simply makes the attack require more resources on the part of the attacker. recognizes the attack and denies that user further access for a given amount of time, or uniformly throttles all requests in order to make it more difficult to consume resources more quickly than they can again be freed.

Source: MITRE CWE corpus.