Apache NiFi CVE-2026-68981

The vulnerable decompression path is activated by any HTTP request to the NiFi REST API that includes a Content-Encoding: gzip header with a compressed body. This functionality is enabled by default in all NiFi versions 1.5.0 through 2.10.0 via the Jersey encoding filter and requires no special server-side configuration. No authentication is required - the CVSS 4.0 vector confirms PR:N, meaning any client able to reach the REST API port can trigger the condition. Exploitation is bounded by network reachability: deployments where the NiFi REST API port is restricted by firewall rules, VPN, or network segmentation to trusted hosts are not directly exposed to external attackers. The existing configurable maximum request size setting does not limit exploitation because it measures compressed size prior to decompression, which is precisely the flawed enforcement ordering this vulnerability exploits.

The CVSS 4.0 base score of 8.8 reflects a high-risk, unauthenticated, network-accessible attack with low complexity and no user interaction (AV:N/AC:L/AT:N/PR:N/UI:N) resulting in high availability impact (VA:H). The supplemental vector strengthens real-world priority: the attack is rated Automatable (AU:Y), meaning it can be scripted and replayed without human-in-the-loop steps; Recovery is rated User (R:U), implying service restoration requires operator intervention rather than automatic recovery; and Value Density is Concentrated (V:C), reflecting that a single NiFi node typically acts as a high-value central data integration hub. No CISA KEV listing exists and no POC has been identified, reducing the likelihood of opportunistic mass exploitation at this time. However, the zero-prerequisite attack path makes this a clear patch priority for any organization with NiFi REST API ports reachable from untrusted networks. One signal inconsistency to flag: the provided CVSS 4.0 vector includes VC:L and VI:L, and the intelligence tags reference Information Disclosure, yet the vulnerability description documents only memory exhaustion with no confidentiality or integrity mechanism described. This gap should be confirmed against the vendor advisory before assessing the full impact scope.

An unauthenticated attacker with network access to the NiFi REST API sends an HTTP POST or PUT request containing a gzip-compressed body crafted as a zip bomb - a payload that compresses at a ratio of 1000:1 or greater while remaining under the configured compressed-size limit. Because the Jersey filter decompresses the payload before the size check is evaluated, the NiFi JVM is forced to allocate heap memory proportional to the decompressed output, potentially hundreds of megabytes or gigabytes per request. Repeated requests, or a single sufficiently large bomb, exhaust available heap and trigger an OutOfMemoryError, taking the NiFi service offline. No public exploit code has been identified at time of analysis.