CVE-2026-68981 in NiFiinfo

Summary

by MITRE • 08/03/2026

Apache NiFi 1.5.0 through 2.10.0 support gzip-encoded HTTP requests for the application REST API using a Jersey encoding filter. The framework enforced a configurable maximum request size on the compressed payload rather than the decompressed output, allowing a malicious client to send crafted requests that could consume excessive amounts of memory. Upgrading to Apache NiFi 2.11.0 is the recommended mitigation, which relocates response compression to Jetty Server and disables decompression of gzip-encoded HTTP requests.

If you want to get the best quality for vulnerability data then you always have to consider VulDB.

Analysis

by VulDB Data Team • 08/03/2026

This vulnerability affects Apache NiFi versions ranging from 1.5.0 through 2.10.0 where the application processes gzip-encoded HTTP requests through a Jersey encoding filter for its REST API. The fundamental flaw lies in how the framework handles request size limitations, specifically enforcing maximum request size constraints on the compressed payload rather than the decompressed content that the application actually processes. This design decision creates a significant memory exhaustion risk because malicious actors can craft compressed requests that appear small in size but decompress to consume excessive amounts of memory during processing. The vulnerability represents a classic decompression bomb scenario where compressed data expands dramatically upon decompression, allowing attackers to bypass normal size restrictions through cleverly crafted payloads.

The technical implementation issue stems from the Jersey filter configuration that processes gzip-encoded content without properly accounting for the difference between compressed and decompressed data sizes. When a client sends a gzip-compressed request, the system validates against the compressed size limit but does not consider that the decompressed content could be orders of magnitude larger than the original compressed payload. This misconfiguration creates an operational vulnerability where resource exhaustion occurs during the decompression phase rather than during initial request reception. The impact extends beyond simple denial of service as this can lead to application instability, performance degradation, and potential system crashes when memory resources are consumed by maliciously crafted requests.

This vulnerability aligns with CWE-400 which addresses "Uncontrolled Resource Consumption" and specifically relates to improper handling of compressed data in web applications. From an attack perspective, it maps to techniques described in the MITRE ATT&CK framework under T1499.004 for "Endpoint Denial of Service" where attackers exploit resource consumption vulnerabilities to exhaust system resources. The flaw demonstrates poor input validation and resource management practices that could enable attackers to consume memory resources far beyond what would be expected from normal application usage patterns. The vulnerability essentially allows an attacker to perform a form of resource exhaustion attack that bypasses typical size-based protections.

The recommended mitigation involves upgrading to Apache NiFi version 2.11.0 which addresses this issue by relocating response compression functionality to the Jetty Server component and most importantly disabling decompression of gzip-encoded HTTP requests entirely. This approach fundamentally changes how the application handles compressed content by removing the decompression processing step that was vulnerable to exploitation. The upgrade path ensures that compressed requests are no longer processed through the vulnerable Jersey filter, eliminating the possibility of attackers crafting malicious payloads that could consume excessive memory during decompression operations. Organizations should also implement additional monitoring for unusual request patterns and consider implementing rate limiting and size-based restrictions at multiple layers of their network infrastructure to provide defense in depth against similar vulnerabilities.

Responsible

Apache

Reservation

08/01/2026

Disclosure

08/03/2026

Moderation

accepted

CPE

ready

EPSS

0.00000

KEV

no

Activities

low

Sources

Are you interested in using VulDB?

Download the whitepaper to learn more about our service!