Apache NiFi fixes four web API security flaws

Apache NiFi has released version 2.11.0 to address four vulnerabilities in its web application programming interface, including high-severity weaknesses that could exhaust server memory or allow users with limited permissions to manipulate sensitive configuration processes.

The most broadly applicable flaw, tracked as CVE-2026-68981, affects NiFi versions 1.5.0 through 2.10.0. It stems from the way the platform processed gzip-compressed HTTP requests sent to its REST API.

NiFi enforced its configurable request-size limit against the compressed data rather than the much larger decompressed output. An attacker able to reach the API could therefore submit a specially constructed payload that expanded sharply during processing, consuming excessive memory and potentially disrupting the service.

The vulnerability has been classified as high severity. It is a resource-exhaustion issue rather than a memory-corruption flaw, meaning the primary risk is denial of service through depleted memory instead of direct modification of memory contents.

Version 2.11.0 removes support for decompressing gzip-encoded API requests and shifts response compression to the Jetty server layer. Administrators have been advised to upgrade rather than rely solely on network controls or adjustments to request-size settings, which were insufficient against the decompression weakness.

A second vulnerability, CVE-2026-68980, could allow an authorised user to delete assets belonging to a Parameter Context for which that user did not have the required permissions. It affects NiFi versions 2.0.0 through 2.10.0 and has been assigned a low severity rating.

Parameter Contexts allow administrators to manage reusable configuration values across NiFi data flows. Assets associated with those contexts can include files and other resources required by processors or services.

When handling a deletion request, vulnerable NiFi versions checked the user’s authority against a Parameter Context identifier supplied in the request. The application did not adequately verify that the targeted asset was actually owned by that context.

A user with write access to one Parameter Context could exploit the mismatch to request the deletion of an asset associated with another context. The issue primarily affects environments that apply different authorisation policies across multiple Parameter Contexts. Installations using the same write-permission boundary for all contexts are not exposed in the same way.

The third flaw, CVE-2026-68979, carries a medium severity rating and affects versions 1.10.0 through 2.10.0. It involves missing authorisation checks when users update values inside a Parameter Context.

Changing a parameter can alter the behaviour of processors, controller services and other components that reference it. Vulnerable versions verified permissions on the Parameter Context but did not consistently check whether the user was authorised to modify the components affected by the changed value.

An authenticated user permitted to edit a context could consequently influence components outside that user’s assigned authority. Where parameter values contain executable scripting content, an update could trigger code execution during automatic component validation.

The impact is constrained by NiFi’s existing verification process, which limits the issue to stopped components. It also depends on the deployment using component-level authorisation policies. The update adds checks covering affected components before Parameter Context changes are accepted.

The fourth vulnerability, CVE-2026-62354, is rated high severity and also affects NiFi versions 1.10.0 through 2.10.0. It concerns validation requests for proposed Parameter Context values.

Users with read access could submit alternative parameter values for validation even when they lacked permission to modify the configuration. The proposed values could then be passed to component validation methods, potentially causing external connections, resource access or other actions defined by the affected component.

Exposure depends on whether an organisation separates read and write privileges for Parameter Context configuration. Systems that do not apply different access levels are not affected by that particular authorisation gap. NiFi 2.11.0 requires write permission before proposed parameter values can be submitted for validation.

The advisories underline the security importance of NiFi’s REST API, which provides extensive administrative control over data flows, processors, services and shared parameters. Although the authorisation flaws generally require authenticated access, compromised accounts or overly broad permissions could give attackers opportunities to move beyond their intended roles.