CVE-2026-54314: n8n Compression Node Decompression Bomb DoS Vulnerability

Technical summary

The Compression node's Decompress operation in n8n versions prior to 2.24.0 lacks decompression size limits (CWE-409: Improper Restriction of Rendered UI Layers or Frames). When processing attacker-supplied archives, the node expands compressed data into memory without enforcing constraints on output size. An unauthenticated actor can deliver a specially crafted archive—often called a "zip bomb" or "decompression bomb"—through a publicly exposed webhook workflow endpoint. The decompression process consumes memory until the n8n process is killed by the operating system, triggering a denial of service. All workflows within the same n8n instance become unavailable until manual intervention restarts the process.

Business impact

Denial of service to workflow automation infrastructure. Organizations relying on n8n for critical automation tasks (API integration, data processing, scheduled operations, etc.) will experience unexpected downtime if an attacker sends a decompression bomb to a public webhook. Recovery requires manual process restart and may involve lost in-flight workflow state. Teams without robust alerting and automated restart mechanisms face extended outage windows and operational friction. Multi-tenant or shared n8n instances amplify blast radius, affecting all users on the same deployment.

Affected systems

n8n versions prior to 2.24.0 are affected. The vulnerability is exploitable only if the instance is exposed to untrusted network input via a webhook workflow that includes the Compression node's Decompress operation. Organizations running n8n in internal, non-public environments face reduced risk; however, those with public-facing webhooks or automation workflows triggered by external data are at direct risk.

Exploitability

Exploitability is high. The attack requires no authentication, no special privileges, and no user interaction—only network access to the webhook endpoint. An attacker can automate delivery of decompression bombs, and the attack succeeds regardless of the victim's security posture outside patching. The primary barrier is discoverability of the affected webhook URL; however, n8n deployments on predictable paths or discovered through reconnaissance can be targeted easily. Proof-of-concept decompression bomb generation is trivial and well-documented in security literature.

Remediation

Upgrade to n8n version 2.24.0 or later, which implements decompression size limits on the Compression node. Organizations unable to patch immediately should disable or restrict access to Compression node workflows, disable public webhook endpoints if not actively required, and implement network-level rate limiting and request size caps on webhook endpoints to mitigate attack surface. Monitoring for unexplained process restarts or memory spikes on n8n instances can signal exploitation attempts.

Patch guidance

Apply the fix by upgrading n8n to version 2.24.0 or newer. Consult the official n8n release notes and upgrade documentation to ensure compatibility with your deployment model (Docker, npm, self-hosted, managed cloud). Test the upgrade in a staging environment first, especially if your workflows depend on the Compression node, to confirm no behavioral changes. After upgrade, verify that the Decompress operation enforces memory limits by reviewing the release notes or triggering a test decompression with a known-safe archive.

Detection guidance

Monitor n8n process metrics for sudden memory exhaustion or out-of-memory kills, especially correlated with webhook requests. Check n8n logs for errors originating from Compression node decompress operations. Implement request size limits at the load balancer or reverse proxy layer to reject unusually large payloads sent to webhook endpoints. Network-based intrusion detection can flag repeated attempts to send compressed payloads to the same endpoint. Vulnerability scanners should confirm n8n version and alert on pre-2.24.0 instances.

Why prioritize this

CVSS 7.5 (HIGH) reflects immediate availability impact with zero authentication barrier. While confidentiality and integrity are not compromised, denial of service to automation infrastructure merits urgent patching. Precedence should increase if n8n instances host mission-critical workflows or multi-tenant environments. Organizations with public webhook endpoints should patch within 1–2 weeks; internal-only deployments can follow a standard patch cycle but should not be deferred indefinitely.

Risk score, explained

The CVSS vector AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H reflects a network-exploitable, unauthenticated, low-complexity attack with high availability impact and no cross-boundary effects. The score does not account for attack ease via decompression bomb tooling or reputational harm from unplanned downtime; context-specific risk may be higher for organizations with strict uptime SLAs or limited incident response capacity.

Frequently asked questions