CVE-2026-68981

This vulnerability exposes a fundamental category error in resource measurement that warrants attention beyond the CVSS score. Apache NiFi was enforcing request size limits on compressed bytes rather than decompressed output. This is backwards — gzip compression can expand data by theoretically up to 1032x, meaning a modest compressed request could consume gigabytes of heap during decompression. The system was measuring the wrong invariant entirely. The fix confirms this interpretation. Rather than retrofitting the Jersey filter to meter decompressed content (which would require buffering and defeat streaming), the team removed gzip decompression entirely and moved compression handling to Jetty. That's feature removal as remediation — a signal that the Jersey layer was never architected as a security boundary. For defenders: first, verify whether your NiFi deployment sits behind authentication and network segmentation. If the REST API was already a high-trust surface (as it should be in production), the actual exploitability may be narrower than the 7.5 CVSS suggests. Second, assess whether your deployment has compensating controls like request timeouts, connection-per-IP limits, or JVM heap caps that would bound this even without the patch. Third, understand that the upgrade to 2.11.0 is an architectural migration (Jetty vs Jersey compression), not a simple patch — plan for regression testing on data flows. The deeper lesson is that this measurement category error — enforcing limits on transport encoding rather than actual resource consumption — is a recurring pattern across toolchains. The 'easy' metric (compressed size) is computationally convenient but semantically wrong. Future framework decisions should specify the security invariant explicitly: not 'limit request size' but 'limit decompressed content to X regardless of compression ratio.'

Reviewed through automated stages and approved by a human before publication.