CVE-2026-68981 is a high severity (CVSS 7.5) resource exhaustion flaw in Apache NiFi. Versions 1.5.0 through 2.10.0 enforce the maximum request size on the compressed payload, not the decompressed output, so crafted gzip requests can consume excessive memory. Upgrade to Apache NiFi 2.11.0.
What's affected
The record says Apache NiFi 1.5.0 through 2.10.0 is affected, and that upgrading to 2.11.0 is the recommended mitigation. I could not retrieve the Apache announcement thread (the archive needs scripting to render), so this comes from the record's text.
The mechanism is specific to the REST API. NiFi supports gzip encoded HTTP requests through a Jersey encoding filter, and the size limit was checked before decompression. The fix described in the record relocates response compression to the Jetty server and disables decompression of gzip encoded HTTP requests.
That last point has an operational effect. After the upgrade, a client that sends gzip compressed request bodies to the NiFi REST API will no longer have them decompressed. Check your own scripts and integrations.
How to check if you're exposed
Find your NiFi version in the UI under the About dialog, or from the install directory:
ls /opt/nifi | head
cat /opt/nifi/nifi-current/conf/nifi.properties | grep -i version
Adjust paths to your install. For containers, check the image tag. Then ask who can reach the REST API. A NiFi instance exposed to untrusted networks is the main concern, though internal clients with credentials may also reach the filter. The record does not say whether authentication is needed, so confirm with the Apache announcement.
A quicker route for a whole project is the free in-browser dependency scan at Gold. Paste a manifest or lockfile and it matches each dependency against known CVEs, including ones pulled in indirectly.
What to do now
- Upgrade Apache NiFi to 2.11.0 or later.
- After the upgrade, test any client that sends gzip compressed request bodies to the REST API, since request decompression is disabled.
- Limit network access to the NiFi API port to known administrators and systems.
- Set a memory limit and alerting for the NiFi JVM, and a supervisor that restarts it.
- Read the Apache announcement and the NiFi security page for details beyond the record.
Reachability analysis helps with ordering the work. Knowing whether your code actually calls the affected path tells you which services to patch first.
Why it matters
The class is CWE-409, improper handling of highly compressed data, often called a decompression bomb. A small compressed payload can expand to a very large one. If the limit is applied to the input size, the output is unbounded in practice, and the process runs out of memory while reading it.
The right control limits the decompressed size, or refuses to decompress at all, which is what the 2.11.0 fix does for request bodies. Services that accept compressed uploads should enforce limits on the expanded data. The record does not mark this CVE as known exploited.
Try it yourself
This demo shows how continuous monitoring flags new CVEs in components you already run, so releases like this are not missed.
Click through it at your own pace, or open it full screen.
Quick check
Which version fixes it?
Apache NiFi 2.11.0, according to the record.
Will upgrading break gzip clients?
The record says 2.11.0 disables decompression of gzip encoded HTTP requests, so test clients that send compressed request bodies.
Sources
- https://lists.apache.org/thread/vxrqn7poyf1wx6gdy7c0dxqfqkctjngg (listed in the record, not retrieved for this review)
- Record: NVD entry for CVE-2026-68981 (score 7.5, HIGH)
Last reviewed: 18 October 2026.
