CVE-2026-68981: 
NixOS vulnerability analysis and mitigation

CVE-2026-68981 is a denial-of-service vulnerability in Apache NiFi caused by improper handling of highly compressed (gzip-encoded) HTTP requests, classified as a "decompression bomb" or data amplification attack (CWE-409). It affects Apache NiFi versions 1.5.0 through 2.10.0, specifically the org.apache.nifi:nifi-web-api component. The vulnerability was reported on 2026-07-28 by researcher Minseong Kim (mak3bread) and publicly disclosed on 2026-08-03 via the Apache security mailing list. It carries a CVSS v4.0 base score of 8.8 (High) (GitHub Advisory, OSS-Security).

The root cause is CWE-409 (Improper Handling of Highly Compressed Data / Data Amplification). Apache NiFi's REST API used a Jersey encoding filter to support gzip-encoded HTTP requests, but the configurable maximum request size limit was enforced against the compressed payload rather than the decompressed output. This allows an unauthenticated attacker to craft a small gzip-encoded HTTP request that decompresses to a vastly larger payload, causing the server to allocate excessive memory during decompression. No authentication, special privileges, or user interaction is required — the attack is fully network-accessible and automatable (OSS-Security, GitHub Advisory). The issue is tracked upstream as NIFI-16152 (OSS-Security).

Successful exploitation allows an unauthenticated remote attacker to cause the Apache NiFi service to consume excessive memory, potentially crashing the service and resulting in a denial of service for all users and dependent data flows. The primary impact is high availability loss; confidentiality and integrity impacts are rated low (limited to the vulnerable system itself, with no subsequent system impact). Since Apache NiFi is commonly used as a critical data integration and workflow automation platform, service disruption could halt data pipelines and operational processes (GitHub Advisory, OSS-Security).

1. Reconnaissance: Identify internet-facing or network-accessible Apache NiFi instances running versions 1.5.0 through 2.10.0 using tools like Shodan, Censys, or network scanning (e.g., nmap), targeting the default NiFi REST API port (typically 8080 or 8443).
2. Craft decompression bomb payload: Create a gzip-encoded HTTP request body that compresses to a small size but decompresses to a very large payload (e.g., a file filled with repeated bytes compressed with gzip), designed to exceed available server memory upon decompression.
3. Send crafted request: Submit an HTTP POST or PUT request to a NiFi REST API endpoint (e.g., /nifi-api/) with the Content-Encoding: gzip header and the malicious compressed payload as the request body, ensuring the compressed size stays within the configured limit.
4. Trigger memory exhaustion: The Jersey encoding filter decompresses the payload without enforcing limits on the decompressed size, causing the NiFi JVM to allocate excessive memory, leading to an OutOfMemoryError or service crash (OSS-Security, GitHub Advisory).

• Network: Unusual HTTP POST/PUT requests to NiFi REST API endpoints (/nifi-api/*) with Content-Encoding: gzip headers and abnormally small request body sizes that trigger large memory allocations; repeated requests from the same source IP targeting the REST API.
• Logs: NiFi application logs (nifi-app.log) showing OutOfMemoryError or heap exhaustion errors; Java garbage collection logs indicating sustained high memory pressure; access logs showing repeated API requests with gzip-encoded bodies.
• Process: NiFi JVM process exhibiting sudden spikes in memory consumption followed by service crashes or restarts; unexpected NiFi service restarts recorded in system logs (/var/log/syslog or equivalent).

The recommended mitigation is to upgrade to Apache NiFi 2.11.0, which relocates response compression handling to the Jetty Server layer and disables decompression of gzip-encoded HTTP requests in the REST API, eliminating the vulnerable code path (OSS-Security, Apache Advisory). No official configuration-based workaround is documented for versions prior to 2.11.0; however, organizations unable to upgrade immediately should consider restricting network access to the NiFi REST API using firewall rules or reverse proxy controls to limit exposure to trusted clients only. Monitoring for anomalous memory usage and enabling JVM heap alerts can help detect exploitation attempts before service failure.

The vulnerability was covered by security news outlets including GBHackers and SecurityOnline shortly after disclosure, noting the unauthenticated nature of the attack and the availability of a patch (GBHackers, SecurityOnline). The DailyCyberSecurity Mastodon account also highlighted the advisory. Community reaction has been measured, with the primary focus on the straightforward remediation path (upgrading to 2.11.0) and the lack of known active exploitation.