n8n: Denial of Service via ZIP decompression in webhook workflow

Vulnerability

The Compression node's Decompress operation in n8n versions prior to 2.24.0 expands attacker-controlled archives into memory without enforcing limits on decompressed output size. An unauthenticated attacker can send a small compressed archive to a public webhook workflow that uses this node, causing memory exhaustion. [1][2]

Exploitation

An attacker needs network access to a public webhook endpoint that triggers a workflow using the Compression node's Decompress operation. No authentication is required. The attacker crafts a small compressed archive (e.g., a ZIP bomb) that expands to a very large size when decompressed. Sending this archive to the webhook triggers the workflow, which decompresses the archive into memory without size limits, exhausting available memory. [1][2]

Impact

Successful exploitation causes the n8n process to terminate due to memory exhaustion, resulting in a denial of service that disrupts all workflows running on the same instance. The impact is limited to availability; no confidentiality or integrity compromise is reported. [1][2]

Mitigation

The issue is fixed in n8n version 2.24.0, released on 2026-06-16. The fix introduces configurable limits: N8N_COMPRESSION_NODE_MAX_DECOMPRESSED_SIZE_BYTES and N8N_COMPRESSION_NODE_MAX_ZIP_ENTRIES. If upgrading is not immediately possible, administrators can disable the Compression node by adding n8n-nodes-base.compression to the NODES_EXCLUDE environment variable, or restrict public webhook workflows to authenticated endpoints only. These workarounds are temporary and do not fully remediate the risk. [1][2]